[OSGeo-Discuss] Mobile GPS data collection...

[Bob Basques]

Mateusz Loskot wrote:
> Hi All,
>
> Bob Basques wrote:
>   
>> I think the route to go with something like this, is NOT to use a 
>> specific portable OS, but rather concentrate on using a Micro PC of
>> some sort (the OQO with Linux, comes to mind) and use the same old
>> tools we've been using for everything else.
>>     
>
> I'd like to lay stress on portability.
> Here is a draft:
>
> 1) core - a highly portable library of core GIS features (Mobile GIS
> Core), something like Mobile Feature Data Objects (named after FDO ;-)),
> Mobile GIS Analysis Objects, etc.
>   
Open Mobile Objects
> 2) UI - the Mobile GIS Core should be available to use with whatever UI
> toolkit user wants to use, so:
>
> a) for Windows CE-based platforms it can be ATL/WTL or MFC or plain
> Win32 API or .NET Compact Framework (through P/Invoke)
> or wxWidgets  or...
>
> b) for Linux-based platforms similar situation should be possible, so UI
> can be made with QT or GTK or wxWidgets or even command line interface
>   
I like the idea of a command line version (AKA a CGI), somehow appeals 
to me.  Might even be a set of command line utilities the more I think 
about it, this would allow for the developer to only load the pieces 
they need to use vs everything everytime.   H m m m m..
> c) mobile phones could use it from Java
>
>
> NOTE: According to my knowledge and experience, it's almost impossible
> to find well-working portable UI for wide variety of mobile devices and
> OSs variation. So, the portability should be achived through
> component-based architecture not tight with specific GUI.
>   
Good Plan I think.
> On top of the core, we can develop GUI widgets (map canvas, legend,
> etc.) for specific environments, etc.
>   
I'm still thikning that I would prefer to use a Web Interface for this, 
especially with this Command line version of things. Using the Utilities 
Grouping approach, it would be easy enough to string together operations 
for example and also allow for enhancements to the set of utilities over 
time.
>   
>> My database of choice for the storage, at least for points, would be
>> MYSQL, much lower overhead for storage and retrieval.
>>     
>
> I vote for SQLite :-)
> Though, I've never used MySQL on mobile devices.
>   
I hate to keep hearing statements like mobile devices, A portable 
computer is a mobile device (of sorts) and fully capable of running 
MySQL.  The WKT option could also be used for the mobile data stores, 
even in a raw form.  Realistically, how much data will be stored on a 
portable device before need (or wanting) to sync it up with the mothership?
>   
>> The Mapping side is a different story, but speed and simplicity would
>> be the order of the day.  While there's no reason a Spatial database
>> couldn't be used for the mapping, I would suspect that the management
>> of the mapping data might be easier with static SHP files in the near
>> term.  Although using a Regular PC OS would help with database up
>> keep in the syncing process as well.
>>     
>
>
> Hmm, wouldn't usage of regular PC limit spreading our project?
> I think full mobility is only possible to achive with mobile devices.
>   
I don't think so, if we got the route described previously of setting up 
a core set of utilities, these tshould be much easier to port to 
different OS's then say a fully capable GUI.  Although I would suggest 
that most portable based web browsers are capable of ahndling any basic 
interface that can be served from a Web Server.
>   
>> Also, don't forget, for a well rounded out system, the MapServer on
>> the portable device should able to update it's Datasets for the
>> mapping side of things in a cascading manner every time the Home and
>> Field machines sync themselves.  It's not just the collected data you
>> need to worry about.  One good example of why this is a good idea to
>> implement, would be when you have a group of folks all capturing data
>> in the same general area, where each needs to see what the other has
>> been doing.  A live system would work very well for this, but even
>> manually syncing things every day would show what each operator had
>> captured the previous day. The same situation occurs when multiple
>> groups are using the same system but depend on one another for the
>> data they are capturing in performing their respective business
>> function(s).
>>     
>
>
> I'm inclined to specify two following business logics:
>
> 1) Standalone GIS application for mobile devices
> - local datastore
> - local mapping engine
> - dedicated application with it's own GUI, no webbrowser usage
>
> 2) Remoting GIS for mobile devices:
> - application *only* acts as a client, no services are running on the device
> - User Interface possibilities:
> --- standalone GUI - data downloaded from and uploaded to remote
> datastore;all GIS functionality is client-only; data already queried is
> stored in the local (cache) datastore
> --- Web browser GUI - data streamed as above, but there is no local
> cache datastore; GIS functionality is provided by remote services
>   
This is certainly something that should be possible with the utitlies 
approach.
> In both versions, remoting could be based on SOAP.
>
> I'm looking forward your comments.
>
>   
>> Lastly, and more related to a live updating system, would be the 
>> Communications aspects between the servers.  In an always on system 
>> where there is a high level of wireless connectivity, each user
>> should be able to view every other users input items as they become
>> available. This will require some thought as well, since the
>> communication will need to go in both directions.  Think about two or
>> three field personnel capturing data in a grid pattern next to each
>> other and being able to see the input of the others as it occurs.
>> The data should still be plotted in real time on the portable device
>> even if it's only manually synced as well, while the communications
>> between server can be controlled a bit easier in this manner, the
>> same requirements will exist.
>>     
>
> Am I correct the idea is to give ability to show person B changes
> uploaded by person A and C, and vice versa, in the field?
>
> Nice idea, but I think connectivity requirements should be specified
> well. In example, foresters in Poland has access only to GPRS
> connection, with pretty low bandwidth.
>   
Depending on the data retrieved (no Photographs for example, actually 
they could be captured, but only available to everyone after syncing, 
and the metadataq would be available at just about Live update speeds.  
GPRS would be plenty fast for something like this, especially if the 
processwere running in the background in an automatic mode.

bobb
>   
>> The reasoning behind my preference for concentrating on a regular OS 
>> (Not portable specific) would be that these micro portables are only 
>> going to get smaller and more plentiful in the future.   There is
>> also the notion that lessons learned from the building of things in
>> the described process would help those that want to ignore the advice
>> and develop on the portable specific OS anyway.  :c)
>>     
>
> My hope is that if there would be provided:
> - common components design
> - common architecture
> - common and portable implementation of core components
>
> then we could be pretty sure to find developers interested in building
> high-level components for wide variety of platforms.
> In example, we could have branches/subprojects/working-goups of our Open
> Source GIS devoted to every platform:
> - Windows CE
> - Linux
> - mobile phones/Java
> - ...
>
> These groups would be able to share ideas, design, implementations,
> experiens or even developers (one developer can work for more than one
> working group). Am I an idealist? Hehe
> May be, but that would be great to develop such infrastructure.
>
> Cheers
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20060731/071e671c/attachment-0001.html>