[mapserver-dev] PROJ4 and EPSG database

[Paul Ramsey]

Well, yes, it's not an easy problem, but that also argues for  
centralizing the knowledge of this quite hard problem.  You are  
correct though, it's a problem in and of itself.  Binding it into the  
proj/mapserver issues makes the proj/mapserver issues look larger  
than they are.

P

On 10-Feb-09, at 2:32 PM, Christopher Schmidt wrote:

> 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


--
Paul Ramsey
OpenGeo - http://opengeo.org
PostGIS. Because you're just that good looking.