[Openstreetmap] GPS point submission format

[sparkes]

Petter Reinholdtsen wrote:
snip
> 
> The problem with this approach is the amount of dependencies needed
> (java, mysql, gpsd), and the lack of access control when connecting to
> the central database.  To get rid of these problems, I propose a
> system where one submit GPS points by uploading a file to the central
> location, and this file is processed centrally to store the points
> into the central database.

I concur, I had to install java specifically to look at this project and 
the person who pointed out the project to me had to do the same as well. 
  Debian users don't use java that much ;-)

> 
>   - run gpsd on a laptop connected to your GPS
>   - run simple program (perl, c) connecting to gpsd, collecting GPS
>     points and storing them as time-stamped files with a sensible file
>     format.
>   - make simple program (perl, c) uploading files when the laptop is
>     able to connect to the central server

agreed your general method is better than the current one but C and 
simple program don't really go together ;-)  May I suggest Perl or 
Python are used for rapid development (and fixing) with excellent 
portability.  Not that it matters really anyway because my next suggest 
might lead to several different ways of adding the data via one clean 
interface

> 
> This way there is no need for the mysql database nor the java apps for
> submitting data.
> 
> For this to work, we need to find a sensible exchange format.  It need
> to be able to represent
> 
>  - GPS points (longitude,latitude,altitude, accuracy)
>  - timestamp and/or sequence number
>  - annotations/labels
>  - info on the submitter (name, email, address, etc)
> 
> It should be a clear text format for easy debugging and review, and
> easy to write and parse, to make sure the collecting program can be a
> simple one.

I believe this problem is best served with an xml-rpc or soap interface. 
  The file uploaded can be a simple xml file (so can be debugged by hand 
and modified using any of the tools available to us)

This centralises the database and creates an interface that is easy to 
use.  an interface like this would also promote cross development with 
other projects and inserted and getting information would be easier.

Another poster pointed out a standard method of storing gps points in a 
database.  May I also suggest that the backend stores the data in this 
format for even more portability and cross development.

But, I think the data uploaded shouldn't go direct into the database but 
be stored as files stored in a subversion server so it's simple to 
remove bogus data or roll back after problems.  I expect spam to appear 
in the database at somepoint (it took about 2 years for wiki's and blogs 
to be hosts for widespread spam but if we plan ahead) and this makes it 
a none-problem from the start.

The database can be created periodically from the data stored on the server.

I am suggesting two ways to access the data.

1) the database (like the current one but using the standard storage 
protocol)
2) the web services interface (so additions are easy and quick lookups 
available)

with the third way being the data stored on the subversion (or cvs) box 
that is only really accessed by scripts.

and one simple way to add the data, via the web services.

This removes the current restrictions on the updating and usage of the 
data pointed out by Petter and will allow the data to be used in more 
open source projects.
> 
> Comments?

is that enough ;-)


sparkes

-- 
<davee> "Sparkes, the Pete Best of LugRadio"