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

[Mateusz Loskot]

Bob Basques wrote:
> Mateusz Loskot wrote:
>> 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

I like it.

>> 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..
> 
> 
> 
> 
Yup, me too. On Linux PDA there is no problem with CLI, but it's not
very common on Windows CE though Microsoft provides Command Prompt to
download and install on the mobile device.

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

Unix-like philosophy of a bunch of small utilities is my favourite, but
I'm not sure about user-friendly integration of it on mobile device.

Please, could you elaborate/describe your idea about Web UI + command
line utils, so it would be easier to imagine how it would work.

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

Portable device without an Operating System is an unusable piece of
plastic and metal :-)
So, we really need to get an idea about software platform we're going to
target. Then we will be able to answer user's questions like this
"Can I run your mobile GIS app with MySQL database on my iPod?"

> The WKT option could also be used for the mobile data stores, even in
>  a raw form.

I'm pretty sure about low performance of text files storage or sth like
that. I've tested XML data storage on Windows CE and it poorly performs.

> Realistically, how much data will be stored on a portable device 
> before need (or wanting) to sync it up with the mothership?

That's a good question.
I don't know about general tendency, but I can say from my own
experience in mobile applications for forestry.
Forest inventory application with GIS capabilities I worked on uses
SQLite database of size 20-80 MB.
So, it's possible user will query for e.g. 6000 records and we have to
populate grid view with such a huge amount of data.
Using SQLite + C++ language gave us very good results (5-10 seconds to
run query and populate the list.

Querying XML file for tens of records in .NET CF and C# took 5-10
seconds too.

Both applications was tested on Windows CE 4.2 and 5.0 with CPU 300-600
MHz and 64-180 MB of RAM.

I know it does not answer your qustion, but I hope it is a kind of good
case study.

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

What portable web browsers do you think about?
I tested Minimo (http://www.mozilla.org/projects/minimo/) in Windows
CE-driven device with 400Mhz and 64 MB RAM and it worked quite slow.

Internet Explorer on this device was too limited in features to run
complex JavaScript based app.

Finally, I think targeting common PC/laptop with Windows XP/Linux
desktop does not make a big sense, because there are already working
applications like uDIG, Quantum GIS and others. Or I've not understood
your point correctly :-)

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


Yes, you're right.


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


OK, that would be great to be possible to use low-bandwidth Internet
connection like GPRS with our application we're planning now.


Best regards
-- 
Mateusz Loskot
http://mateusz.loskot.net