[OSGeo-Discuss] Mobile GPS data collection, summary of sorts.

[Bob Basques]

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
>