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.html
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
