[OSGeo-Discuss] Mobile GPS data collection...
mateusz at loskot.net
Mon Jul 31 23:54:45 PDT 2006
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
> 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
> 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
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
>>> 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
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
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.
More information about the Discuss