[mapserver-users] Projection EPSG code for LCC in mapserv 3.5

[Craig Bruce]

Paul Ramsey <pramsey at refractions.net> wrote:

> This dependence on the EPSG authority has got to be the worst aspect of
> the WMS spec. There are scads of useful (and widely used!) projections
> which EPSG does not have codes for. So now people are just randomly
> adding codes willy nilly. ESRI has already done so, in their
> "predefined" projections provided with ArcGIS8. They took the EPSG list,
> dropped a few projections, and then added a bunch of new ones of their
> own. I can send a proj4-style epsg file with the ESRI-added codes to
> anyone who needs it.

The reason that the EPSG approach was incorporated is that a concrete
list of codes makes it easy for a map server to describe to its client
what coordinate systems are available for its layers.

An alternate approach for fully dynamic coordinate systems would be for
the map server to describe what projections and datums are available from a
well-known list.  (Ellipsoids can be fully described parametrically.)  This
method would need to be in addition to the present fixed-coordinate-system
method, since some map servers and layers may only be available for very
specific projection parameters.

> What I do not understand is why the WMS spec does not support WKT as a
> means of defining projection information in the first place. Ironically,
> ArcIMS *does* support WKT for defining projection information.

Our map server will actually accept WKT strings (at least as [almost]
defined in OGC SQL Simple Features 1.0), e.g.:

http://www.cubewerx.com/demo/cubeserv/cubeserv.cgi?VERSION=1.1.0&REQUEST=GetMap&SRS=PROJCS["WGS84/LCCCanada",GEOGCS["WGS84",DATUM["WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Decimal_Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["Central_Meridian",-95],PARAMETER["Latitude_of_Origin",0],PARAMETER["Standard_Parallel_1",49],PARAMETER["Standard_Parallel_2",77],PARAMETER["False_Easting",0],PARAMETER["False_Northing",-8000000],UNIT["Meter",1]]&BBOX=1662867.0162,-1442055.790776781,2502867.0162,-1022055.790776781&WIDTH=600&HEIGHT=300&LAYERS=RELIEF%3AFoundation,GTOPO30%3AFoundation,POLBNDL_1M%3AFoundation,COASTL_1M%3AFoundation&STYLES=,,,&FORMAT=image%2Fpng&BGCOLOR=0xFFFFFF&TRANSPARENT=FALSE&EXCEPTIONS=application%2Fvnd.ogc.se_inimage

We will also accept proj4 strings, though we don't handle them as well.

> Daniel Morissette wrote:
> > Question to Frank W: Do you think the 42100-42399 custom EPSG codes
> > could be added to the official "epsg" file distributed with PROJ4?

My understanding is that codes 32768+ are reserved for private use, so
officially approved EPSG codes would need to be remapped.  The ones that
we define ourselves tend to be quite ad-hoc.

Rob Atkinson <rob at socialchange.net.au> wrote:

> IMHO - and I've been involved with both mapserver and WMS since inception, the
> use of codes allows a greater degree of discovery through service registries,
> and ability of client to discover how to negotiate a binding with the service.
> WMS is all about interoperability after all. The lack of a better taxonomy is
> a broader issue - the solution would be to have an active engagement with an
> ISO process so that each country has a simple means to register its WKT
> (actually the model for the projection) and get a code assigned as required.

Personally, I tend to think that the whole registry craze is a bit
over-rated.  Basically, it adds a level of indirection without any
actual additional functionality.  (Well, in this context... it does add
the ability to search for things that are worth searching for, like data
sets, but that's not really relevant for coordinate systems.)  Both the
client and the server need to understand the representation that is used
to describe the coordinate system inside of the registry in addition to how
to use the registry.  This same information could be easily passed in-line
in requests and capabilities, without the need for registry lookups.

An advantage of the registry approach is that lists of coordinate systems
can be more compact since only code values are used.  A disadvantage
is that, like the EPSG approach, only a finite set of projections can
be described, so a dynamic approach is still needed to handle arbitrary
projection parameterizations.

"Martin Daly" <martin at cadcorpdev.co.uk> wrote:

> My understanding was that using "EPSG:xxxx" was a pragmatic solution to a
> complex problem.  GML 3.0 will have XML encoding of co-ordinate reference
> systems (much more powerful than existing WKT), and support for CRS
> dictionaries, e.g. for on-line repositories containng CRS definitions that
> can be referenced with a URI.

Does it provide a mechanism for a server to describe what datums and
projections are available so that a client can construct arbitrary
parameterizations?

--------------------------+------------------------+--------------------------
Dr. Craig S. Bruce        | Tel: 819-771-8303 x205 |             CubeWerx Inc.
Senior Software Developer |   Home: 613-565-1344   |      Hull, Québec, Canada
csbruce at cubewerx.com      | http://www.csbruce.com |  http://www.cubewerx.com/
--------------------------+------------------------+--------------------------
                    "Halting problem, Schmalting problem!"