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

[Bob Basques]

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.

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.

    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.
        * Have a way to Connect to the Internet, Cradle(landline),
          Bluetooth, etc.
        * 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)
        * These might be optional items
              o Have a way of generating a Map, even in a simplified
                form as a standalone operation.
              o Have a way of connecting to a GPS (Bluetooth, other, etc)
              o Have a way of connecting to a Digital Compass(bluetooth,
                etc)
              o Have a way of connecting to a Digital Camera (etc.)
              o Have a way of connecting to a AVL hardware stack ??(etc.)
              o This list is likely to get much longer I would imagine.

    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?)
              o Database, Flat File, etc.
              o Time indexing.
        * Server comm LIB, Main (MotherShip) to Secondary (Attack
          Fighter) web servers.
              o Syncing of captured data points
              o 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.
        * Some sort of GUI (web Based, even when running standalone)
        * MapService, for providing Automated location services.

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
    * GPS Listener - AUOTMATIC in the background while a connection is
      made with the remote device
    * User GUI, limited to basic functions, Picking Points, Choosing
      from pulldown list, etc.
    * Collected Data Syncing between servers, AUTOMATIC - When
      connection available, AUTOMATIC caching when the connection is not
      available
    * 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.

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.

bobb