[Openstreetmap] GPS point submission format

[Matt Amos]

On Wednesday 20 October 2004 09:32, sparkes wrote:
> Petter Reinholdtsen wrote:
> > 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 ;-)

the only problem is that MacOS and Windows users already have java and 
its pretty well-developed in terms of graphical capability and 
standard libraries/classes.

perl is also very good, but MacOS 9 (and earlier) and Windows users 
don't have it installed by default.

imho, the best option would be to have a java client for the time 
being (which doesn't depend on mysql locally) and, when the format 
has settled down, write a c/c++ client in some OS-independant toolkit 
(Gtk, Qt, wxWindows, FOX, etc...)

or possibly in perl/python/ruby if we can embed the interpreter into 
any sort or .dmg or Windows installer.

> > For this to work, we need to find a sensible exchange format.  It
> > need to be able to represent
> > (snip)
> > 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)

XML has one important feature: its forwards compatible and scalable. 
gpsd doesn't output important information like ephemeris and PR and 
DOP which can be used to refine the data offline using DGPS or DOP 
filtering. XML would allow us to add these things in later and 
optionally.

i disagree that xml-rpc/soap is a good way to do things, though, and 
i'd prefer we just stick to uploading XML files the old-fashioned way 
and using ssl+http as the access mechanism. (or, as you suggested: 
subversion or other webDAV system)

> 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.

this (openGIS, iirc) is already being used.

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

imho, this is a very good idea. if we store raw gps data in the most 
basic form (flat files) then it can be backed up or imported into 
other projects more easily.

> 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)

the idea is to have a multi-map style web interface, once we have 
enough data to start rendering useful maps. the priority is to get 
the data!

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

agreed.

cya,

matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20041102/6d53bd72/attachment.pgp>