[OSGeo-Discuss] Mobile GPS data collection, summary of sorts.
Just van den Broecke
just at justobjects.nl
Wed Aug 2 15:41:38 PDT 2006
(Back from holiday...just went through the MGPSDC threads...wew..)
What I can offer is the GeoTracing (www.geotracing.com) platform, not as
much not as the solution but as a way to try out, share ideas, design
issues and experience. If the FOSS4G submission is accepted I hope to
present and/or demo in Lausanne (and/or have interesting discussions
with you).
I plan to move the code to geotracing.codehaus.org somewhere this month
(time!). Documentation (time!) is lacking, but several working
applications have been delivered that do personalized GPS tracking from
a mobile phone through a server finally into a (MySQL non-spatial) DB.
Application-requirements were the main driver for the project. The
underlying Media/CMS platform KeyWorx (www.keyworx.org) that e.g.
describes protocol concepts is reasonably documented:
http://kwx.dev.waag.org/docs
If you have a smartphone with bluetooth (JSR-82) plus bt gps you may try
out the MobiTracer client by signing up and downloading OTA:
http://www.geotracing.com/gt/my
The related TraceLand webapp runs at http://www.geotracing.com/gt
For MacOSX a _very_ experimental browser-AJAX-based client is available:
http://www.geotracing.com/gt/webtracer and
http://www.geotracing.com/gt/gpsdoor (small CLI Python program similar
to gpsd but HTTP-service-based)
Other:
- client/server comms uses lightweight XML over HTTP or TCP/IP
- hence client technology is independent of server
- authorization: users logon before any other action like submitting data
- personalization: all submitted data (GPS, media, POIs) is linked to
user (in DB).
- basically client does remote track recording through the XML protocol
(create-track, write-track, suspend/resume (creates segments), etc)
- media files (photo/video) can be uploaded (HTTP) or emailed
- geotagging media is attempted by matching EXIF timestamp data with GPS
points or else submission time
- raw GPS (NMEA) samples are sent to server, who parses, checks for
quality and spikes (GPS data can be "filthy") before appending to track
- client does some GPS-prefiltering: taking best sample in an
configurable interval
- time is a nasty issue: though a GPS has exact time, some phones do not
provide correct UTC, photos do not provide timezone info in EXIF etc
- no local storage/later syncing yet (a much wanted option since
connectivity may not be present in e.g. rural areas)
- for desktop and possibly/hopefully some PDA-type clients
(http://weblogs.mozillazine.org/dougt/archives/016719.html) I see
browser-AJAX-based solutions as a way to go over dedicated apps. You
will then only need small components to handle GPS and possibly local
storage.
- Opera Mobile on Symbian is not yet there, Minimo for CE is hopeful
with AJAX support.
- data organisation: server stores tracks per user divided into segments
(like GPX)
- REST service to acquire data as XML (e.g. GPX export)
- realtime tracking in browser with AJAX-based Pushlets (www.pushlets.com)
- yesyes, GeoTracing does not comply with OpenGIS stacks yet
I realize the above is somewhat long/unordered and not a direct reply
but I am enthousiastic about this topic and many issues discussed are
familiar to those that I have been working on the past year.
best,
--Just
Just van den Broecke just at justobjects.nl
Just Objects B.V. tel +31 65 4268627 Skype: justb4
The Netherlands http://www.justobjects.nl
Bob Basques wrote:
> First off, I'm about ready to put some of this into a WIKI, just figured
> it needs to be hashed out here first. :c)
>
> Mateusz Loskot wrote:
>
>> Bob Basques wrote:
>>
>
> Development of a BETA package for Mobile Data capture:
>
>>> The CLI approach seems to most sane to me. This will most like
>>> change over time with some of the seperate utilities being combined
>>> into bigger and better things later on. One reason I like this
>>> approach is that it's very easy to segment the utilities into smaller
>>> work area/groups. As long as a good Comm directive is followed, ann
>>> utilities should work in harmony together. This "Utility" approach
>>> also affords us the opportunity to work precisely on the things that
>>> need to be worked on, while at the same time using the tools already
>>> developed for other things.
>>>
>>
>>
>> What about the idea of modularized package + UI, for example command
>> line interface at the first stage?
>>
>
> I like thinking about this as a CGI sort of request handler. If this
> method were followed, then it's just that much easier to use components
> via a Webserver when the time comes, or even to combine utilities into a
> piped structure as handlers.
>
>>> Related to the above is the question of what build.
>>> I keep pointing
>>> to LINUX as the first version of things because it will require the
>>> least amount of NEW work to get a prototype operational.
>>> Basic requirements (as I see them):
>>>
>>> Every Device that is considered for porting, should have:
>>>
>>> * Have a Web Server of some sort (in the near term, nothing
>>> exotic should be attempted on the LINUX side, just keep it
>>> short and sweet so that the capabilities are easier to port
>>> to other OS's.
>>>
>>
>>
>> What is the idea of communication, could you elaborate?
>>
>
> Since my notion is that the Main server (mothership) and the portable
> device (figher ship) will each have about the same capabilites (ideally
> THE same), the only real problem is with syncing the data between them.
> The next biggest piece will be in updating tracking layers at each
> remote device, but the DB sysning should take care of this easily.
>
>>
>>
>>> * Have a Web Browser that has at least some Javascript
>>> capabilities, (most do, BTW, although most are also
>>> incomplete when talking about what features they support,
>>> don't support)
>>>
>>
>>
>> Yes, though it may be a problem with portability.
>> What Web browsers do you consider?
>>
>
> Since I wouldn't advocate anything to wierd in the Client GUI, it could
> be just about anything with Javascript support, Blazer (PALM),
> Opera(lot's of portable OS's), WinCE, etc. Even some of the Phone
> browser should support basic Javascript operations. I say we shoot for
> most, but not all up front.
>
>>> * These might be optional items
>>> * Have a way of generating a Map, even in a simplified
>>> form as a standalone operation.
>>>
>>
>>
>> What does "generate a map" means?
>> Do you mean it should be able to display map on a device screen?
>>
>
> Yup, the portable device acts just like a desktop version of thing, even
> when disconnected (it has some basic mapping data resident on the
> machine. Some smaller form factors will have limited space and the
> Syncing process could be made a bit more robust in these situations,
> where only a localized version of the data is resident on the portable
> device based on dispatching etc.
>
>>> * Have a way of connecting to a AVL hardware stack ??(etc.)
>>>
>>
>>
>> I'm not experienced with technical specification of AVL but OK :-)
>>
>
> I explain some of this in the earlier Email, but the important piece, is
> that they too also capture GPS data as a built in Capability.
>
>>> If we can agree to the above, then what we'll need to build (short
>>> list):
>>>
>>> * Collection format for the data (Points only to start with?)
>>>
>>
>>
>> What does "collection format" means?
>> Is this about log GPS locations or also from manual map editing?
>>
>
> Yes, and yes, with my description in the previous Email, I think you can
> see how this would work usig a database storage technique.
>
>>> * Database, Flat File, etc.
>>>
>>
>>
>> IMHO one of the most important requirement is insert/update/query
>> performance with good indexing.
>> So, I'd stick to SQLite.
>>
>
> Any SQL database, I'm most familiar with MYSQL. But since I'm
> suggesting that no special data formatting is needed, that the data
> could reside in anything with a SQL retrieval mechanism.
>
>>
>>
>>> * Server comm LIB, Main (MotherShip) to Secondary (Attack
>>> Fighter) web servers.
>>> * Syncing of captured data points
>>> * Syncing of Mapping data between servers fore
>>> re-distribution.
>>> * Daemon (listener) to monitor GPS (could be a wrapper around
>>> any of the options already available for reading
>>> GPS devices.) coordinate locations, and other digital
>>> devices, Compass, etc.
>>>
>>
>>
>> As Paulo has suggested, gpsd should work well.
>>
>
> See my notes on this in other Emails.
>
>>> * Some sort of GUI (web Based, even when running standalone)
>>> Do you mean it will be a JavaScript/AJAX application>
>>>
>
> Yes.
>
>>> * MapService, for providing Automated location services.
>>>
>>
>>
>> I imagine it can be one of the biggest problem to find/create services
>> infrastructure.
>>
>
> I'm not sure I understand this statement. If by it you mean a Mapping
> system with this type data already present, I have access to this type
> of thing. It's a big reason why I'm pushing hard to make this component
> based, as the CLIENT end of anything will end up in our Main Spatial
> service, not as a seperate application, but as an enhancement to the
> existing one.
>
>>> could be a start for pulling a project proposal out of.
>>>
>>
>> There are a bunch of details I'm glossing over here, but I think this
>>
>> Although it's hard for me to comment a Web-based interface for
>> GPS-driven application for data collecting, I think the plan is good.
>>
>> Here are my additional questions:
>> 1. What's the suggested development platform for the prototype?
>> 2. Are we still going to create and use underlying core components for
>> data accessing, processing, analysing, computing, etc?
>> 3. What about services infrastructure?
>>
>
> I think these questions should start to become clearer for all those
> reading so far, let me know if anyone is still needing some aspects
> (that I have described) explained further. I'm very interested in
> hearing about why my ideas are hair brained, etc. Don't worry about
> offending me either, I have this same problem with every application
> team I get on it seems. :c)
>
> bobb
>
>> Best regards
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: discuss-unsubscribe at mail.osgeo.org
> For additional commands, e-mail: discuss-help at mail.osgeo.org
>
>
>
--
More information about the Discuss
mailing list