<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Mateusz Loskot wrote:
<blockquote cite="mid44CDD758.4030609@loskot.net" type="cite">
<pre wrap="">Hi All,
Bob Basques wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
Open Mobile Objects<br>
<blockquote cite="mid44CDD758.4030609@loskot.net" type="cite">
<pre wrap="">
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
</pre>
</blockquote>
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..<br>
<blockquote cite="mid44CDD758.4030609@loskot.net" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
Good Plan I think.<br>
<blockquote cite="mid44CDD758.4030609@loskot.net" type="cite">
<pre wrap="">On top of the core, we can develop GUI widgets (map canvas, legend,
etc.) for specific environments, etc.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid44CDD758.4030609@loskot.net" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">My database of choice for the storage, at least for points, would be
MYSQL, much lower overhead for storage and retrieval.
</pre>
</blockquote>
<pre wrap=""><!---->
I vote for SQLite :-)
Though, I've never used MySQL on mobile devices.
</pre>
</blockquote>
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?<br>
<blockquote cite="mid44CDD758.4030609@loskot.net" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Hmm, wouldn't usage of regular PC limit spreading our project?
I think full mobility is only possible to achive with mobile devices.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid44CDD758.4030609@loskot.net" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
This is certainly something that should be possible with the utitlies
approach.<br>
<blockquote cite="mid44CDD758.4030609@loskot.net" type="cite">
<pre wrap="">
In both versions, remoting could be based on SOAP.
I'm looking forward your comments.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<br>
bobb<br>
<blockquote cite="mid44CDD758.4030609@loskot.net" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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)
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
</body>
</html>