Subject: RE: LO Option Proposal (was: Re: I-DACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt)

From: Martin Layley <[email-masked]>
Date: Fri, 24 Jan 2003 08:21:48 +0000

From the EPSG website
>EPSG Codes
>
>EPSG has reserved the integer range 0 to 32767 for use as codes. To prevent conflict with future EPSG additions to the data, users who wish to augment the data with their own information should utilise codes greater than 32768. EPSG record coding has been renumbered from previous versions to eliminate EPSG codes under 1024 in order to assist GeoTIFF compatibility.
>
>If users wish to supplement the change table with their own entries, it is important that the user's change notice IDs be above the EPSG real number code limit of 32,767.0. For example, such an entry in the change table is required for users to deprecate any erroneous user data.
>
		Martin Layley
		Samsung SERI

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: 23 January 2003 19:36
To: 'Henning Schulzrinne'; Carl Reed
Cc: Marc Linsner; [email-masked]
Subject: RE: LO Option Proposal (was: Re:
I-DACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt)

This was new info to me.  I started looking.
The database can be obtained from:
http://www.ihsenergy.com/epsg/

If you load it, the table of interest is the "Coordinate Reference
System".  It has an index (Code).  

If you take the table at face value, the code can be as big as a
32766, a close to a suspiciously binary number.

Might need to delve into the EPSG procedure to know:
	Does a code EVER change (ie adding and subtracting is possible,
		but can the meaning of a specific code instance ever
change)?
	Is there a commitment to keep the maximum code less than some
		number?

There are 2597 records in this table at the moment.
I think one byte identifier is not going to work. The question is
whether a two byte identifier works, or we need 4.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, January 23, 2003 9:58 AM
> To: Carl Reed
> Cc: Marc Linsner; [email-masked]
> Subject: Re: LO Option Proposal (was: Re:
> I-DACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt)
> 
> 
> Since there's no point in having IANA duplicate the work of 
> the EPSG, it 
> makes sense to just use that database. We need a small numeric 
> identifier that can be derived from that database, e.g., by 
> subtracting 
> some fixed offset from a larger identifier.
> 
> Carl Reed wrote:
> > No, but EPSG does. The EPSG database has now become the 
> normative reference
> > for coordinate reference systems (including datums) for 
> many organizations
> > such as the petroleum industry, numerous GIS vendors, the 
> OGC and LIF/OMA.
> > The OGC has recently developed an on-line registry for the 
> common reference
> > systems and datums expressed in the EPSG database. Perhaps 
> we could look to
> > the EPSG.
> > 
> > Just a thought -
> > 
> 

The mail message has been scanned by MAILsweeper
for content analysis.

---

From: Carl Reed <[email-masked]>
Date: Mon, 27 Jan 2003 19:33:26 -0700

Hi -

After conferring with a number of OGC members who have considerable
experience with coordinate reference systems (CRS), interoperability
requirements for CRS, and standards specification, the following is
suggested.

The gist of their recommendation is rather than have well known codes for
all datums, use identifiers that reference CRS definitions in a registry.
This is more flexible and allows you to use any subset of the identifiers
(codes) that you want. This also allows anyone to check the contents of the
CRS definition. This, I suspect, is analogous to using the previously
suggested IANA approach. Now, a CRS definition includes not just the datum
bit also axes order, units, and so forth. However, by using a CRS code, the
space requirements for a "tight" LO package are met while at the same time
insuring flexibility of implementation as well as providing all the CRS
information required by the end application. FYI, the OGC now has a
prototype CRS registry at http://crs.opengis.org/crsportal.

Now, a  bit more detail on the why of this approach as to why one should not
refer to a Datum code but to a CRS code.  The CRS entity contains more than
the datum entity, e.g. the order and names of the axes and the unit to be
used.  That information is needed for interpretation of the location
element, at least if coordinates are used to define the location.  One
should not use implied assumptions about the axes order and the units,
because, as experience has taught us (and ISO and LIF), different people
make different assumptions about these things, potentially resulting in the
coordinates being useless to many applications. Again, a CRS code gets
around this issue.

Also, EPSG (the organization) made recent changes in their procedures and
their database structure that allow people to construct their own CRS code
so they can use a geographic CRS with different units (or rather: different
representation formats of the same "degree" unit) than those defined in the
EPSG database.  In this way, IETF could define a "default" CRS for use in
the LO definition. The EPSG database uses the
<deg><symbol><min><symbol><sec><symbol><hemisphere char> format. However,
most digital applications of geographic data would prefer decimal degrees.
This would lead to a CRS code such as 43266405, which stands for WGS84 in
decimal degrees (latitude before longitude!).  Hence two bytes may not
enough.  The EPSG documentation mentions 32768 as an upper limit, but that
only indicates the range reserved for EPSG, not the range of codes you can
expect.  You need 4 bytes to describe the long codes I mentioned and I would
very strongly recommend they use 4 bytes.

On the subject of obsolete datums, as a geodesist told me, "One should also
be careful to claim that certain datums are obsolete. The statement is true,
some are indeed obsolete, but legacy geospatial data sets in the associated
CRS still hang around .  It also requires considerable geodetic experience
to indicate which are obsolete.  The fact that someone has never heard of it
doesn't mean it's obsolete!  It also depends what target user population you
have in mind.  If you are aiming for a worldwide standard, you should not a
priori exclude certain datums!"

Several OGC members, including geodesists, have stated they would be more
than happy to provide additional input.

Hope this helps!

Carl Reed
OGC

----- Original Message -----
From: Martin Layley <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 24, 2003 1:21 AM
Subject: RE: LO Option Proposal (was:
Re:I-DACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt)

> From the EPSG website
> >EPSG Codes
> >
> >EPSG has reserved the integer range 0 to 32767 for use as codes. To
prevent conflict with future EPSG additions to the data, users who wish to
augment the data with their own information should utilise codes greater
than 32768. EPSG record coding has been renumbered from previous versions to
eliminate EPSG codes under 1024 in order to assist GeoTIFF compatibility.
> >
> >If users wish to supplement the change table with their own entries, it
is important that the user's change notice IDs be above the EPSG real number
code limit of 32,767.0. For example, such an entry in the change table is
required for users to deprecate any erroneous user data.