[mapserver-dev] PROJ4 and EPSG database

Christopher Schmidt crschmidt at metacarta.com
Tue Feb 10 17:32:52 EST 2009


On Tue, Feb 10, 2009 at 02:29:39PM -0800, Paul Ramsey wrote:
> I've been thinking along the lines of a pure-C "libwkt" that parses
> any serialization and outputs any other serialization. Basically a
> central point of knowledge for things like "how does ESRI mangle WKT?"
> or "what CRS does this SRID apply to?".  I think having it separate
> from the re-projection engines themselves would be nice.

I had the same thought. I was convinced by the MetaCRS list I was
insane. Even just the various flavors of WKT is hell -- for example,
GeoTools and MapServer use a different flavor than CS-Map -- all when
trying to emulate "OGC" WKT.

This doesn't bring into account Oracle9, 10, 11 (all different), ESRI,
Autodesk, or other flavors of WKT that exist...

I'm supportive of the goal, but I'd recommend that this be treated as a
seperate effort, unrelated to the proj4+mapserver problems/not problems.

> These are all "good" solutions, but they aren't "fast" or "soon"
> solutions... we've got a bit of a hump problem, in that the
> incremental work to get a "good" solution exceeds the incremental
> benefit of the solution. A hack has better cost/benefit... we could
> enrich the epsg file with "swapped" tokens more easily. Heck, you
> could write a simple hack rule for Mapserver that says "all lonlat and
> these 12 planar projections are swapped" and cover all reasonable use
> cases.
> 
> Hrm, hrm.
> 
> P.
> 
> On Tue, Feb 10, 2009 at 2:00 PM, Daniel Morissette
> <dmorissette at mapgears.com> wrote:
> > As we all know, PROJ4's processing of init files (the infamous epsg file) is
> > quite slow and a few options have been discussed on this list to solve this,
> > going from optimizations directly in PROJ to caching in MapServer or even
> > having MapServer use its own optimized database.
> >
> > While working on WMS 1.3.0 we have come accross another need that PROJ4's
> > current init file setup doesn't address: the ability to lookup extra
> > information about a given SRS such as the axis order.
> >
> > That gives one more argument for leaving the current PROJ4 init stuff behind
> > and developing an optimized (but simple) SRS database system.
> >
> > I'd hate to do something specific to MapServer, so perhaps we could develop
> > a simple API that sits well on top of PROJ4 and that could be used by all
> > PROJ4-based applications to provide a shared projection database format and
> > API. We could even look at the database format used by other systems such as
> > GeoTools or GeoServer (I have no clue what they use, just thinking out loud)
> > so that we try sharing as much as possible with them. I'd like to discuss
> > that approach at the Toronto code sprint.
> >
> > This is turning into a question for the MetaCRS project, but I wanted to
> >  run the idea by the MapServer group first since we are the ones with the
> > most pressing need for this.
> >
> > Daniel
> > --
> > Daniel Morissette
> > http://www.mapgears.com/
> > _______________________________________________
> > mapserver-dev mailing list
> > mapserver-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/mapserver-dev
> >
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev

-- 
Christopher Schmidt
MetaCarta


More information about the mapserver-dev mailing list