Thanks for the response and care consideration of the 6709 issue. I
understand your reasoning and if OK with you pass on your reasoning to NOAA.
Yes, the original 6709 is quite old but there is actually a much newer
version (2 years old or so) that includes an informative annex of XML
encodings for 6709:2008.
Regards
Carl
----- Original Message -----
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Carl Reed" <creed@opengeospatial.org>; "Alexander Mayrhofer"
<alexander.mayrhofer@nic.at>; "Ivan Shmakov" <oneingray@gmail.com>;
<geopriv@ietf.org>
Sent: Tuesday, May 11, 2010 11:02 PM
Subject: ISO 6709 (was: [Geopriv] a few tweaks to
draft-ietf-geopriv-geo-uri-07)
> Thanks Carl.
>
> I'll be the first to admit ignorance of ISO 6709, which was a bit of a
> blind spot.
>
> My reaction to the suggestion that the two be aligned is a little
> conflicted.
>
> On the one hand, it's a trivial matter to alter the syntax of the URI. On
> the other, we'd have to be happy that there was an interoperability gain
> in doing so.
>
> The ISO 6709 syntax is relatively easy to understand, so no great problem
> there. But it is also another example of the (braindead)
> degrees-minutes-seconds syntax that should have long been eradicated from
> protocols [1].
>
> Thus, I'd be OK with a simplification along these lines:
>
> URI = "geo:" 1*number *options
> number = ( "+" / "-" ) 1*DIGIT [ "." *DIGIT ]
>
> It even saves a character here and there. It's mostly ISO 6709
> compatible.
>
> The trailing slash and the DMS notation aren't useful. Since a slash in a
> URI has a specific meaning, so we'd have to drop that. The DMS encoding
> is actually harmful.
>
> Compatibility on CRS might be possible, but embedding a URI might be hard,
> and we can't use angle brackets.
>
> With all these caveats, it's hard to see there being much interoperability
> benefit in trying to align the two formats. As I see it, transcoding is
> relatively trivial anyway.
>
> As for the other comments,
>
> There's probably some benefit in clarifying the vertical aspects (though
> it is obvious to me that height == negative depth, perhaps I'm not
> qualified :).
>
> The suggestion to allow for polygon region representations goes beyond the
> remit of the work; two alternatives: extensions are allowed, though this
> might stretch the definitions somewhat, or you can use a location URI
> [RFC5808].
>
> --Martin
>
> [1] I notice that ISO 6709 is almost 30 years old now, so I guess we have
> to forgive them for that.
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of Carl Reed
>> Sent: Wednesday, 12 May 2010 2:15 AM
>> To: Alexander Mayrhofer; Ivan Shmakov; geopriv@ietf.org
>> Subject: Re: [Geopriv] a few tweaks to draft-ietf-geopriv-geo-uri-07
>>
>> I know that it is very late in the process, but such is the world of
>> standards :-) Getting non IETF community folks to thoroughy read an
>> IETF
>> document and comment takes time.
>>
>> So, please take the following comments and suggestions as positive
>> input
>> into the process and adjudicate them as deemed appropriate.
>>
>> From Joint Research Council (JRC) and CSIRO - a clarification:
>>
>> The draft RFC says that EPSG 4979 should be used for 3-D. According to
>> the
>> EPSG database, CRS 4979 uses the coordinate system 6423, for which the
>> definition reads
>> 'Ellipsoidal 3D CS. Axes: latitude, longitude, ellipsoidal height.
>> Orientations: north, east, up. UoM: degree, degree, metre.' i.e. it is
>> +ve
>> up. So heights displaced down from the datum will be negative numbers.
>>
>> From the Global Biodiversity Community (GBIF) - request for
>> clarification
>> and a correction edit.
>>
>> I'm curious about the altitude field. I assume the standard is not just
>> for
>> the terrestrial realm so, for a marine location, is depth meant to be
>> depicted as negative altitude?
>> See here for a standard that distinguishes between altitude and depth:
>>
>> http://plantnet.rbgsyd.nsw.gov.au/HISCOM/HISPID/HISPID3/H3_location.htm
>> l
>>
>> In regard to altitude -
>>
>> "Negative values indicate terrestrial altitudes below sea level
>> (depressions), not aquatic environments or caves (refer Depth field
>> below).
>> A negative altitude must be preceded by a minus sign, without a space.
>> The
>> plus sign for positive altitudes should be omitted."
>>
>> From Universitetet for miljø- og biovitenskap, Norway - suggested title
>> change to reflect content of document
>>
>> This RFC only covers geographical point locations (or if one uses the
>> uncertainty attribute - it could be used to represent circular areas).
>>
>> The RFC should therefore change name accordingly. To defend its current
>> name, I think that the RFC should also cover lines and regions
>> (polygons in
>> 2D). Or at least provide an opening for future extension of the RFC.
>>
>> Lines are useful for representing the geographical location of for
>> instance
>> rivers, roads and air line routes.
>>
>> Regions are useful for representing the geographical location of most
>> "places", such as administrative areas, mountain ranges, settlements
>> and
>> parks.
>>
>> From US National Ocean and Atmospheric Administration (NOAA) and
>> International Instruments - harmonization potential with widely
>> implemented
>> ISO standard:
>>
>> The proposed URIs have the form (see section 6.1 of the RFC)
>> geo:48.2010,16.3695,183 (without CRS specified)
>> geo:48.2010,16.3695,183;crs=wgs84 (with explicit CRS)
>>
>> This differs needlessly from the plain-text format defined by ISO 6709,
>> "Standard representation of geographic point location by coordinates."
>> I
>> recommend that either ISO 6709 representation be adopted by geo: URIs,
>> or
>> that the authors clearly explain in Section 3.7 "Interoperability
>> Considerations" why they have failed to consider interoperability with
>> ISO
>> 6709.
>>
>> If the proposed RFC were to be compatible with ISO 6709, the example
>> above
>> would instead be written something like the following:
>>
>> geo:+48.2010+16.3695+183/ (without CRS)
>> geo:+48.2010+16.3695+183CRS<urn:ogc:def:crs:epsg::4326>/ (with CRS)
>>
>> From the UK Ordnance Survey - Comment and a question
>>
>> Is it reasonable to "identify" a point in a continuum, particularly
>> where
>> there are many equivalent identifiers that could be expressed for the
>> same
>> point?.
>>
>> Internally in OS, I summarised the IETF approach as "straightforward
>> enough, for those occasions when one wants to express a simple WGS-84
>> point
>> position in a compact text form." and in competition with ISO 6709.
>>
>> It may also be worth asking about the relationship between this 'geo
>> URI'
>> and their RFC 5139 (VoIP 999, which uses GML3 for positions in an XML
>> encoding), and builds on IETF RFC 4119 (GEOPRIV)
>>
>> Notice that if the geo-uri document is harmonized with 6709, then a key
>> criticism of the current approach is removed.
>>
>> Regards
>>
>> Carl
>>
>>
>>
>> ----- Original Message -----
>> From: "Alexander Mayrhofer" <alexander.mayrhofer@nic.at>
>> To: "Carl Reed" <creed@opengeospatial.org>; "Ivan Shmakov"
>> <oneingray@gmail.com>; <geopriv@ietf.org>
>> Sent: Monday, May 03, 2010 9:55 AM
>> Subject: RE: [Geopriv] a few tweaks to draft-ietf-geopriv-geo-uri-07
>>
>>
>> >
>> > Hm.
>> >
>> > Honestly, it is *very* late for comments and changes to the document.
>> It
>> > has passed working group last call a *long* time ago, was last called
>> > IETF-wide months ago, and has passed IESG evaluation a month ago.
>> >
>> > Which means that any changes that we instruct the RFC editors to do
>> now
>> > on the documents should be editorial ones, rather than affecting the
>> > content.
>> >
>> > I'm very open to suggestions of what could be improved, but i would
>> also
>> > rather not want to reopen the whole thing..
>> >
>> > Alex
>> >
>> >
>> >> -----Original Message-----
>> >> From: geopriv-bounces@ietf.org
>> >> [mailto:geopriv-bounces@ietf.org] On Behalf Of Carl Reed
>> >> Sent: Monday, May 03, 2010 5:52 PM
>> >> To: Ivan Shmakov; geopriv@ietf.org
>> >> Subject: Re: [Geopriv] a few tweaks to draft-ietf-geopriv-geo-uri-07
>> >>
>> >> And I have a number of comments and suggestions from the OGC
>> >> Membership that
>> >> I need to consolidate and submit. Some have to do with
>> >> clarification of the
>> >> CRS value definition and usage. This is important as some
>> >> countries, such
>> >> as China, have legal policies regarding CRS definitions for use in
>> >> applications deployed in China. Nothing arbitrary at all.
>> >>
>> >> And Ivan, I have a hard time following your suggested edits
>> >> and comments.
>> >> Perhaps my email scrambled things.
>> >>
>> >> Regards
>> >>
>> >> Carl
>> >>
>> >> ----- Original Message -----
>> >> From: "Ivan Shmakov" <ivan@main.uusia.org>
>> >> To: <geopriv@ietf.org>
>> >> Sent: Monday, May 03, 2010 9:44 AM
>> >> Subject: [Geopriv] a few tweaks to draft-ietf-geopriv-geo-uri-07
>> >>
>> >>
>> >> Glad to see that the specification have progressed further. I
>> >> wonder, wouldn't it be too late to suggest a few more tweaks?
>> >>
>> >> --
>> >> FSF associate member #7257
>> >>
>> >>
>> >>
>> >> --------------------------------------------------------------
>> >> ------------------
>> >>
>> >>
>> >> --- www.ietf.org/id/draft-ietf-geopriv-geo-uri-07.xml 2010-04-14
>> >> 23:31:04.000000000 +0700
>> >> +++ draft-ietf-geopriv-geo-uri-07-1272900834.xml 2010-05-03
>> >> 22:33:54.000000000 +0700
>> >> @@ -99,7 +99,7 @@
>> >> (WGS-84)</xref>. The scheme provides the textual
>> >> representation of
>> >> the location's spatial coordinates in either two or three
>> dimensions
>> >> (latitude, longitude, and optionally altitude for the default
>> >> - CRS of WGS-84). An example of such an 'geo' URI follows:</t>
>> >> + CRS of WGS-84). An example of such a 'geo' URI follows:</t>
>> >> <vspace blankLines='1'/>
>> >> <list style='hanging'>
>> >> <t>geo:13.4125,103.8667</t>
>> >> @@ -123,7 +123,7 @@
>> >> intended to cope with the case of another CRS
>> >> replacing WGS-84
>> >> as the predominantly used one, rather than allowing
>> >> the arbitrary
>> >> use of thousands of CRSes for the URI (which would
>> >> clearly affect
>> >> - interopability). The definition of 'crs' values
>> >> + interoperability). The definition of 'crs' values
>> >> beyond the default of "wgs84" is therefore out of scope of
>> >> this document.
>> >> </t>
>> >> @@ -203,11 +203,11 @@
>> >> </artwork>
>> >>
>> >> <t>Parameter names are case insensitive, use of
>> >> the lowercase
>> >> - representation is PREFERRED. Case sensitivity of
>> >> non-numeric
>> >> + representation is preferred. Case sensitivity of
>> >> non-numeric
>> >> parameter
>> >> values MUST be described in the specification of the
>> >> respective parameter. For the 'crs' parameter, values are
>> >> - case insensitive, and lowercase is PREFERRED.
>> >> + case insensitive, and lowercase is preferred.
>> >> </t>
>> >> <t>Both 'crs' and 'u' parameters MUST NOT appear more
>> than
>> >> once each.
>> >> @@ -370,7 +370,7 @@
>> >> and their values are bitwise identical after
>> >> percent-decoding.
>> >> </t>
>> >> <t>Otherwise, the comparison operation for the
>> >> respective
>> >> URIs
>> >> - is undefined (since the legacy implementation is not
>> >> + is undefined (since the legacy implementation would
>> not
>> >> be aware of the comparison rules for those
>> parameters).
>> >> </t>
>> >> </list>
>> >> @@ -382,7 +382,7 @@
>> >> MUST NOT be considered equal to a URI containing a
>> >> <coord-c>,
>> >> even if the remaining <coord-a>, <coord-b>,
>> >> - and their 'u' values are equivalent.
>> >> + and 'u' values are equivalent.
>> >> </t>
>> >> <t>For the default CRS of WGS-84, the following
>> >> comparison
>> >> rules apply additionally:
>> >> @@ -440,7 +440,7 @@
>> >> <xref target='examples'/>.
>> >> </t>
>> >> </section>
>> >> - <section anchor='uriinterop' title='Interopability
>> Considerations'>
>> >> + <section anchor='uriinterop' title='Interoperability
>> >> Considerations'>
>> >> <t>Like other new URI schemes, the 'geo' URI requires
>> >> support in client applications. Users of
>> >> applications which are
>> >> not aware of the 'geo' scheme are likely not able
>> >> to make direct
>> >> use
>> >> @@ -467,7 +467,7 @@
>> >> locations.
>> >> </t>
>> >> <t>The number of digits in the <coordinates>
>> >> values MUST
>> >> NOT
>> >> - be interpreted as an indication to a certain level of
>> >> + be interpreted as an indication of a certain level of
>> >> accuracy or uncertainty.
>> >> </t>
>> >> </section>
>> >> @@ -495,7 +495,7 @@
>> >> <t>This specification creates a new IANA Registry
>> >> named "'geo' URI
>> >> Parameters Registry" for the <parameter>
>> >> component of the
>> >> URI. Parameters for the 'geo' URI and values
>> >> for these parameters MUST be registered with IANA to
>> prevent
>> >> - namespace collisions, and provide interopability.</t>
>> >> + namespace collisions, and provide interoperability.</t>
>> >> <t>Some parameters accept values that are
>> >> constrained by a syntax
>> >> definition only, while others accept values from a
>> >> predefined set
>> >> only. Some parameters might not accept any values at
>> >> all ("flag"
>> >> @@ -504,7 +504,7 @@
>> >> that accept values from a predefined set.</t>
>> >> <t>The specification of a parameter MUST fully
>> >> explain the syntax,
>> >> intended usage and semantics of the parameter. This ensures
>> >> - interopability between independent implementations.</t>
>> >> + interoperability between independent implementations.</t>
>> >> <t>For parameters that are neither restricted to a set of
>> >> predefined
>> >> values nor of the "flag" type described above, the syntax
>> of
>> >> allowed values MUST be described in the specification, for example
>> >> @@ -522,11 +522,11 @@
>> >> <t>"No value": The parameter does not accept any
>> >> values, and
>> >> is to be used as a "flag" only.</t>
>> >> <t>"Predefined": The parameter does accept values from a
>> >> - predefined set only, as specified in a RFC or
>> >> other permanent
>> >> + predefined set only, as specified in an RFC or
>> >> other permanent
>> >> and readily available public specification.</t>
>> >> <t>"Constrained": The parameter accepts arbitrary values
>> >> that are only constrained by a syntax as specified in
>> >> - a RFC or other permanent and readily available public
>> >> + an RFC or other permanent and readily available public
>> >> specification.</t>
>> >> </list>
>> >> </t>
>> >> @@ -555,7 +555,7 @@
>> >> </t>
>> >> </list>
>> >> </t>
>> >> - <t>Note that the examples and use cases aboves
>> >> as well as in
>> >> + <t>Note that the examples and use cases above
>> >> as well as in
>> >> the next section are non-normative, and provided for
>> >> information
>> >> only.</t>
>> >> </section> <!-- end of URI Operations section -->
>> >> @@ -595,11 +595,11 @@
>> >> <t>Resolution of the URI returns the following
>> >> information:</t>
>> >> <vspace blankLines='1'/>
>> >> <list style='symbols'>
>> >> - <t>The 'crs' is given in the URI, and
>> >> sets the CRS used
>> >> in the URI to WGS-84 explicitely.</t>
>> >> + <t>The 'crs' is given in the URI, and
>> >> sets the CRS used
>> >> in the URI to WGS-84 explicitly.</t>
>> >> <t>The URI does omit <coord-c>, is hence
>> >> 2-dimensional, and therefore uses
>> >> 'urn:ogc:def:crs:EPSG::4326' as the WGS-84
>> >> CRS identifier.</t>
>> >> <t>The <coord-a> value (latitude
>> >> in WGS-84) is
>> >> set to '48.198634' decimal degrees.</t>
>> >> <t>The <coord-b> value (longitude
>> >> in WGS-84) is
>> >> set to '16.371648' decimal degrees.</t>
>> >> - <t>The <coord-c> (altitude) value
>> >> is undefined,
>> >> hence the client MAY assume the identified location to be on Earth's
>> >> physical surface.</t>
>> >> + <t>The <coord-c> (altitude) value
>> >> is undefined,
>> >> hence the client MAY assume the identified location to be on
>> >> the Earth's
>> >> physical surface.</t>
>> >> <t>The 'u' parameter is included in the
>> >> URI, setting
>> >> uncertainty to 40 meters.</t>
>> >> </list>
>> >> @@ -870,7 +870,7 @@
>> >> URIs with such values, and SHOULD warn the user when such
>> >> URIs are encountered.
>> >> </t>
>> >> - <t>An example of such an URI referring to an invalid location
>> >> + <t>An example of such a URI referring to an invalid location
>> >> would be <geo:94,0> (latitude "beyond" north pole).
>> >> </t>
>> >> </section>
>> >>
>> >>
>> >>
>> >> --------------------------------------------------------------
>> >> ------------------
>> >>
>> >>
>> >> > _______________________________________________
>> >> > Geopriv mailing list
>> >> > Geopriv@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/geopriv
>> >> >
>> >>
>> >> _______________________________________________
>> >> Geopriv mailing list
>> >> Geopriv@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/geopriv
>> >>
>> >>
>> >>
>> >
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
