[mapserver-dev] PROJ4 and EPSG database

[Paul Ramsey]

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.

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
>