Subject: [Geopriv] geo: URI: why crs=, and notcrsURI=?

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 13:36:39 +0700

I wonder, why the `crs=' parameter's value is opted to hold a
	``CRS label'', and not an URI below, say, `urn:ogc:def:crs:'?

	It seems that the separate set of labels, which the proposed
	scheme needs, will require its own IANA management, while
	there's already a namespace for coordinate systems managed by
	OGC Naming Authority (ONA.)

	Also note that a geo: URI with the CRS URI specified maps to a
	GML `Point' in probably the most straightforward and simple way.

	FWIW, I'd suggest either requiring `crs=' to hold an URI, or to
	have a separate `crsURI=' parameter for that purpose.

-- 
FSF associate member #7257

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2009 09:29:29 +0200

Ivan,

Re-using the URIs is a pretty good idea.  However, there are a couple of 
advantages to the current approach:
1. Abstraction: You can use "wgs84" to represent both the 2D and 3D 
CRSes, depending on whether altitude is present
2. Brevity

--Richard

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Tue, 28 Jul 2009 09:36:34 +0200

> CRSes, depending on whether altitude is present

In my opinion, the URI is a good idea, because it removes the need for a
registry. *However*, just because the CRS is defined in the urn space
does not necessarily mean that the corresponding definition is good
enough for the geo URI, because as you see from the draft, there's more
needed to have the URI semantics defined, even if the CRS is clear:

- What is the meaning of the "x","y","z" coordinate component
- What are valid URIs
- How does comparison work
- Are there any security considerations

So there definitely needs to be documentation for how each CRS to be
used in the geo URI is to be mapped (note that there are many many CRSes
that don't use the longitude/latitude scheme, for a start - also many
CRSes have completely different definitions of the third dimension).

So, just adding the CRS to the URI parameter is not good enough for a
full definition - which means that we need a document for new CRSes
anyway.

Which, in turn, removes the advantage of not needing a registry...

BUT - i think it is definitely a good idea to align the "identifier
string" that ogc uses and what is the token in the "crs" URI parameter
(i think we are fine with "wgs84").

BTW, i have tried to locate that URN registry - could you provide me
with a pointer?

Alex

---

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 14:49:40 +0700

>>>>> Richard Barnes <[email-masked]> writes:

 >> I wonder, why the `crs=' parameter's value is opted to hold a ``CRS
 >> label'', and not an URI below, say, `urn:ogc:def:crs:'?

[...]

 >> FWIW, I'd suggest either requiring `crs=' to hold an URI, or to have
 >> a separate `crsURI=' parameter for that purpose.

 > Ivan, Re-using the URIs is a pretty good idea.  However, there are a
 > couple of advantages to the current approach:

 > CRSes, depending on whether altitude is present

	... at the expense of having to maintain a separate registry of
	such labels, and a mapping of these labels to URIs.

 > 2. Brevity

	Well, the above may justify a set of labels for the CRSes used
	the most.

	Wouldn't it then make sense to allow for a separate parameter to
	hold an URI for the rarer CRSes?

	Once again, with the current proposal, the set of available
	coordinate systems is yet to be extended:

--cut: http://www.ietf.org/id/draft-ietf-geopriv-geo-uri-01.txt --
4.4.1.  Coordinate Reference System Identification

   The semantics of the 'coordinates' component depends on the CRS of
   the URI.  The CRS itself is identified by the optional 'crs'
   parameter the default.  A URI instance uses the default WGS-84 CRS if
   the 'crs' parameter is either missing, or contains the value of
   'wgs84'.  Other 'crs' values are not currently defined, but may be
   specified by future documents.
--cut: http://www.ietf.org/id/draft-ietf-geopriv-geo-uri-01.txt --

	With such a parameter, a sheer number of already defined CRS
	becomes available for the use in the geo: URIs.

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Tue, 28 Jul 2009 10:04:48 +0200

> 	becomes available for the use in the geo: URIs.

Theoretically, yes. Practically, only if the definition of the CRS is
crystal clear about everything that is required for URI semantics (see
definitions of WGS-84 in the document). 

Another issue that bothers me is that the sheer number of defined CRSes
would almost make it impossible to support all those CRSes - which would
probably hurt interopability.

Does anybody else have an opinion about this?

Alex

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 28 Jul 2009 03:19:56 -0500

I think that your analysis was correct.  WGS84 as specified doesn't directly map to one CRS URN, it maps to two.  4979 AND 4326, depending on the presence of altitude.  Other definitions would need to deal with this.

That doesn't prevent the later addition of a CRSURN parameter, but I think that I'd be opposed to that as I was on this ;)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alexander Mayrhofer
> Sent: Tuesday, 28 July 2009 10:05 AM
> To: Ivan Shmakov; [email-masked]
> Subject: Re: [Geopriv] geo: URI: why crs=, andnotcrsURI=?
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 28 Jul 2009 10:50:15 +0200

>	such labels, and a mapping of these labels to URIs.

The reality is that the key requirement here is that everyone understands
what the labels mean, whether they are short-form labels or URIs.   URI
matching is a lot trickier than label matching (since it can be some form
of string compare).  You can limit the URI type to something like a URN
(which will avoid some of the many-strings-dereference-the-same-resource
problem of HTTP), but those essentially are pointers to a registry entry,
with the NID telling you *which* registry.  I'm personally fine with that
way forward, but I hope if we go down that road we strongly indicate which
NIDs are likely.

---

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 16:21:35 +0700

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

 >> Re-using the URIs is a pretty good idea.  However, there are a

 > In my opinion, the URI is a good idea, because it removes the need
 > for a registry.  *However*, just because the CRS is defined in the
 > urn space does not necessarily mean that the corresponding definition
 > is good enough for the geo URI, because as you see from the draft,
 > there's more needed to have the URI semantics defined, even if the
 > CRS is clear:

 > - What is the meaning of the "x","y","z" coordinate component

	Is this really necessary?

 > - What are valid URIs

	While a CRS definition will, I guess, include the limits for the
	coordinates, or at least allow for them to be determined in an
	unambigous way, I doubt that these limits could easily be
	written in ABNF for any existing CRS.  (May EPSG 3576 [1] serve
	as an example?)

[1] http://nsidc.org/data/atlas/epsg_3576.html

 > - How does comparison work

	Wouldn't the simple string comparison work (with the trailing
	zeros being dropped)?

	(But note, that the trailing zeros are used in science to
	provide the uncertainty information; i. e., 1.23 may not be the
	same as 1.2300 in, say, the field of physics -- while 1.23 may
	be considered ``equal'' to 1.234, the 1.2300 may not.)

 > - Are there any security considerations

	Any example where this may be appropriate?

 > used in the geo URI is to be mapped (note that there are many many
 > CRSes that don't use the longitude/latitude scheme, for a start -
 > also many CRSes have completely different definitions of the third
 > dimension).

	Wouldn't the party supporting a particular CRS ``know'' what the
	interpretation is?  Wouldn't the geo: URI with a CRS not known
	to a particular party be unusable to that party anyway?

 > string" that ogc uses and what is the token in the "crs" URI
 > parameter (i think we are fine with "wgs84").

 > BTW, i have tried to locate that URN registry - could you provide me

	I'm afraid I wasn't able to find it, either.  Looks like [2]
	``delegates'' the naming below urn:ogc:def:crs:EPSG: to EPSG
	[3].  As per [2], urn:ogc:def:crs:EPSG is the only possible
	immediate subordinate to urn:ogc:def:crs.

	You may wish to check how the `epsg' file shipped with the
	PROJ.4 [4] package is generated.

