[X3D-Public] revised GpsSensor node proposal

[Don Brutzman]

Myeong Won Lee made a convincing presentation on Tuesday at the Web3D Korea Chapter
meeting that GPS support needs to be provided in the near term to support the
planned X3D Mobile Profile.  In-depth discussions have led to the following
revised proposal, which will be kept up-to-date on the member wiki as our
thinking and consensus-building progresses.

Thanks also to Dick Puk, Byounghyun Yoo, Anita Havele and Gun Lee for review and
discussion.

So it looks like the X3D Earth working group has a bit more to do in the coming month
to finalize our inputs to X3D version 3.3... happy holidays!

Detailed review comments welcome.

http://www.web3d.org/membership/login/memberwiki/index.php/X3D_v3.3_Specification_Changes#GpsSensor_node

_GpsSensor node_

GPS sensing devices have been stable for many years. GPS inputs are very useful for animating X3D scenes. GpsSensor will be a valuable addition to the forthcoming X3D Mobile Profile.

Status. Active review and refinement needed by X3D Earth and X3D Working Groups in order to be ready for X3D v3.3.

Use cases. The definition of use cases helps define the requirements and field data types for this new node.

    1. Primary common use: ROUTE the GPS position_changed to GeoLocation or GeoTransform position field.
    2. What are outputs if no GPS signal is available, or if the author wants to deliberately ignore values? The typical X3D way to handle these kinds of usage is with isActive and enabled fields. Thus GpsSensor should inherit X3DSensorNode interface.
    3. Exposing date/time of new position record may be helpful for animations. Thus need timeStamp field.
    4. May want to play back an NMEA file of GPS data points from memory. Thus need url field.
    5. Author may want to use a Script node to examine each data record individually. Thus need data_changed field.
    6. Local world coordinates. Sometimes an author might want to get an offset from a nearby location, in order to ROUTE a single-precision relative translation to a regular (non geospatial) Transform node. This use case assumes a local flat Earth, Cartesian X-Y-Z coordinate system. Thus need localOrigin and offset_changed fields.
    7. The previous use case also permits playback of position changes from a file to a different baseline location, as well as insertion into a differently scaled virtual world.
    8. Vertical height issues can be a bit tricky; older GPS receivers might not provide an estimated altitude. GPS vertical accuracy is less than surface latitude-longitude accuracy by design. Good accuracy requires multiple satellites and extra computational effort. Some GPS receivers sometimes improve vertical accuracy by using an air-pressure sensor; the absolute height is rarely accurate (since barometric pressure changes, slowly) but real-time changes in pressure can provide a rapid measure of altitude changes. Advanced GPS receivers can therefore use Kalmann or other filter techniques to accurately estimate altitude changes. Meanwhile, an author may want to deliberately ignore altitude changes completely since any error might put an object underground or up in the air. Script filtering of altitude is simple but nevertheless clumsy and error prone. Thus a boolean clampAltitude field is needed when the vertical Y component needs to be locked at 0.

  25.3.12 GpsSensor
  
  GpsSensor : X3DSensorNode {
    SFString [in,out]   description       ""
    SFBool   [in,out]   enabled           TRUE
    SFBool   [out]      isActive
    SFNode   [in,out]   metadata          NULL        [X3DMetadataObject]
  
    SFVec3d    [out]    position_changed       (-∞,∞)
    MFString   [in,out] url               []   [URI]
    SFString   [out]    data_changed      ""   NMEA format
    SFTime     [out]    timeStamp
  
    SFVec3d    [in,out] localOrigin            (-∞,∞)
    SFVec3f    [out]    offset_changed         (-∞,∞)
    SFBool     [in,out] clampAltitude     FALSE
    [...]
  }

Next steps.

     * Position and other primary outputs are unlikely to change significantly in the foreseeable future. Thus there no strong rationale for delaying this node further.
     * We will ask the principal contributors to the X3D Augmented Reality (AR) Component (which includes Mixed Reality elements) to review this node and confirm that it can be finalized without risk of needing additional changes when planned contributions to the AR profile are harmonized.
     * If AR implementers agree that the node signature is satisfactory and compatible with their approaches, then we can proceed with including GpsSensor in X3D v3.3.

TODO

     * Match other common GPS output values, as appropriate.
     * What about computed speed and direction? Different ways of filtering or deriving such values exist. How might an author ROUTE such results (i.e. what are the X3D use cases)?
     * Link to updated version of Myeong Won Lee's proposal. GPS Boundary values node not needed since such information is redundant.
     * Additional references
           o NMEA format appears to be primary reference, are there any others?
           o Is there an OGC specification to reconcile the common denominator for various formats/APIs?
           o W3C geoLocation API?
     * We need a native implementation in this node in an X3D browser to test/evaluate.
           o InstantReality proposal (NEMA Device, Tutorial on serial communication)
           o If there is some relevant example code, NPS could look at adding to Xj3D and X3D-Edit.
           o Others?
     * If utility functions are commonly needed to further filter or convert GPS output values, then a utility prototype might be created in order to gain authoring experience and determine best practices.

Deferred. The following goals are more appropriate for forthcoming Augmented Reality (AR) working group.

     * Node coverage for tilt, AccelerometerSensor and Compass magnetic heading
     * Indoor positioning systems and other trackers
     * If changes are made to the X3D sensor interface hierarchy, then this signature can be refined when other sensors are refactored

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br      brutzman at nps.edu
Watkins 270   MOVES Institute, Monterey CA 93943-5000 USA  +1.831.656.2149
X3D, virtual worlds, underwater robots     http://faculty.nps.edu/brutzman