[Requests] Comments submission on the Open GeoSMS Standard

Rob Manson roBman at mob-labs.com
Sun Apr 24 00:29:41 EDT 2011


Feedback/comments regarding the proposed Open GeoSMS Standard.
http://www.opengeospatial.org/standards/requests/76

PART A
1. Evaluator:

        Rob Manson
        Managing Director
        http://mob-labs.com
        roBman at mob-labs.com 
        

2. Submission:

        OGC 11-030 : Open GeoSMS Standard - Core


PART B
1. Requirement:

        Allowing support for alternate Coordinate Reference Systems

2. Implementation Specification Section number:

        Section 1 - Introduction of OGC 11-030 defines:
        
                "Based on the OGC WMS (Web Map Service) approach for
                expressing coordinates [2], the location information in
                Open GeoSMS uses latitude/longitude 2d expressed in
                decimal degree as defined in the WGS84 [3] coordinate
                reference system."
        
        Section 3 - Normative references refers to:
        
                [3] WGS 84 Earth Gravitational Model website, available
                at
                <http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_wgs84.html>
                
        5.1.3. Requirement 3: Location Parameter (Mandatory) defines:
        
                "The value of the latitude and longitude shall be
                described using the Decimal Degree format based on
                WGS84"

3. Criticality:

        Major

4. Comments/justifications for changes: [Comments]

        The NGA's own definition page for WGS-84 states that it is
        "valid up to about 2010" - a date which is already in the past.
        
                The National Geospatial-Intelligence Agency develops,
                maintains, and enhances the World Geodetic System 1984,
                the reference frame upon which all geospatial
                intelligence is based.
                World Geodetic System 1984 (WGS 84)
                The World Geodetic System defines a reference frame for
                the earth, for use in geodesy and navigation. The latest
                revision is WGS 84 dating from 1984 (last revised in
                2004), which will be valid up to about 2010.
                https://www1.nga.mil/ProductsServices/GeodesyGeophysics/WorldGeodeticSystem/Pages/default.aspx
                (Retrieved April 24, 2011)
                
        It's obviously pragmatic to use WGS-84 now while also allowing
        alternate Coordinate Reference Systems (CRS) in the future.
        Simply adding an optional CRS parameter would help to future
        proof this proposed GeoSMS standard.
        


1. Requirement:

        Allowing support for an optional Altitude parameter

2. Implementation Specification Section number:

        5.1.3. Requirement 3: Location Parameter

3. Criticality:

        Major

4. Comments/justifications for changes:

        As indoor location based services become more usable and more
        used the importance of altitude based parameters will become
        more significant.  Identifying the floor or level that a person
        is on will be key to certain services that have not yet been
        fully defined.  Allowing this optional third parameter would
        help to future proof this proposed Open GeoSMS Standard.



1. Requirement:

        Allowing support for an optional Uncertainty parameter
        
2. Implementation Specification Section number:

        5.1.3. Requirement 3: Location Parameter
        
        6. Example
        
3. Criticality:

        Major

4. Comments/justifications for changes:

        One of the major drawbacks with location based services
        currently is the variable nature of the accuracy or uncertainty
        of the coordinates provided by consumer level GPS devices like
        mobile phones.  In the example provided in section 6. of the
        proposed Open GeoSMS Standard document it would be very helpful
        for the towing service to know if the location provided was very
        accurate or only roughly within 200m.  If a user is indoors or
        even under debris, yet still relying on GPS data then the level
        of uncertainty can be significant.  In a rescue situation or
        when collecting forensic information this value can be even more
        important.  Since this value is often available it seems overly
        restrictive to exclude an optional uncertainty parameter.


Summary:
The geo: URI format proposed in RFC5870 addresses all of the comments
outlined above.  Here is an example based on the examples provided in
sections 6.1 and 6.2 of RFC5870. http://tools.ietf.org/html/rfc5870

        geo:48.198634,16.371648,183;crs=wgs84;u=40

By contrast, here is the example URI included in section 6. of the
proposed Open GeoSMS Standard.

        http://maps.geosms.cc/showmap?geo=23.9572,120.6860&GeoSMS

This could be adapted in one of two ways to support the comments above.

1. add additional optional parameters
This brings the Open GeoSMS URI inline with RFC5870 by adding the
optional altitude third parameter and then optional crs and u key/value
pairs.

        http://maps.geosms.cc/showmap?geo=23.9572,120.6860,183&crs=wgs84&u=40&GeoSMS

2. extend the existing geo parameter with additional extras
This first adds the extra optional altitude parameter as a third element
in the comma separated section after the geo=
It then adds the crs and u parameters but instead of separating them
with the normal & it uses an equally valid ;
In these optional extra key/value pairs the = is replaced with a :
  
        http://maps.geosms.cc/showmap?geo=23.9572,120.6860,183;crs:wgs84;u:40&GeoSMS

Both of these proposed extensions would leave the example URI provided
in section 6 of the proposed Open GeoSMS standard as valid while also
allowing improved features, functionality and potential future proofing.


"ORDERING" NOTE: 
I would also comment that the order dependency described in "5.1.2.
Requirement 2: Postfix String" and "5.1.3. Requirement 3: Location
Parameter" seems a little arbitrary and restrictive.  URI query strings
are generally treated as simple collections of key/value pairs with no
firm expectation that ordering will be preserved.  Many web based
libraries, proxies and tools may adjust this data so it seems risky to
impose an ordering requirement when it is not technically essential for
valid parsing.  For example the mere presence of the GeoSMS key in the
query string is just as informative as a &GeoSMS query string suffix.

"NO POST" NOTE:
I would also comment that only supporting GET and not POST is quite
limiting and may breach some security policies.  GET request parameters
often end up in access logs which can expose private location data in
unexpected ways.  Using POST as an alternative HTTP method should be
allowed and is a perfectly valid and standards compliant solution.

Taking these two NOTEs into account would result in a more flexible Open
GeoSMS standard that retains it's current structure while also being
more in line with existing web standards and approaches.


-- 
Rob Manson
Managing Director

MOB - start something!

The Mobile & Online Business innovation lab
http://mob-labs.com

m: +61423215731
e: roBman at mob-labs.com
l: http://linkedin.com/in/robertmanson
t: http://twitter.com/nambor
s: http://slideshare.net/robman 


----------------------------------------------------------------------------------
Checkout our site at http://mob-labs.com or on your mobile at
http://mob-labs.com or on your iPad at http://mob-labs.com
----------------------------------------------------------------------------------




More information about the Requests mailing list