[2] http://www.opengeospatial.org/ogcUrnPolicy
[3] http://www.epsg.org/
[4] http://trac.osgeo.org/proj/

---

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 16:28:58 +0700

>>>>> Ivan Shmakov <[email-masked]> writes:

[...]

 > unambigous way, I doubt that these limits could easily be written in
 > ABNF for any existing CRS.

	s/any/every/, of course.

[...]

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 28 Jul 2009 04:31:00 -0500

I warned you about this.

> 	be considered ``equal'' to 1.234, the 1.2300 may not.)

This is outright wrong.

Please read:

   [ISO.GUM]  ISO/IEC, "Guide to the expression of uncertainty in
              measurement (GUM)", Guide 98:1995, 1995.

   [NIST.TN1297]
              Taylor, B. and C. Kuyatt, "Guidelines for Evaluating and
              Expressing the Uncertainty of NIST Measurement Results",
              Technical Note 1297, Sep 1994.

You can google for the second, which is quite readable.  The first is both less readable and less readily available.

Or, you can read my favourite page on this topic:

  <http://www.av8n.com/physics/uncertainty.htm>

In "science" uncertainty is treated with respect.  Using significant figures shows the utmost disrespect.

--Martin

---

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 16:44:57 +0700

>>>>> Thomson, Martin <[email-masked]> writes:

 >> (But note, that the trailing zeros are used in science to provide
 >> the uncertainty information; i. e., 1.23 may not be the same as
 >> 1.2300 in, say, the field of physics -- while 1.23 may be considered
 >> ``equal'' to 1.234, the 1.2300 may not.)

[...]

	OK, agreed.

---

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 17:20:56 +0700

>>>>> Ted Hardie <[email-masked]> writes:

