FW: [MetaCRS] "FOSS Maintained" Source of CRS Definitions

Wed May 7 09:30:06 PDT 2008

Frank wrote: "Can you point us to a public document on this model?"

This might be an issue with the ISO spec. You have to pay for copies of
ISO specs if I remember correctly. They are also protected by copyright,
which might be another issue for some of us.

>From the ISO FAQ:

Are any ISO standards available electronically? 

Some ISO standards are available as electronic products. Contact the ISO
member in your country or our sales department using the online contact
form.

Where can I obtain technical assistance on standards? 

Contact the ISO member in your country. A list of members can be
accessed on this site. The ISO Central Secretariat does not provide
technical assistance, but the online enquiry service may be able to help
you save time by directing you to appropriate sources of information.

Can I reproduce material from ISO standards? 

All ISO publications, including ISO standards, are protected by
copyright. See the ISO copyright guide page for further information.

The web page for the newest version of the ISO 19111 spec being
developed is here:

http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.
htm?csnumber=44075

Frank wrote: " I'd be interested to hear from the CS-MAP folks if they
model datum
shifts between arbitrary datums, as opposed to mapping everything
through
WGS84 (as PROJ4 is inclined to do)."

We talked about this at OpenJUMP a few months back. It seems design of a
CRS library is simpler if you use WGS84 as the common currency for
transformations, but it adds overhead for some more simple
transformations. For example, you don't need to convert to WGS84 to go
from California State Plane Coordinates in US Survey Feet to California
State Plane Coordinates in Metric units. You just scale. We had thought
a solution would be to break transformations into two (2) types. Simple
transformations that could be performed with scaling, rotation, and an
elevation shift, and everything else, which would use WGS84 as a medium.

Frank wrote: " A few limitations to WKT that I am concerned about..."

Could we extend the format? I don't really think it is critical that we
use WKT. As long as we have something that is human readable text, and
not locked up in a relational database.

The only advantage of an extended WKT format is that it is already known
to a lot of programmers.

Frank wrote: " When talking about dictionaries I would prefer not to get
hung up on
API specifications.  I'd prefer to manage and provide a dictionary in
some form suitable exploitation by different packages and leave it to
them to talk about APIs."

I agree. I'm speaking to Jody about setting up a mailing list that can
host discussions on collaboration between Java projects.

Landon

-----Original Message-----
From: metacrs-bounces at lists.osgeo.org
[mailto:metacrs-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam
Sent: Wednesday, May 07, 2008 8:24 AM
To: Martin Desruisseaux
Cc: metacrs at lists.osgeo.org
Subject: Re: [MetaCRS] "FOSS Maintained" Source of CRS Definitions

Martin Desruisseaux wrote:
> There is already an existing model, which is an international standard

> approved both by ISO and OGC: ISO 19111. Would it be an acceptable
model?

Martin,

Can you point us to a public document on this model?  I'm frankly
somewhat
intimidated by it, and concerned that a lot of stuff it describes is not
practically useful.  But I really need to do a current review before I
spout off much more.

>>> There is already a "standard" and open format for CRS definitions,
>>> namely WKT, correct? Couldn't this be used?
> 
> It can be used for "minimal" CRS definition. But the OGC standard WKT 
> can not express Bursa-Wolf parameters targeting any other datum than 
> WGS84, and can not contain useful metadata like area of validity. Yet
it 
> still applicable when there is nothing better. But when a choice is 
> possible, I rather push for the EPSG database.

I'd be interested to hear from the CS-MAP folks if they model datum
shifts between arbitrary datums, as opposed to mapping everything
through
WGS84 (as PROJ4 is inclined to do).

A few limitations to WKT that I am concerned about:
  * There is no way to express datum shift methods other than 3/7
parameter
    transformations to wgs84 (via TOWGS84).  In particular, how am I
    supposed to document use of grid shift files in WKT?
  * There is no way to express that there are more than one possible
    datum shift approximation available for use.
  * No way to mark coordinate systems as deprecated, categorize them for
    display to the user and such.  If we produce a "super dictionary" it
    would be nice if user interfaces could provide a useful navigation
    mechanism to user based on it.

I can imagine picking the ISO model as our central CRS data model, and
distributing definitions in some format that maps well to that model,
like
GML, but I'm concerned we make our dictionaries so complicated that they
become very difficult to exploit.

> As far as I known the EPSG database is the most widely accepted at
least 
> at OGC. Some other sources like the PostGIS "spatial_ref_sys" table
are 
> actually generated from a subset of the EPSG database.

The EPSG database will certainly be a large portion of a
super-dictionary.
However, I would like to be able to capture other coordinate system
dictionaries too.  A few of interest to me:

  * The datum list from NGA, as used in GeoTrans.
  * The ESRI "coded" extensions to EPSG.
  * The ERMapper projection and datum definitions.
  * The MapInfo datum list.
  * The IAU (International Astronomical Union) definitions for other
planets.
  * OGC authority space definitions like urn:ogc:def:crs:OGC::CRS84

I should also point out http://spatialreference.org/ as a point of
interest
in our discussions.  This web site maintains it's own list of CRS
definitions,
many user submitted, though starting from the EPSG set.  It effectively
stores
them internally as WKT (I think) but endevors to return them in a
variety of
formats (using OGRSpatialReference facilities to do the translation).

>> - CRS interface spec. (not necesary but would be nice)
> 
> GeoAPI ?

When talking about dictionaries I would prefer not to get hung up on
API specifications.  I'd prefer to manage and provide a dictionary in
some form suitable exploitation by different packages and leave it to
them to talk about APIs.

I'm keen on GeoAPI as a basis for shared Java coordinate system
libraries
but I would like to keep that discussion distinct from the dictionary
discussion if possible.  Obviously starting from an ISO model (or
perhaps
a subset of the ISO model) makes it easier to map the dictionary to
something like GeoAPI.

Best regards,
-- 
---------------------------------------+--------------------------------
------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo,
http://osgeo.org

_______________________________________________
MetaCRS mailing list
MetaCRS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/metacrs

Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.