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
