[bezema@lat-lon.de: Re: [martin.desruisseaux@geomatys.fr:Re:[MetaCRS] Introduction]]

[Landon Blake]

I appreciate having someone from the deegree Project involved in this
discussion, and I wanted to respond to some of Rutger's comments.

Rutger wrote: " I think Frank Warmerdam's point, that '...there are
definitions EPSG doesn't want to represent for good reasons', is valid.
I believe it to be one of the
reasons, that the creation and maintanance of one super crs library will
be a
project with lots of 'extreme timeconsuming' side effects, and with
marginally
gains."

I have a couple of questions here. My first questions is this: How does
the EPSG decide which CRS definitions are included in their database,
and which are excluded? I have no doubt they are a smart group (they are
surveyors, after all) but I'm curious how these decisions are made. I
suspect the criteria that serve their group may not be the best criteria
for our group, though I could be mistaken in this regard.

You also mentioned "extreme timeconsuming side effects" and marginal
gains. Could you be more specific about these? What time consuming tasks
would be involved, and what would be gained? I'm not necessarily
disagreeing with your assessment, but I think it is important to examine
specifics so that good decisions can be made.

I would argue the benefits of a shared CRS library with this example:

In your e-mail you identified at least 4 existing sources of CRS
definitions. [1] proj4 configuration files, [2] iso 19111/GML, [3] EPSG
database, and [4] deegree CRS format. There may be others. (I think an
ESRI format was mentioned.)

Let's imagine for a minute, that the NGS in the United States actually
received adequate funding, and was able to perform survey work and
adjustments necessary for the definition of a new, official horizontal
datum. Will call it NAD09. NAD09 will be a replacement of NAD83. It
would be used across the United States, and possibly in parts of Canada
and Mexico. In addition, several states decide to revamp their State
Plane Coordinate Systems to coincide with the switch to a new horizontal
datum. Some of these states add zones, some remove zones, and some
switch to a new type of projection altogether. (This has happened
before.)

Our buddy Frank is on the ball. He was able to get some funding, and has
updated all of the proj4 configuration files to reflect the changes. But
the boys at the EPSG are behind the 8 ball. They haven't made the
changes. Neither has the deegree project, most of their customers are in
Europe, and they aren't terribly excited about paying for updates to CRS
definitions used exclusively in North America.

Now we've got a real chocolate mess.

But, if we had a single "super CRS" library", Frank, the programmers
from the deegree Project, and the programmers from OpenJUMP (especially
those in North America) could coordinate a single update of one source
of CRS definitions. That means one update,  one download, on source for
the latest and greatest CRS information. It means that we aren't
repeating the same update work across four (4) or (5) CRS definition
libraries.

Let me share another example:

Suppose we decide that a shared CRS library isn't worth the hassle, or
we all can't agree on a format. So we decide that each project will
share some test cases, but that we'll still independently access the
different CRS definition libraries from our own code, or our own home
grown files.

Now the boys at the EPSG decide that their database needs some tweaking.
So the switch some tables around or they make some other modifications
that really make sense given the changes in their industry.

Now, each one of our projects has to modify their code that accesses the
EPSG database to handle the new changes. If instead, we had a process to
reflect changes in the EPSG database in our own shared CRS library, we
could focus these efforts in a single place, as a team.

One last thing...

I'm not saying that our shared CRS library needs to include every
conceivable CRS definition known to mankind. We could only include the
most popular or the most traditional. That would ease maintenance. We
could then establish our own procedures for excluding or including CRS
definitions in the library.

More importantly, if we choose to store CRS definitions in a human
readable text format, small players would be able to distribute CRS
definitions to others in a form that could be used by many FOSS GIS
programs. For example, if I'm the City Surveyor for a large
municipality, and I establish a CRS that best suits my City's needs, I
can now distribute the definition of this CRS to others in a format they
can use. I don't have to worry about it not being included in the EPSG
database, or in the proj4 configuration files. I know this may sound
silly, but wait until you have a mapping project for a Wilderness Area
that is sliced in two parts by the line between UTM zones, and is also
conveniently bisected by the California State Place Coordinate System
zones. :]

Landon


-----Original Message-----
From: Rutger Bezema [mailto:bezema at lat-lon.de] 
Sent: Thursday, May 15, 2008 2:28 AM
To: Landon Blake
Cc: metacrs at lists.osgeo.org
Subject: Re: [bezema at lat-lon.de: Re:
[martin.desruisseaux at geomatys.fr:Re:[MetaCRS] Introduction]]

Hi all, 

Currently the deegree crs package is able to use the proj4 configuration
files and
the deegree crs format (a schema is available) which was partially
created from
the proj4 (4.6) epsg file.  The srs framework provides a mechanism to
use other
backends though, we are currently thinking about the implementation of a
subset of iso
19111 (gml:dictionary) and a wkt parser as well.  The direct usage of
the epsg database is not implemented yet, but it is a good idea which
will
probably be quickly possible as soon as the iso 19111 subset
implementation is
finished.  

I think Frank Warmerdam's point, that "...there are definitions EPSG
doesn't
want to represent for good reasons", is valid. I believe it to be one of
the
reasons, that the creation and maintanance of one super crs library will
be a
project with lots of 'extreme timeconsuming' side effects, and with
marginally
gains. In my opinion the geotools and deegree approach to supply
different
file format readers, will --in the end-- keep the sub sets of databases
managable
without having to reinvent the wheel every time.

I believe a collection of such standardized 'Providers' would be most
beneficial
for all spatial referencing projects, independent of the programming
language.

With kind regards,
Rutger Bezema

I would like to 
Landon Blake wrote:
> I think it would be prudent to set aside the GeoAPI debate for the
time being. I'm working with Tyler to set up a Java Collaboration
mailing list, and I think this topic will be more appropriate for that
forum.
> 
> Having said that, I would like to learn more about the GeoTools CRS
code and deegree CRS code in a specific aspect. I think this aspect
would be of interest to all on this mailing list, not just the Java code
slingers. :]
> 
> How did GeoTools and deegree each choose to integrate the EPSG
database? Are you tapping into the database directly, or did you convert
the information in the EPSG database into another format? What plan or
system does your project have in place to stay current with the EPSG
database?
> 
> I think this topic may be of greater interest to all.
> 
> Landon

-- 
l a t / l o n  GmbH
Aennchenstrasse 19           53177 Bonn, Germany
phone ++49 +228 184960       fax ++49 +228 1849629
http://www.lat-lon.de        http://www.deegree.org

-------------------------------------------------------
On June 17 is deegree day - Am 17. Juni ist deegree day
              http://deegree.org/deegreeday


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.