Subject: Re: [Geopriv] Short (5 page) ID to "update" RFC 3825

From: "Marc Berryman" <[email-masked]>
Date: Sun, 26 Apr 2009 18:46:00 -0500

Any new datum will be,  completely backward compatible exactly for the reason brought up in this thread. Has always been an relatively easy to convert between datums! Granted NAD27 is the exception, but any future datums will require backward compatibility.
Marc B

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; James M. Polk <[email-masked]>; [email-masked] <[email-masked]>
Sent: Sun Apr 26 18:39:30 2009
Subject: Re: [Geopriv] Short (5 page) ID to "update" RFC 3825

Indeed it would prevent use of new datums.  But then WGS84 is adequate.  If the world starts using a new datum in future, then it really isn't that bad to have to convert.  Unless things get a whole lot stranger, interplanetary datums are the only case I can think of where WGS84 wont convert easily.  But then, I'd suspect that DHCP LCI isn't going to be the protocol container of choice anyhow.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, 24 April 2009 5:14 PM
> To: Thomson, Martin
> Cc: [email-masked]; [email-masked]; James M. Polk
> Subject: Re: [Geopriv] Short (5 page) ID to "update" RFC 3825
> 
> > Read my risk analysis email [1] on the trade-off between versioning
> > and not.  My conclusion based on that analysis is that the addition
> > of a version field is not a good idea.  Versioning forces rejection
> > of an option rather than allowing for the chance of a minor
> > misinterpretation.  I invite further discussion on the issue.
> 
> Notwithstanding that the datum most commonly in use (WGS84) is already
> covered, IMHO the same arguments would appear to prevent us from _ever_
> adding new datums to RFC 3825.  e.g. "we can't add a new datum because
> the
> old client base doesn't know how to interpret it".
> 
> Ray
> 

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 27 Apr 2009 19:31:12 -0600

Well, I just reread the section on WGS 84/datums in RFC 3825.

While the information is partially correct as stated, there is actually 
additional information that is required in order to be very clear about the 
semantics and parameters being specified for use in 3825. There are also an 
invalid EPSG code. Providing the additional clarification will insure 
minimal ambiguity in implementation. This is important as there are real 
implications in terms of the interoperability, accuracy, and legal 
implications of the coordinates being encoded in the DHCP payload.

First, some definitions. These are from ISO 19111: Spatial Referencing by 
Coordinates was developed in the OGC and submitted to ISO. The work is based 
on discussions in the OGC, ISO, the Petroleum Industry, etc. This document 
is now the baseline for dealing with referencing in Asia, Europe, NGA, and 
so forth.

Anyway, some definitions:

coordinate: one of a sequence of n numbers designating the position of a 
point in n-dimensional space
In a coordinate reference system, the coordinate numbers are qualified by 
units

coordinate system: set of mathematical rules for specifying how coordinates 
are to be assigned to points

Coordinate Reference System: coordinate system which is related to the real 
world by a datum

datum: parameter or set of parameters that define the position of the 
origin, the scale, and the orientation of a coordinate reference system

So, latitude-longitude is actually what is known as a geographic coordinate 
system. When WGS-84 is added to the mix, we then have a full expression of a 
geographic coordinate reference system. One can actually specify geographics 
using datums other than WGS 84. One also needs to be clear about the units, 
which in the case of 3825 are decimal degrees.

Which brings me to one other point. The TLA "CRS" is used in the document. 
CRS is never defined as Coordinate Reference System. Also, EPSG is 
mentioned. I would add a few words about what the EPSG is and why it is 
being used. From the OGP website:
The EPSG geodetic parameter dataset is a structured repository of data 
required to

  a.. identify coordinates such that those coordinates describe position 
unambiguously. This is through a coordinate reference system (CRS) 
definition.
  b.. define transformations and conversions that allow coordinates to be 
changed from one CRS to another CRS. Transformations and conversions are 
collectively called coordinate operations.
Finally, there is now also an on-line OGP/EPSG CRS registry: 
http://www.epsg-registry.org/ . This registry was designed and implemented 
by an OGC Member (Galdos). And on checking the proper code for WGS 84 3d 
(for geographic CRS), we find 4979, not 4327. 4327 is not a valid EPSG code.

Apologies for not checking some of this information sooner!

Will be glad to do a more thorough "scrub" of the document on this 
particular topic.

Regards

Carl

PS: An interesting short paper on Latitude and Longitude by the former head 
surveyor for BP. Now key CRS fellow for OGP and works with the OGC.
http://www.ogcnetwork.net/node/338

----- Original Message ----- 
From: "Marc Berryman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, April 26, 2009 5:46 PM
Subject: Re: [Geopriv] Short (5 page) ID to "update" RFC 3825

> Any new datum will be,  completely backward compatible exactly for the 
> reason brought up in this thread. Has always been an relatively easy to 
> convert between datums! Granted NAD27 is the exception, but any future 
> datums will require backward compatibility.
> Marc B
>
> Cc: [email-masked] <[email-masked]>; James M. Polk <[email-masked]>; 
> [email-masked] <[email-masked]>
> Indeed it would prevent use of new datums.  But then WGS84 is adequate. 
> If the world starts using a new datum in future, then it really isn't that 
> bad to have to convert.  Unless things get a whole lot stranger, 
> interplanetary datums are the only case I can think of where WGS84 wont 
> convert easily.  But then, I'd suspect that DHCP LCI isn't going to be the 
> protocol container of choice anyhow.
>