Subject: [Geopriv] New version of geo-URI

From: "Alexander Mayrhofer" <[email-masked]>
Date: Tue, 1 Sep 2009 16:58:02 +0200

Hi,

I've just posted a new revision of the "geo" URI draft.

http://tools.ietf.org/id/draft-ietf-geopriv-geo-uri-02.txt

The major changes compared to the -01 version are:

- "u" (Uncertainty) URI parameter added
- IANA Registry added for URI parameters
- GML mappings restructured
- Security Considerations rewritten (Privacy issues)
- Feedback from URI-Review incorporated

I think i have addressed all of the comments that i have received, so
from my point of view i think this is a pretty stable revision that
probably could be WGLCed soon?

Comments appreciated.

Alex

---

From: Ivan Shmakov <[email-masked]>
Date: Wed, 02 Sep 2009 00:23:00 +0700

>>>>> "AM" == Alexander Mayrhofer <[email-masked]> writes:

 AM> Hi,

 AM> I've just posted a new revision of the "geo" URI draft.

 AM> http://tools.ietf.org/id/draft-ietf-geopriv-geo-uri-02.txt

	I'm glad to see it's finally out!  I hope to update my
	simplistic ``geo: to Google'' geo-uri.sh implementation soon.

	I still have concerns over the lack of support for the sheer
	variety of CRS currently in use.  My ``guess'' is that these
	exist on purpose, and not because the parties involved didn't
	reach an agreement.  While the intent of the geo: URI scheme is
	to allow for ``a protocol independent, compact and generic way
	to refer to a physical geographic location'', its use for this
	purpose may be hampered by the necessity to perform otherwise
	unnecessary (and wasteful to the computer's resources)
	projection transformations.

	There's no necessity to put everything in a single proposal,
	though.

 AM> The major changes compared to the -01 version are:

 AM> - "u" (Uncertainty) URI parameter added

	While the current version's definition for uncertainty is
	probably the most unambiguous and simple, I'm in doubt that the
	formulae necessary to, e. g., show the uncertainty defined in
	such a way on a map, are going to be implemented in many
	``geosimple'' programs anytime soon.

	(FWIW, it looks to me like a lot of hassle to handle the `u'
	parameter in my geo-uri.sh script.)

	Hopefully an implementation of the necessary computations will
	be available before the wide adoption of the scheme.

 AM> - IANA Registry added for URI parameters

 AM> - GML mappings restructured

 AM> - Security Considerations rewritten (Privacy issues)

 AM> - Feedback from URI-Review incorporated

 AM> I think i have addressed all of the comments that i have received,
 AM> so from my point of view i think this is a pretty stable revision
 AM> that probably could be WGLCed soon?

 AM> Comments appreciated.

	So far I've spotted some minor issues on wording, punctuation
	and alike (hopefully not false positives), which I'm going to
	enumerate later.

-- 
FSF associate member #7257

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 2 Sep 2009 11:03:32 +0200

> 	reach an agreement.  

[OT]

Historical reasons, mostly, i guess.

For example, one Austrian reference system uses the "0" elevation point
relative to a spot where the former emporer put his toe into the waters
off Trieste, and said "here there be 0" back in the 19th century (Not
quite, but nearly).

Of course, that reference system is still in use for official land
register, and changing it to something more adequate for the 21th
century would create massive legal issues.

So, i think that most of the reference systems are there for historical
or policital reasons, or they are local CRSes (like the one above is
useless anywhere beyond the former Austrian Epire) - and WGS84 was the
first truly popular "global" CRS because of GPS..

Alex

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 2 Sep 2009 10:55:35 +0200

> 	projection transformations.

As i said a couple of times (and that seems to be what people i talk
about that issue think as well):

 - WGS-84 is currently clearly the most predominantly used CRS for
"neogeography" 
 - If you use it, the "casual user" won't be surprised, and doesn't need
transformations
 - The burden of re-projection should be put on the author of an URI
rather than the user
   - it's confusing to non-GIS-people
   - most internet users are not even aware that there's something like
CRSes.
 - A professional that wants to use the data from a geo-URI in a
different CRS certainly 
   has the software and knowledge to transform it into anything that he
wants
 
 - The introduced "crs" parameter allows for defining other CRSes
(particularly in 
   cases where something else replaces WGS-84 as the predominantly used
CRS).

> 	There's no necessity to put everything in a single proposal,

+1
 
> 	be available before the wide adoption of the scheme.

I am sure there will be a couple of implementations - i am working on
one currently.
 
> 	and alike (hopefully not false positives), which I'm going to

Thanks!

Alex

---

From: Ivan Shmakov <[email-masked]>
Date: Wed, 02 Sep 2009 20:05:03 +0700

>>>>> "AM" == Alexander Mayrhofer <[email-masked]> writes:

 IS> I still have concerns over the lack of support for the sheer
 IS> variety of CRS currently in use.  My ``guess'' is that these exist
 IS> on purpose, and not because the parties involved didn't reach an
 IS> agreement.  While the intent of the geo: URI scheme is to allow for
 IS> ``a protocol independent, compact and generic way to refer to a
 IS> physical geographic location'', its use for this purpose may be
 IS> hampered by the necessity to perform otherwise unnecessary (and
 IS> wasteful to the computer's resources) projection transformations.

 AM> As i said a couple of times (and that seems to be what people i
 AM> talk about that issue think as well):

 AM> - WGS-84 is currently clearly the most predominantly used CRS for
 AM> "neogeography"

	It isn't.  Apparently, there're a lot of geoscientific data sets
	(SRTM- and ASTER-derived digital elevation models, some of the
	MODIS datasets, Landsat imagery is what comes to mind) which are
	referenced to UTM, sinusoidal or other projections.  To me, it
	looks like that the only field where WGS-84 is predominant in
	geoscience is climatology.

	Yet, as the computing power rises, and allows for even finer
	resolutions to be used for world-scale climatic models, the
	community is forced to look... for other ways to construct the
	modelling grids, which effectively means -- coordinate systems.

 AM> - If you use it, the "casual user" won't be surprised, and doesn't
 AM> need transformations

	Just to clarify: while the stated purpose of the proposal is to
	``provide a protocol independent, compact and generic way to
	refer to a physical geographic location'', don't you assume a
	rather specific protocol here?  Namely, one with a user seeing
	an URI within his or her WWW browser window?

[...]

 AM> - most internet users are not even aware that there's something
 AM> like CRSes.

	I don't think that most of the Internet users of today seen an
	RCPT command, either.  Nevertheless, SMTP keeps going.

[...]

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 2 Sep 2009 15:55:39 +0200

> 	geoscience is climatology.

Well, the SRTM and ASTER datasets that i found and use are in WGS-84.
And i think of "neogeography" as people with no GIS knowledge at all
handling such data (and who most likely know coordinates only from their
GPS, and the numbers above the wikipedia articles), not of those people
who are well aware of the implications of using a certain CRS. 

Anyway, for the purpose of the document we had reached consensus in the
group to go for WGS-84 as the default, and "keep the door open" for
other CRSes. I'd very much not like to re-open that discussion again.
 
> 	an URI within his or her WWW browser window?

No, i do not. The purpose for my include what you describe, but
essentially it's purpose is to be used in anyplace where a whatever
protocol allows the inclusion of an arbitrary URI. 

Where the information contained in the URI originates, and what a user
agent (if it ever reaches one) does with that information is a
completely different story.

>	RCPT command, either.  Nevertheless, SMTP keeps going.

RCPT is a an element of a protocol command, not an identification
scheme. "mailto:" is the corresponding identification scheme - and
people know very well what it means and how to use it, even if it's
printed on a business card - and for that, they don't need to speak
SMTP.

Anyway: Let's get the document done, so that we have a stable basis for
whatever things may bloom based on that :-)

Alex

---

From: Ivan Shmakov <[email-masked]>
Date: Wed, 02 Sep 2009 22:26:36 +0700

Please consider the following patch.

	Among the issues I've considered:

	* the name of the planet Earth is constantly uncapitalized; (or
	  is it written this way for a purpose? or is there something I
	  don't understand?)

	* actually, I don't know why a hyphen (-, &#x2d, HYPHEN-MINUS)
	  is used instead of a proper M-dash (&#x2014, EM DASH), but I
	  guess that there's some implementation restriction justifying
	  that; anyway, <workgroup> has the M-dash encoded with two
	  hyphens instead (--), so I changed all the other instances to
	  match;

	* the names of the parameters are written both single-quoted
	  ('u') and double-quoted ("u"); as I didn't know whether this
	  was done on a purpose, I've left it that way;

	* one more nitpick: the whitespace is a bit weird; namely,
	  blanks and TABs (ASCII: HT, code 9) are somewhat mixed, and
	  there're a plenty of lines which end with a sequence of
	  blanks, or are comprised of blanks entirely; as it makes no
	  difference to the XML parser, I've left it that way, too.

	I guess, it will be found that not all of the edits below are
	actually necessary.

--- draft-ietf-geopriv-geo-uri-02.xml~	2009-09-01 19:39:48 +0700
+++ draft-ietf-geopriv-geo-uri-02.xml	2009-09-02 22:00:02 +0700
@@ -78,7 +78,7 @@
 	open source mapping community brought an enormous momentum into 
 	location aware technology. 
 	A wide range of tools and data sets which formerly were accessible
-	to professional only became available for a wider audience.
+	to professional users only became available for a wider audience.
 	</t>
 	<t>The 'geo' URI scheme is another step into that direction and aims
 	to facilitate, support and standardize the problem of location 
@@ -86,7 +86,7 @@
 	in geospatial services and applications. Accessing information about 
 	a particular location on earth or trigger further services 
 	shouldn't be any harder than clicking on a 'mailto:' link
-	and write an email straight away.
+	and writing an email straight away.
 	</t>
 	<t>According to <xref target='RFC3986'/>, a Uniform Resource Identifier (URI)
 	is "a compact sequence of 
@@ -105,7 +105,7 @@
         inclusion of arbitrary URIs.</t>
 	<t>For the sake of usability, the definition of the URI scheme 
         is strictly focused on the simplest, but also most common
-        representation of a spatial location - a single point in a well
+        representation of a spatial location -- a single point in a well
         known CRS. The 
 	provision of more complex geometries or locations described by
 	civic addresses is out of scope of this document.
@@ -118,7 +118,7 @@
         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 
-        beyond the default of "wgs84" is therefore out of scope of 
+        beyond the default of "wgs84" is therefore out of the scope of 
 	this document.
         </t>
 	<t>Note: The choice of WGS-84 as the default CRS
@@ -215,7 +215,7 @@
 	</section>
 	<section anchor='urisemantics' title='URI Scheme Semantics'>
 	  <t>Data contained in a 'geo' URI identifies 
-	  a physical resource: A spatial location on earth 
+	  a physical resource: a spatial location on Earth 
           identified by the geographic coordinates encoded in the URI. 
           </t>
           <section anchor='crsidentification' title='Coordinate Reference System Identification'>
@@ -288,7 +288,7 @@
           <section anchor='uncertainty' title="Location Uncertainty"> 
             <t>The 'u' ("uncertainty") parameter indicates the amount of 
             uncertainty in the location as a value in meters.  Where a 
-            geo URI is used to identify the location of a particular 
+            'geo' URI is used to identify the location of a particular 
             subject, uncertainty indicates the uncertainty with which 
             the identified location of the subject is known.
             </t>
@@ -298,7 +298,7 @@
             specific point in space, uncertainty MAY be set to zero. 
             Zero uncertainty and absent uncertainty are never the same thing.
             </t>
-            <t>Note: The number of significant digits of the value 
+            <t>Note: The number of digits of the values 
 	    in the 'coordinates' component MUST NOT be interpreted 
 	    as an indication to uncertainty.</t>
           </section>
@@ -330,7 +330,7 @@
 	    An URI with undefined (missing) 'coord-c' (altitude) value 
 	    MUST NOT be considered equal to an URI containing an 
             'coord-c' value, 
-	    even if the remaining values 'coord-a', 'coord-b' and 'u'  
+	    even if the remaining 'coord-a', 'coord-b' and 'u' values  
             are equivalent.
 	    </t>
 	  </section>
@@ -338,7 +338,7 @@
 	    <t>A consumer of a 'geo' URI in the WGS-84 CRS with undefined 'altitude' MAY 
 	    assume that the URI refers to the respective location on earth's 
 	    physical surface at the given 'latitude' and 'longitude' 
-            coordinate. 
+            coordinates. 
 	    </t>
             <t>However, as defined above, altitudes are relative to the WGS-84
             reference geoid rather than earth's surface. Hence, an altitude 
@@ -350,7 +350,7 @@
 	</section>
 	<section anchor='urienc' title='Encoding Considerations'>
 	  <t>The 'coordinates' path component of the 'geo' URI 
-	  (see <xref target='urisyntax'/>) uses a comma (",") as a 
+	  (see <xref target='urisyntax'/>) uses a comma (",") as the 
 	  delimiter for subcomponents. This delimiter MUST NOT be 
 	  percent encoded.
 	  </t>
@@ -361,7 +361,7 @@
 	  </t>
           <t>Regarding internationalization, the currently specified 
           components do allow for ASCII characters exclusively, 
-          and therefore don't require internationalization-
+          and therefore don't require internationalization.
           Future specifications of 
           additional parameters might allow for introduction of non-ASCII
           values. Such specifications MUST describe internationalization 
@@ -379,9 +379,9 @@
 	<section anchor='uriinterop' title='Interopability 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 unable to make direct use 
+          not aware of the 'geo' scheme are likely to be unable to make direct use 
           of the information in the URI. However, the simple structure of the
-          'geo' URI would even allow manual dereference by humans.
+          'geo' URI would allow even manual dereference by humans.
           </t>
  <!--         <t>Malformed and invalid 'geo' URI instances could contain whitespace
           and values with leading plus signs ("+"), which is not allowed 
@@ -466,8 +466,8 @@
         </t>
       </section>
       <section anchor='uriops' title="URI Operations">
-          <t>Currently, just one operation on a 'geo' URI is defined - location
-  	  dereference: In that operation, a client dereferences the URI by
+          <t>Currently, just one operation on a 'geo' URI is defined -- location
+  	  dereference.  In that operation, a client dereferences the URI by
 	  extracting the geographical coordinates from the URI path component
           ('geo-path' in the ABNF).
 	  Further use of those coordinates (and the uncertainty value from 
@@ -487,7 +487,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 -->
@@ -559,14 +559,14 @@
         <t>The Geographic Markup Language (GML) by the Open Geospatial 
         Consortium (OGC) is a set of XML schemas 
 	to represent geographical features. Since GML is widely accepted, 
-        this document includes instructions on how to transpose 'geo' URIs 
+        this document includes instructions on how to transform 'geo' URIs 
         from and to GML documents. The instructions in this 
         section are not normative.
         </t>
         <t>
 	For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are 
 	placeholders for latitude, longitude, altitude and uncertainty 
-	values. The mappings use WGS-84, and are defined in the following sections.
+	values, respectively. The mappings use WGS-84, and are defined in the following sections.
         </t>
         <t>Note: GML documents in other reference systems could be used as 
         well if a transformation into "urn:ogc:def:crs:EPSG::4979" or 
@@ -575,7 +575,7 @@
         </t>
         <t>GML uses the 'double' type from XML schema, and the mapping 
         examples assume that numbers in the form of "3.32435e2" in GML
-        are properly converted to decimal when placed in the 'geo' URI.
+        are properly converted to decimal when placed into the 'geo' URI.
         </t>
 	<section anchor='2dpoint' title="2D GML 'Point'">
           <t>A 2D GML <xref target="RFC5491">'Point'</xref> is constructed from a 'geo' URI that has two coordinates and an uncertainty ("u") parameter that is absent or zero.  A GML point is always converted to a 'geo' URI that has no uncertainty parameter.
@@ -726,7 +726,7 @@
 	</section>
         <section anchor='locprivacy' title='Location Privacy'>
           <t>A 'geo' URI by itself is just an opaque reference to a 
-          physical location, expressed by a set of spatial oordinates. This 
+          physical location, expressed by a set of spatial coordinates. This 
 	  does not fit the "Location Information" definition according to
           Section 5.2 of <xref target='RFC3693'>GEOPRIV Requirements</xref>, 
           because there is not necessarily a "Device" involved.
@@ -734,13 +734,13 @@
           <t>
           Because there is also no 
           way to specify the identity of a "Target" in a 'geo' URI by 
-	  itself, it does also not fit the 
-	  specification of an "Location Object" (Section 5.2 of RFC3693).
+	  itself, it also does not fit the 
+	  specification of a "Location Object" (Section 5.2 of RFC3693).
           </t>
           <t>However, by putting a 'geo' URI into a context that allows 
           identification of a "Target", the URI might become part of a 
-	  "Location Object", and would then be subject to GEOPRIV rules.</t>
-          <t>Therefore, Publishers of 'geo' URIs that are put into such 
+	  "Location Object", and would then be subject to the GEOPRIV rules.</t>
+          <t>Therefore, publishers of 'geo' URIs that are put into such 
           contexts MUST consider privacy issues, particularly in cases where 
           a URI instance is combined with Personally Identifyable Information
           (PII) with the intent to describe the location of a Target that 
@@ -754,7 +754,7 @@
         <t>The authors further wish to acknowledge the helpful 
 	contributions from Carl Reed, 
         Bill McQuillan, Martin Kofal, Andrew Turner, Kim Sanders,
-        Ted Hardie,  Culllen Jennings, Klaus Darilion and Bjorn Hoehrmann.
+        Ted Hardie,  Cullen Jennings, Klaus Darilion and Bjorn Hoehrmann.
         </t>
       </section>
   </middle>

---

From: [email-masked]
Date: Wed, 2 Sep 2009 11:52:28 -0400 (EDT)

Jumping in with both feet -

First, I agree that for many information communities that working solely
with coordinates expressed in WGS 84 is very limiting. For example, forget
doing GIS business in local government if your software only works with
WGS 84 - 2d coordinates!

That said, I have worked location/geo standards activities not only in the
OGC but also in the W3C, OMA, IETF, OASIS, ISO, ITU, ASPRS, OSGeo, GeoRSS,
and so on. I do so to try to insure consistency of the semantics,
modeling, and even the encoding for location payloads.

Based on my 15 years experience doing standards I can categorically state
that in many geo based applications and related encodings for location
that WGS 84 is the default and often only allowed CRS. Period. This is
especially true for what we in the OGC call mass market applications (and
what others call neogeo which is a misleading term). Mass market includes
location services, earth browser apps, car navigation systems, GPS centric
apps, location enabled RSS, authority to citizen alerting, and so forth.
And increasingly, sensor systems are location enabled and guess what -
they provide WGS 84 coordinates. This includes all of the UAVs that I am
aware of.

The issue for all of these applications and related standards that specify
the use of WGS 84 is that they properly document the semantics and usage
of WGS  84. The Terminology section in the geo-uri draft is quite good,
although I will be suggesting some additional words for increased semantic
clarity and reference. We went through very similar dialogues when
developing the GeoRSS information model and the GML Point Profile. In both
of these examples, the default CRS is WGS 84 2d. However, in recognition
that many applications and regions (such as Russia, India, and Australia)
require the use - often as legal mandates - that other CRSs MUST be
supported, the GeoRSS and GML Point encodings support by extension other
CRSs.

I do not see any reason that a similar approach cannot be used with the
geo-uri approach.

Sorry for the long winded response in support of Alexander's logic
regarding WGS 84.

Regards

Carl

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

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 2 Sep 2009 17:41:59 +0200

Ivan, 

Thanks for the thorough review - i will include the changes into the
next version together with other last call comments that i might
receive.

> 	  is it written this way for a purpose? or is there something I

Not intentional, will change that in the next version.

> 	  hyphens instead (--), so I changed all the other instances to

Well, intenet drafts and RFCs have to be pure ASCII, so if your comment
is about the text, then there's no way of using an M-dash. Usually, the
RFC editor team would change single dashes into double hashes at their
discretion.

> 	  was done on a purpose, I've left it that way;

I will change it to just one way - you are right, that's confusing (and
intententional).

> 	  difference to the XML parser, I've left it that way, too.

Yes, this comes from changing the document over and over... Again, the
RFC Editor would typically take care of that, but i will try cleaning
out the document before we finally submit it to the RFC editors to make
their jobs easier.

Thanks again!

Alex

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 2 Sep 2009 18:51:25 +0200

[ ..About CRSes.. ]

In the end, it's about interopability - that's what the IETF is
concerned when new protocols are developed. And as it can be seen from
the multiple efforts to develop encrypted variants of RTP, too many
choices for a particular problem can clearly hamper interopability, and
in the end, deployment. 

Why? Because both sides have to go significant efforts to support all
the variants that are possible - if they don't, chances are very high
that communication fails. For example, i thing there were 12 variants of
encrypted RTP. If any client can support only 2 of those 12 ways,
chances that communication could actually take place between random
clients would be very low... Clearly, nobody ever implemented all 12 in
a single client.

And it's the same with the thousands of CRSes out there. Yes, i know
that there is software like PROJ that can handle *most* of those CRSes -
but i wouldn't expect that every tiny mobile device out there would
include a PROJ just for the eventual case that they *might* encounter
data in one of those thousands CRSes. In my opinion, requiring every
client to support all those CRSes would hinder deployment significantly.

A nice metaphor just came to my mind:

My native language is German, while your's is probably Russian (wild
guess!). Still, we are using English to converse with each other -
because it gives us interopability, and in the end allows us to
communicate with each other. The other option would be than everybody
learns all the 200 (wild guess again!) languages that are spoken in the
world - just in case we *might* need one of those one day. That would be
a lot of effort if everybody would learn every possible language "just
for the case". 

However, if one day a different language might become the predominant
one used in international business, we both might have to learn it. But
then, both of us spent the effort of just learning 2 languages, rather
than 200.

Plus, if you really want to convey spatial information in whatever CRS
you like, then there's always GML - and for most applications among
professionals, that would probably be the way to go.

Alex

---

From: Ivan Shmakov <[email-masked]>
Date: Wed, 02 Sep 2009 23:06:40 +0700

IS> It isn't.  Apparently, there're a lot of geoscientific data sets
 IS> (SRTM- and ASTER-derived digital elevation models, some of the
 IS> MODIS datasets, Landsat imagery is what comes to mind) which are
 IS> referenced to UTM, sinusoidal or other projections.  To me, it
 IS> looks like that the only field where WGS-84 is predominant in
 IS> geoscience is climatology.

 AM> Well, the SRTM and ASTER datasets that i found and use are in
 AM> WGS-84.

	I stand corrected.  I've checked the SRTM dataset as it was
	obtained and it's in WGS-84.  (Seems like we had it reprojected
	to match some other dataset.)  Still, there're other examples.

 AM> And i think of "neogeography" as people with no GIS knowledge at
 AM> all handling such data (and who most likely know coordinates only
 AM> from their GPS, and the numbers above the wikipedia articles), not
 AM> of those people who are well aware of the implications of using a
 AM> certain CRS.

	The question is: can such people use, e. g., Landsat 7 imagery?
	See below for an example where it matters.

 AM> Anyway, for the purpose of the document we had reached consensus in
 AM> the group to go for WGS-84 as the default, and "keep the door open"
 AM> for other CRSes.

	The document seems to imply the contrary:

   The optional "crs" URI parameter described below may be used by
   future specifications to define the use of CRSes other than WGS-84.
   This is primarily 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).  [...]

 AM> I'd very much not like to re-open that discussion again.

[...]

 AM> RCPT is a an element of a protocol command, not an identification
 AM> scheme. "mailto:" is the corresponding identification scheme - and
 AM> people know very well what it means and how to use it, even if it's
 AM> printed on a business card - and for that, they don't need to speak
 AM> SMTP.

	I'm probably missing the point, but I see that aside from
	identification, there's a place for a generic and
	protocol-independent way to encode geolocation information of
	arbitrary objects.  Such information, after being encoded, could
	be stored in various places -- ASCII files, LDAP directories,
	DNS zones, RDBMS databases, etc.  Or it can be passed between
	processes over the network.  Anyway, such information may be
	obtained, e. g., by analyzing a georeferenced dataset.

	Think, e. g., of a user clicking on a place upon a satellite
	image in an image viewer.  Whenever the image is properly
	georeferenced to WGS-84, it would be trivial to encode the
	coordinates the user has clicked on into a geo: URI and to pass
	it to, say, some server for dereference.

	Now, the situation is the same, and the image is once again
	properly georeferenced, but not WGS-84 (e. g., a Landsat image.)
	And the whole thing is ruined, as now you're asking an image
	viewer (the ``author'' of the geo: URI) to become a GIS and to
	convert the coordinates to WGS-84.

	That being said, I won't insist that this generic geolocation
	encoding I'd be glad to use is necessarily to be performed by
	the means of URIs in general and the geo: URI in particular.

 AM> Anyway: Let's get the document done, so that we have a stable basis
 AM> for whatever things may bloom based on that :-)

	I don't insist on the contrary, actually.

---

From: Andy Mabbett <[email-masked]>
Date: Wed, 2 Sep 2009 22:34:10 +0100

In message <[email-masked]>, Ivan Shmakov 
<[email-masked]> writes

>   clearly affect interopability).  [...]

I should like to see specific reference to the use-case of 
non-terrestrial (e.g. lunar, Martian) coordinates.

-- 
Andy Mabbett

---

From: Andy Mabbett <[email-masked]>
Date: Wed, 2 Sep 2009 22:37:04 +0100

In message 
<[email-masked]>, 
Alexander Mayrhofer <[email-masked]> writes

>world - just in case we *might* need one of those one day. That would 
>be a lot of effort if everybody would learn every possible language 
>"just for the case".

That's not a metaphor, it's an analogy; and it's extensible, in that we 
have "lang" attributes in HTML and other systems, so that the language 
(= CRS) in use can be specified.

-- 
Andy Mabbett

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 2 Sep 2009 17:54:07 -0400

However, marking alone isn't very interesting or helpful, except to  
recognize that all you can do is discard the information received.

I'm not clear how useful all the different CRSes are going to be in  
practice, given that the producer of the URI will generally have no  
idea as to who will read it and there's no way to negotiate  
capabilities if the URL is on a web page. There are only three choices  
in an open environment:

(1) Either the sender re-codes the datum to WGS-84, if that is  
possible without losing information;

(2) Or it negotiates what datum to use, hoping to find common ground -  
only applies in certain circumstances and would point to extensions  
of, say, HTTP;

(3) Or it provides multiple versions, in the hope that one of them  
will work for the receiver.

Closed communities obviously don't have this problem, since everybody  
can be assumed to "speak" a certain CRS.

I'm unclear what model is being anticipated here. Without it, we have  
designed a mechanism that can reliably discard bits, but no  
interoperability.

Henning

On Sep 2, 2009, at 5:37 PM, Andy Mabbett wrote:

> In message <[email-masked] 
> >, Alexander Mayrhofer <[email-masked]> writes
>
>> My native language is German, while your's is probably Russian  
>> (wild guess!). Still, we are using English to converse with each  
>> other - because it gives us interopability, and in the end allows  
>> us to communicate with each other. The other option would be than  
>> everybody learns all the 200 (wild guess again!) languages that are  
>> spoken in the world - just in case we *might* need one of those one  
>> day. That would be a lot of effort if everybody would learn every  
>> possible language "just for the case".
>
> That's not a metaphor, it's an analogy; and it's extensible, in that  
> we have "lang" attributes in HTML and other systems, so that the  
> language (= CRS) in use can be specified.
>
> -- 
> Andy Mabbett

---

From: [email-masked]
Date: Thu, 3 Sep 2009 08:36:21 +0100

> non-terrestrial (e.g. lunar, Martian) coordinates.

And I specifically would not like to.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Thu, 3 Sep 2009 10:18:12 +0200

Henning,

> recognize that all you can do is discard the information received.

Exactly. That's why i was pushing for an agreed default that is well
known and understood to any author and consumer. 
 
> possible without losing information;

That's exactly the idea. If people are unhappy with that option, there's
always GML to express nearly arbitrarly complex geometries in thousands
of CRSes. GML documents are not simple and concise, though.

> only applies in certain circumstances and would point to extensions  

As you noted, negotiation is not possible in many situations, because it
requires a protocol that can negotiate - therefore i don't think it's an
option. 
 
> will work for the receiver.

Would be an option, although not an efficient one - especially
considering that there are thousands of CRSes out there.

Alex

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Thu, 3 Sep 2009 10:01:05 +0200

> And I specifically would not like to. 

I second that. Plus, i believe our esteemed chairs have declared that
out of scope long time ago.

Alex

---

From: Andy Mabbett <[email-masked]>
Date: Fri, 4 Sep 2009 20:42:58 +0100

In message 
<[email-masked]
 >, [email-masked] writes

>And I specifically would not like to

Then perhaps you could tell us how you propose that such coordinates - 
of which there are plentiful examples "in the wild" - should be 
referenced; or at least why. I have, after all, provided use cases for 
their inclusion.

-- 
Andy Mabbett

---

From: Andy Mabbett <[email-masked]>
Date: Fri, 4 Sep 2009 20:50:14 +0100

In message <[email-masked]>, 
Henning Schulzrinne <[email-masked]> writes

>recognize that all you can do is discard the information received.

You can do far more than that, You can have software translate such 
text, instruct search engines to prioritise or exclude it, spell check 
it correctly, have it pronounced correctly, or even style it with a 
different background colour to make it more apparent.

>designed a mechanism that can reliably discard bits, but no 

I would rather have a system which can identify, and then choose to 
interpret or discard, non-WGS84 coordinates, than one which wrongly 
assumes that they are WGS84.

-- 
Andy Mabbett

---

From: Andy Mabbett <[email-masked]>
Date: Fri, 4 Sep 2009 20:56:26 +0100

In message 
<[email-masked]>, 
Alexander Mayrhofer <[email-masked]> writes

>out of scope long time ago.

Cite, please?

My (apparently unanswered) post of 9 June 2009 refers:

    http://www.ietf.org/mail-archive/web/geopriv/current/msg07337.html

-- 
Andy Mabbett

---

From: Richard Barnes <[email-masked]>
Date: Sun, 06 Sep 2009 16:14:59 -0400

Andy,

Your comment is moot: There is no need for separate language relating to 
non-terrestrial CRSs because they can be supported by the same mechanism 
as terrestrial CRSs, namely the "crs" parameter.

If you would like to define GEO URIs for any CRS other than WGS84 
(whether terrestrial or not), the appropriate action at this point is to 
write a Internet-draft defining a new CRS parameter value for the 
current URI scheme.  You are welcome to write such a document, and 
propose it to the working group if you so desire.

--Richard

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Mon, 7 Sep 2009 10:28:43 +0200

> >out of scope long time ago.

http://www.ietf.org/mail-archive/web/geopriv/current/msg07282.html

Alex

---

From: Andy Mabbett <[email-masked]>
Date: Mon, 7 Sep 2009 11:04:29 +0100

In message <[email-masked]>, Richard Barnes <[email-masked]>
writes

>Andy Mabbett wrote:
>> In message  <8BC845943058D844ABFC73D2220D4665088A06AD@nics-
>>mail.sbg.nic.at>,  Alexander Mayrhofer <[email-masked]>
>>writes
>>
>>> I second that. Plus, i believe our esteemed chairs have declared
>>>that  out of scope long time ago.
>>  Cite, please?

>Your comment is moot: There is no need for separate language relating
>to non-terrestrial CRSs because they can be supported by the same
>mechanism as terrestrial CRSs, namely the "crs" parameter.
>
>(whether terrestrial or not), the appropriate action at this point is
>to write a Internet-draft defining a new CRS parameter value for the

I'm fully aware of all of the above; and am merely suggesting he
inclusion of half-a-dozen or so words, in order that it is made clear to
readers who are not.

For example, instead of:

        The optional "crs" URI parameter described below may be used by
        future specifications to define the use of CRSes other than
        WGS-84. This is primarily 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).  [...]

perhaps:

        The optional "crs" URI parameter described below may be used by
        future specifications to define the use of CRSes other than
        WGS-84. This is primarily 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); and to
        allow the use of non-terrestrial coordinates.  [...]

-- 
Andy Mabbett
            Says  "NO! to compulsory UK ID Cards":  <http://www.no2id.net/>
            and:  "Free Our Data":  <http://www.freeourdata.org.uk>
                   (both also on Facebook)

---

From: Andy Mabbett <[email-masked]>
Date: Mon, 7 Sep 2009 11:21:53 +0100

In message
<[email-masked]>,
Alexander Mayrhofer <[email-masked]> writes

>http://www.ietf.org/mail-archive/web/geopriv/current/msg07282.html

That's Richard Barnes saying:

        In message <[email-masked]>, Richard Barnes
        <[email-masked]> writes

        >+1
        >
        >I'm pretty sure that extraterrestrial coordinates are outside
        >the scope of this WG.  Those who are interested should feel
        >free to propose a charter update in the future.

        <http://www.ietf.org/mail-archive/web/geopriv/current/msg07282.html>

His "+1" was to the suggestion:

        In message <[email-masked]>, Dan Brickley
        <[email-masked]> writes

        >Could an escape code or sub-namespace be left in the geo: spec,
        >such that future revisions could be made without needing to
        >move to a new URI scheme?

        <http://www.ietf.org/mail-archive/web/geopriv/current/msg07280.html>

and today he says:

        In message <[email-masked]>, Richard Barnes
        <[email-masked]> writes

        >If you would like to define GEO URIs for any CRS other than
        >GS84 (whether terrestrial or not), the appropriate action at
        >his point is to write a Internet-draft defining a new CRS
        >parameter value for the current URI scheme.  You are welcome to
        >write such a document, and propose it to the working group if
        >you so desire.

        <http://www.ietf.org/mail-archive/web/geopriv/current/msg07817.html>

I also note that the former thread leaves several questions unanswered;
but providing the latter pertains (and is made clear), then I'm happy.

-- 
Andy Mabbett

---

From: Brian Rosen <[email-masked]>
Date: Mon, 07 Sep 2009 10:25:18 -0400

Working groups have deliberately limited scope, defined in the charter.

Richard offered his opinion that the current charter did not cover
extraterrestrial coordinates.  While anyone can write an Internet Draft on
any subject, and RFCs can be created without going through a work group,
Richard's opinion, if interpreted the same way by the ADs, would prohibit
this working group from considering non-earth coordinates unless and until
the charter was changed.
>> free to propose a charter update in the future.

The +1 part of that message is irrelevant.

Scope creep is an insidious thing.  It does seem really simple to expand to
extraterrestrial coordinates.  It's probably not in our charter to do so.

Brian

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 15 Sep 2009 11:00:53 -0600

Alexander -

GML instances can be clear and concise :-) when the content model is clear, 
simple, and concise.

For example, there is an OGC GML Point Profile that encodes as follows (less 
the obligatory header goo for the XML file):

<gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
  <gml:pos>45.256 -110.45</gml:pos>
</gml:Point>

The typical size would be 90 bytes per point with no compression.

And if WGS-84 2d is the default CRS, then the SRSname can be removed.

Just had to say so.

Also, there is an interesting comparison of file sizes using different geo 
encodings on a given land and water dataset done by Andrew Turner. 
Interesting results. GeoRSS GML was the most compact and efficient. GeoJSON, 
KML, Shape files, and SpatialLite all created files at least 75% larger. 
Interesting.

Cheers

Carl

----- Original Message ----- 
From: "Alexander Mayrhofer" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>; "Andy Mabbett" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 03, 2009 2:18 AM
Subject: Re: [Geopriv] New version of geo-URI