[...]

 >>> However, there are a couple of advantages to the current approach:

 >> ... at the expense of having to maintain a separate registry of such
 >> labels, and a mapping of these labels to URIs.

 > The reality is that the key requirement here is that everyone
 > understands what the labels mean, whether they are short-form labels
 > or URIs.

	Yes.

 > URI matching is a lot trickier than label matching (since it can be
 > some form of string compare).  You can limit the URI type to
 > something like a URN (which will avoid some of the
 > many-strings-dereference-the-same-resource problem of HTTP),

	It may make sense, but I don't think that such limitation is
	really necessary.  The specification may RECOMMEND for the CRS
	URIs to be restricted to a particular set of URNs.

	To be honest, what I've had in mind suggesting crsURI= is
	certainly the `urn:ogc:def:crs:EPSG:*' URNs.

 > but those essentially are pointers to a registry entry, with the NID
 > telling you *which* registry.

	The point is not to have /no/ registry at all, but to have no
	/extra/ registry just for the geo: URIs.

 > I'm personally fine with that way forward, but I hope if we go down
 > that road we strongly indicate which NIDs are likely.

	No objections on that.

[...]

---

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 17:50:02 +0700

>> With such a parameter, a sheer number of already defined CRS becomes
 >> available for the use in the geo: URIs.

[...]

 > Another issue that bothers me is that the sheer number of defined
 > CRSes would almost make it impossible to support all those CRSes -
 > which would probably hurt interopability.

	First of all, there's PROJ.4 [1], readily supporting more than
	approximately...

$ grep -vE ^\# /usr/share/proj/epsg | wc -l 
3519
$ 

	... coordinate systems.

	Also, I'm in doubt that most of the parties handling the geo:
	URIs are ought to have some ``specific'' support for the
	particular CRSes.  To my mind, most of the ``simple'' software
	(when it comes to the geography knowledge; should I call such
	software ``geosimple''?) would simply pass the geo: URIs to the
	other parties, without any need to ever interpret it.

	And the complex software (such as GRASS, MapServer, and,
	perhaps, Google Maps) is expected to support this sheer number
	of coordinate systems anyway.

[...]

[1] http://trac.osgeo.org/proj/

---

From: [email-masked]
Date: Tue, 28 Jul 2009 13:19:32 -0400 (EDT)

If this helps at all:

The official EPSG CRS registry is here http://www.epsg-registry.org/

and the OGC urn resolver (beta) is here: http://urn.opengis.net/

Please note that the OGC urn registry against which the resolver works has
not been fully. Should be in the next few months. There are also seveal
OGC standards documents that specify the rules for the "def" branch of the
OGC urn - including type "crs".

Alexandre is correct - there are thousands of CRS's. Relatively few
specify latitude/longitude.

Carl

---

From: Ivan Shmakov <[email-masked]>
Date: Wed, 29 Jul 2009 01:06:49 +0700

>>>>> creed  <[email-masked]> writes:

[...]

 >> So, just adding the CRS to the URI parameter is not good enough for
 >> a full definition - which means that we need a document for new
 >> CRSes anyway.

[...]

 > If this helps at all: The official EPSG CRS registry is here
 > http://www.epsg-registry.org/

	Thanks for the link!  (Looks like I should look for something
	speaking JavaScript to work with the resource, though.)

 > Please note that the OGC urn registry against which the resolver
 > works has not been fully.

	Apparently, I've stumbled upon this one earlier, but haven't
	figured out how to make any use of it.  Could you provide any
	examples (with respect to the URN-mapped CRS definitions)?

 > Should be in the next few months. There are also seveal OGC standards
 > documents that specify the rules for the "def" branch of the OGC urn
 > - including type "crs".

 > specify latitude/longitude.

	Is this a problem for a modern ``geospatially-enabled''
	application?  (I've got a feeling like I'm missing something
	both trivial and widely known...)

---

From: [email-masked]
Date: Tue, 28 Jul 2009 14:26:58 -0400 (EDT)

PROJ.4 does not have the level of normative endorsement as does the
OGP/EPSG database of CRS info. The OGC, ISO, the OGP, NATO, US DoD, the
European SDI (INSPIRE), and many more now use the EPSG database as a
normative reference. You also need to look at the use cases - many from
the emergency services, 911, risk mitigation, location services, and
related communities - that drives much of the work here, NENA, in the OGC,
and other communities of interest.

Carl

---

From: Ivan Shmakov <[email-masked]>
Date: Wed, 29 Jul 2009 01:52:48 +0700

[...]

 > OGP/EPSG database of CRS info. The OGC, ISO, the OGP, NATO, US DoD,
 > the European SDI (INSPIRE), and many more now use the EPSG database
 > as a normative reference.

	I haven't made a claim that PROJ.4 has any level of normative
	endorsement.

	I've just tried to point that, while there are thousands
	coordinate systems in use in the world, there're also thousands
	of coordinate systems already supported by free (as in freedom)
	software packages.

	Therefore, I see no reason to restrict particular location
	``encodings'' (and the geo: URI scheme could be viewed as such
	an encoding) to particular coordinate systems.

 > You also need to look at the use cases - many from the emergency
 > services, 911, risk mitigation, location services, and related
 > communities - that drives much of the work here, NENA, in the OGC,