Feedback/comments regarding the proposed Open GeoSMS Standard.
http://www.opengeospatial.org/standards/requests/76
PART A1. Evaluator: Rob Manson
Managing Director
http://mob-labs.com 2. Submission: OGC 11-030 : Open GeoSMS Standard - Core
PART B1. 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: 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/P... (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 parametersThis 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 extrasThis 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.
