[OSGeo-Discuss] Mobile GPS data collection, summary of sorts.

[Mateusz Loskot]

Bob Basques wrote:
> All,
> 
> Just a short summary of things so I can group them for reply . . .
> 
> Field User Survey:
> 
> I agree with this line of thinking.  The Field(end) users should be 
> surveyed to find out what they would like.  But I also think this 
> survey process works much better once they have something to play off
>  of during the questioning.  A BETA version for example would help
> out with this type of process.  In my experience, the Field changes
> are mostly centered on the Styling and organization of the View
> (still styling) and not much related to the basic functionality.  I
> would propose building a BETA version first, and using a working
> model to solicit reviews.

I have an impression that doing a end users survey is quite difficult
operation at current stage of our project (idea of project).
Organizationally it would be easier to start-up with development of a
prototype and then do some survey, even online (download, try and give
us some comments).

About 3 years ago when I started to work on mobile applications for
forestry in Poland, my team was really determined to do such a kind of
end users survey and we did one. Unfortunately, the outcome was quite
poor. The main reason was that our idea was very very new for our
potential users, mostly non-technical people. So, it was very difficult
for them to imagine what a mobile application is, how could they use it,
what benefits would they get, etc.
So, we decided to spend a few months to release first version. Then, we
send it to ~30 clients. After some time, we did the survey again and
this time it was much more effective. User had very detailed comments.

I know the "make prototype first, then ask" is not a very common (or not
according to requirements definition and management standards) project
lifecycle in a software business, but currently starting up with a
survey would be difficult.

So, Bob's (and Dave's in previous posts) suggestion is reasonable
for me.

> Development of a BETA package for Mobile Data capture:
> 
> The CLI approach seems to most sane to me.  This will most like 
> change over time with some of the seperate utilities being combined 
> into bigger and better things later on.  One reason I like this 
> approach is that it's very easy to segment the utilities into smaller
>  work area/groups.  As long as a good Comm directive is followed, ann
>  utilities should work in harmony together.  This "Utility" approach 
> also affords us the opportunity to work precisely on the things that 
> need to be worked on, while at the same time using the tools already 
> developed for other things.

What about the idea of modularized package + UI, for example command
line interface at the first stage?


>    Related to the above is the question of what build.
>    I keep pointing
>    to LINUX as the first version of things because it will require the
>    least amount of NEW work to get a prototype operational.
> Basic requirements (as I see them):
>
>    Every Device that is considered for porting, should have:
>
>        * Have a Web Server of some sort (in the near term, nothing
>          exotic should be attempted on the LINUX side, just keep it
>          short and sweet so that the capabilities are easier to port
>          to other OS's.

What is the idea of communication, could you elaborate?

>        * Have a way to Connect to the Internet, Cradle(landline),
>          Bluetooth, etc.

Yes.

>        * Have a Web Browser that has at least some Javascript
>          capabilities, (most do, BTW, although most are also
>          incomplete when talking about what features they support,
>          don't support)

Yes, though it may be a problem with portability.
What Web browsers do you consider?

>        * These might be optional items
>           * Have a way of generating a Map, even in a simplified
>             form as a standalone operation.

What does "generate a map" means?
Do you mean it should be able to display map on a device screen?

>            * Have a way of connecting to a GPS (Bluetooth,other, etc)

Most of today devices does have BT or connection slots.

>            * Have a way of connecting to a Digital Compass(bluetooth,
> etc)

OK.

>            * Have a way of connecting to a Digital Camera (etc.)

OK

>            * Have a way of connecting to a AVL hardware stack ??(etc.)

I'm not experienced with technical specification of AVL but OK :-)

>            * This list is likely to get much longer I would imagine.

Yes

>    If we can agree to the above, then what we'll need to build (short
>    list):
>
>        * Collection format for the data (Points only to start with?)

What does "collection format" means?
Is this about log GPS locations or also from manual map editing?

>            * Database, Flat File, etc.

IMHO one of the most important requirement is insert/update/query
performance with good indexing.
So, I'd stick to SQLite.

>            * Time indexing.

OK

>        * Server comm LIB, Main (MotherShip) to Secondary (Attack
>          Fighter) web servers.
>            * Syncing of captured data points
>            * Syncing of Mapping data between servers fore
>                re-distribution.
>        * Daemon (listener) to monitor GPS (could be a wrapper around
>          any of the options already available for reading
>          GPS devices.) coordinate locations, and other digital
>          devices, Compass, etc.

As Paulo has suggested, gpsd should work well.

>        * Some sort of GUI (web Based, even when running standalone)

Do you mean it will be a JavaScript/AJAX application>

>        * MapService, for providing Automated location services.

I imagine it can be one of the biggest problem to find/create services
infrastructure.

> Default Operations (My predictions only):
>
>    * Map data snycing between MotherShip and Fighters - AUTOMATIC in
>      the background, while a connection is made with the remote device

Yes

>    * GPS Listener - AUOTMATIC in the background while a connection is
>      made with the remote device

Yes

>    * User GUI, limited to basic functions, Picking Points, Choosing
>      from pulldown list, etc.

Yes

>    * Collected Data Syncing between servers, AUTOMATIC - When
>      connection available, AUTOMATIC caching when the connection is
>      not available

Yes

>    * Mapping System runs automatically based on GPS coordinates read,
>      always on (once the page is opened) and able to move the map
>      accordingly (this might take a bit of work BTW.  Although the
>      local WebServer will help out a bunch with this.

So, it seems AJAX is reasonable here.

> There are a bunch of details I'm glossing over here, but I think this
> could be a start for pulling a project proposal out of.

Although it's hard for me to comment a Web-based interface for
GPS-driven application for data collecting, I think the plan is good.

Here are my additional questions:
1. What's the suggested development platform for the prototype?
2. Are we still going to create and use underlying core components for
data accessing, processing, analysing, computing, etc?
3. What about services infrastructure?

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