Subject: [Geopriv] a few tweaks to draft-ietf-geopriv-geo-uri-07

From: Ivan Shmakov <[email-masked]>
Date: Mon, 03 May 2010 22:44:51 +0700

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 
             &lt;coord-c&gt;, 
 	    even if the remaining &lt;coord-a&gt;, &lt;coord-b&gt;, 
-	    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 &lt;coordinates&gt; 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 &lt;parameter&gt; 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 &lt;coord-c&gt;, is hence 2-dimensional, and therefore uses 'urn:ogc:def:crs:EPSG::4326' as the WGS-84 CRS identifier.</t>
                     <t>The &lt;coord-a&gt; value (latitude in WGS-84) is set to '48.198634' decimal degrees.</t>
                     <t>The &lt;coord-b&gt; value (longitude in WGS-84) is set to '16.371648' decimal degrees.</t>
-                    <t>The &lt;coord-c&gt; (altitude) value is undefined, hence the client MAY assume the identified location to be on Earth's physical surface.</t>
+                    <t>The &lt;coord-c&gt; (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 &lt;geo:94,0&gt; (latitude "beyond" north pole).
 	  </t>
 	</section>

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 3 May 2010 09:51:46 -0600

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" <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 03, 2010 9:44 AM
Subject: [Geopriv] a few tweaks to draft-ietf-geopriv-geo-uri-07

--------------------------------------------------------------------------------

--- 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 @@

           <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
             &lt;coord-c&gt;,
      even if the remaining &lt;coord-a&gt;, &lt;coord-b&gt;,
-     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 &lt;coordinates&gt; 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 &lt;parameter&gt; 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 &lt;coord-c&gt;, is hence 
2-dimensional, and therefore uses 'urn:ogc:def:crs:EPSG::4326' as the WGS-84 
CRS identifier.</t>
                     <t>The &lt;coord-a&gt; value (latitude in WGS-84) is 
set to '48.198634' decimal degrees.</t>
                     <t>The &lt;coord-b&gt; value (longitude in WGS-84) is 
set to '16.371648' decimal degrees.</t>
-                    <t>The &lt;coord-c&gt; (altitude) value is undefined, 
hence the client MAY assume the identified location to be on Earth's 
physical surface.</t>
+                    <t>The &lt;coord-c&gt; (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 &lt;geo:94,0&gt; (latitude "beyond" north pole).
    </t>
  </section>

--------------------------------------------------------------------------------

> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 3 May 2010 17:55:10 +0200

Please get these in ASAP, and be aware that major changes cannot be  
made at this point, since the document is already in the RFC editor's  
queue.

--Richard

On May 3, 2010, at 5:51 PM, Carl Reed wrote:

> 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"  
> <[email-masked]>
> To: <[email-masked]>
>        Parameters Registry" for the &lt;parameter&gt; component of  
> the URI. Parameters for the 'geo' URI and values
> -                    <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 &lt;coord-c&gt;, is hence 2- 
> dimensional, and therefore uses 'urn:ogc:def:crs:EPSG::4326' as the  
> WGS-84 CRS identifier.</t>
>                    <t>The &lt;coord-a&gt; value (latitude in WGS-84)  
> is set to '48.198634' decimal degrees.</t>
>                    <t>The &lt;coord-b&gt; value (longitude in  
> WGS-84) is set to '16.371648' decimal degrees.</t>
> -                    <t>The &lt;coord-c&gt; (altitude) value is  
> undefined, hence the client MAY assume the identified location to be  
> on Earth's physical surface.</t>
> +                    <t>The &lt;coord-c&gt; (altitude) value is  
> undefined, hence the client MAY assume the identified location to be  
> on the Earth's physical surface.</t>

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Mon, 3 May 2010 17:55:42 +0200

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Carl Reed
> Sent: Monday, May 03, 2010 5:52 PM
> To: Ivan Shmakov; [email-masked]
> Subject: Re: [Geopriv] a few tweaks to draft-ietf-geopriv-geo-uri-07
> 
> Membership that 
> 2-dimensional, and therefore uses 
> 'urn:ogc:def:crs:EPSG::4326' as the WGS-84 
> CRS identifier.</t>

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Mon, 3 May 2010 17:58:29 +0200

>From what i see, your tweaks all seem to be editorial - i think we can
instruct the RFC editors to apply most of the  changes - they have
probably already taken care of the typo and spelling errors.

thanks,

Alex

---

From: Ivan Shmakov <[email-masked]>
Date: Mon, 03 May 2010 23:38:57 +0700

>>>>> Alexander Mayrhofer <[email-masked]> writes:

 > From what i see, your tweaks all seem to be editorial

	Yes.

 > - i think we can instruct the RFC editors to apply most of the
 > changes - they have probably already taken care of the typo and
 > spelling errors.

	Most probably, yes.

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 11 May 2010 10:15:21 -0600

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.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" <[email-masked]>
To: "Carl Reed" <[email-masked]>; "Ivan Shmakov" 
<[email-masked]>; <[email-masked]>
Sent: Monday, May 03, 2010 9:55 AM
Subject: RE: [Geopriv] a few tweaks to draft-ietf-geopriv-geo-uri-07

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 12 May 2010 13:02:47 +0800

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.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Carl Reed
> Sent: Wednesday, 12 May 2010 2:15 AM
> To: Alexander Mayrhofer; Ivan Shmakov; [email-masked]

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 12 May 2010 09:42:24 -0600

Martin -

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" <[email-masked]>
To: "Carl Reed" <[email-masked]>; "Alexander Mayrhofer" 
<[email-masked]>; "Ivan Shmakov" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, May 11, 2010 11:02 PM
Subject: ISO 6709 (was: [Geopriv] a few tweaks to 
draft-ietf-geopriv-geo-uri-07)

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

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 26 May 2010 14:06:20 +0200

Carl,

I've been thinking about the comments that you forwarded to the list.
The draft is now in AUTH48, so we're more or less in a state of the
document where we're only correcting spelling errors etc., but not
change the content significantly. 

More about the specific topics:

- Altitude clarification: 

Section 2 includes that "... altitudes below the WGS-84 reference geoid
are signed negative...". 

For clarification, i could add the single word "depth" to the sentence
cited, so that it reads: "... altitudes below the WGS-84 reference geoid
(depths) are signed negative..."

Would that help? 

- Lines and Polygons:

It was agreed very early in the process (and confirmed by WG chairs)
that Lines and Polygons would be out of scope for the document. PIDF-LO
already covers such elements. 

- ISO 6709:

(Disclaimer: I have only access to the German DIN EN 6709:2009 here, so
my knowledge might be limited to that version of the standard)

Like Martin, i admit i heard of that format for the first time in your
posting - blind spot for me as well (and i haven't found any discussion
about it in the GEOPRIV working group archives either). I think that the
mapping from a "geo" URI to an ISO6709 representation is trivial, and
can be performed without additional instructions in the draft.

(Side note: I'm a little bit concerned about the option in the string
representation to leave out the CRS definition - particularly with the
option to have positive depths as well as positive elevation - how would
i know whether 40.44+70.2+221.5/ is 222.5 meters above or below whatever
reference plane? I fully agree with Martin that DMS representations are
dangerous, particularly to "non-GIS" users)

For the XML mapping of ISO6709, we have already specified a mapping to
another, more recent ISO standard (GML) in the document - so it should
be easy to map the ISO GML to ISO 6709 XML (particularly because GPL
seems to be based on GML types anyway).

For those reason, i think that we shouldn't include another mapping in
the document. If there's demand for the specification of such a mapping,
we could still do it in a seperate Information document.

Alex

---

From: [email-masked]
Date: Wed, 26 May 2010 13:20:47 -0400 (EDT)

Alexander -

Thanks for the response to my questions. I understand the document stage
issue and apologize for getting OGC Member comments into the process so
late.

Responses to your questions etc are below.

Regards

Carl

> (depths) are signed negative..."

Yes, this would help.

> already covers such elements.

Understand. Thanks.
> can be performed without additional instructions in the draft.

Perhaps just a note that geo URI can be mapped to 6709 as a recognition of
6709 would remove majority of concerns. FYI - GML incorporates 6709.

> dangerous, particularly to "non-GIS" users)

Yes, I also agree that DMS representation is not useful. And totally agree
with your CRS note.

> we could still do it in a seperate Information document.

Agreed.

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Thu, 27 May 2010 08:53:25 +0200

Carl, 

sorry if that came out wrong - i fully appreciate that the you took the
effort of getting the document reviewed in the OGC community, and also
comiled the comments - it was "just in time" to get the issues below
into the final document.

> Responses to your questions etc are below.

I've commented on your responses below.

> > (depths) are signed negative..."

I have now instructed the RFC Editors to modify the sentence as follows:

   Coordinates in the Southern and Western hemispheres as well as
   altitudes below the WGS-84 reference geoid (depths) are signed 
   negative with a leading dash.
 
> 6709 would remove majority of concerns. FYI - GML incorporates 6709.

I haven't yet instructed the RFC Editors to do so, but given that you
say it would remove major concerns, i will draft up an (informative)
note to be included in the final RFC. I will also add an informative
reference to the ISO standard document. 

Alex

---

From: [email-masked]
Date: Fri, 28 May 2010 12:24:19 -0400 (EDT)

Thanks!

Carl