[MetaCRS] 'FOSS Maintained' Source of CRS Definitions

[Norm Olsen]

Howard is correct in that, in the case where you don't know the specific code, the site is awkward to use.  More importantly:

1> you don't get to add new definitions; you can only _request_ a change.
2> while you get a complete definition when you ask for a Report, you don't get much of anything useful when you ask for GML.

I believe there is a  mechanism that supports on-line query to obtain a definition.  I'm not an Internet person, so I wouldn't know how that works.  I only know that my old Brand X advertises that it is capable of doing that.

> A question I ask myself is if this problem is solvable, why hasn't it been solved yet?

All the issues you have referenced, plus one more big one:

        Is it a matter of sufficient funding?

I think this is where OGP/EPSG have a big advantage.  Setting up the Geodesy Registry cost a bundle.  Being in the oil business, OGP has lots of money (by our standards, anyway).  So that made it relatively easy for them to implement this and promote it as a standard.  I think that is the primary reason I have suggested EPSG as a possible standard; they have the bucks to pull it off.

The following is an e-mail I was writing when I received Howard's last message:

The following is a link to the EPSG web service.  Turns out, it is free.  Take a look see . . .

http://www.epsg-registry.org/

I have downloaded the entire database in GML format.  It appears to be the EPSG database in XML/GML form.  Each of the 22 tables is carried essentially in same schema as used within Access, but simply in GML form.  It took Internet Explorer  6+ minutes to parse the thing, and (according to Task Manager) it occupied 1.2 gigs of memory after parsing.

A sample of the GML produced by the EPSG web site appears below.  Notice that this is rather unreadable, and contains more XML stuff than it does coordinate system stuff.  Also note, that the interesting stuff is only referenced, and you need the entire database, plus a program to get at it.  For example, aside from the name entry and the description, how do you determine the actual units of the coordinate system.

- <ProjectedCRS xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:epsg="urn:x-ogp:spec:schema-xsd:EPSG:0.1:dataset" xmlns:gml="http://www.opengis.net/gml" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns="http://www.opengis.net/gml" gml:id="epsg-crs-2232">
- <metaDataProperty>
- <epsg:CommonMetaData>
  <epsg:type>projected</epsg:type>
  <epsg:informationSource>National Geodetic Survey http://www.ngs.noaa.gov/INFO/Policy/st_plane.html</epsg:informationSource>
  <epsg:revisionDate>2001-11-06</epsg:revisionDate>
  <epsg:show>true</epsg:show>
  <epsg:isDeprecated>false</epsg:isDeprecated>
  </epsg:CommonMetaData>
  </metaDataProperty>
  <identifier codeSpace="EPSG">urn:x-ogc:def:crs:EPSG:2232</identifier>
  <name>NAD83 / Colorado Central (ftUS)</name>
  <remarks>State law defines system in US survey feet. Federal definition is metric - see code 26954. For applications with an accuracy of better than 3 feet, replaced by NAD83(HARN) / SPCS.</remarks>
  <domainOfValidity xlink:href="urn:x-ogc:def:area:EPSG:2183" />
  <scope>Large and medium scale topographic mapping and engineering survey.</scope>
  <conversion xlink:href="urn:x-ogc:def:coordinateOperation:EPSG:15314" />
  <baseGeodeticCRS xlink:href="urn:x-ogc:def:crs:EPSG:4269" />
  <cartesianCS xlink:href="urn:x-ogc:def:cs:EPSG:4497" />
  </ProjectedCRS>

Are better schemas for defining coordinate reference systems using GML available anywhere?

Just some info for the pot.

Norm


-----Original Message-----
From: Howard Butler [mailto:hobu.inc at gmail.com]
Sent: Monday, May 12, 2008 3:32 PM
To: Norm Olsen
Cc: metacrs at lists.osgeo.org
Subject: Re: [MetaCRS] 'FOSS Maintained' Source of CRS Definitions


On May 12, 2008, at 2:52 PM, Norm Olsen wrote:
>
> OPERATIONAL APPLICATION
>
> Establishing an operational site sounds like a nightmare for a
> volunteer based organization.  OGP/EPSG has established a web based
> site from which a web client can obtain EPSG definitions in GML
> form.  EPSG does not support all the definitions we would like.  So
> I think the appropriate course of action is to establish a working
> relationship with EPSG and use what they have established and work
> to get the definitions we require added to the database.
>
> There may be fees involved in using this service, but funds to
> operate need to come from someplace. :>)
>

At the time we rolled out http://spatialreference.org, the EPSG
registry was just coming into existence (I don't know who preceded
who, but EPSG's idea for the site must have existed for much longer
than the two days in which we conceived and implemented sr.org ;).
The EPSG registry website (http://www.epsg-registry.org) is atrocious
to use, especially from a hands-off, developer perspective.  One thing
we wanted sr.org to excel at was to allow softwares that can speak
HTTP to easily be able to fetch (and create new) coordinate reference
systems.  In that sense, I think sr.org has been a successful
demonstration as shown by proj4js' and GDAL's ability to consume
sr.org URLs and dereference them into something they can interpret. If
we were to take on building something (as http://spatialreference.org
or otherwise), I think that property of sr.org is an important one to
keep.

I'll confess to being quite naive when it comes to coordinate
reference system description, and I will gladly leave the details to
the experts like yourself who work with this stuff all day everyday.
On the other hand, I'm skeptical that coming up with a uber-
encompassing dictionary of descriptions is a project that has a high
probability of success.  A question I ask myself is if this problem is
solvable, why hasn't it been solved yet?  Is it merely a communication
problem, where getting all of the right people in a room can solve
it?  Is it a complexity issue, where all of the permutations of how
people/software can do things make capturing all of it a monumental
task?  Is it a political issue, where organizations like EPSG who act
as authorities move too slow to update their registry?  Does *THE
STANDARD* already solve it and it is just generally not in wide enough
use yet?

Is the juicy, solvable problem for MetaCRS the common description of
coordinate reference systems (and all of the details that you've
described), or is it software(s) that can speak all of the coordinate
reference system description languages that are out there (31 flavors
of WKT, proj, EPSG codes, etc) and act as a Babel Fish? Or, to be
successful, do we really have to tackle both?

> OK, you can wake up now.  I'm done.

Thanks for the excellent treatise of where things are currently.
Sorry that I just have more meandering questions to ask...

Howard