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

[Mateusz Loskot]

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.

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

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.
On top of the core, we can develop GUI widgets (map canvas, legend,
etc.) for specific environments, etc.

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

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

> 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

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.

> 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
-- 
Mateusz Loskot
http://mateusz.loskot.net