[MetaCRS] proj4js and axis order

[Frank Warmerdam]

Christopher Schmidt wrote:
> On Thu, Oct 01, 2009 at 08:03:00PM +0200, Bart van den Eijnden (OSGIS) wrote:
>> Indeed, thanks for the detailed explanation Chris.
>>
>> So there are no plans to extend the proj4js projection object with this  
>> info? That will make it really hard to make a generic WMS 1.3 javascript  
>> client ..... maybe I can take a shot at it with a few pointers.
>>
>> Chris, can the axis order info be retrieved through  
>> spatialreference.org, and if so, how? TIA.
> 
> not that I'm aware of. Some projections (not supported by GDAL) may
> have "AXIS" things in the WKT, but since the primary source for a lot
> of them is GDAL/OGR/proj (which don't store this information), any that come 
> from that source will not have the information available.

Folks,

Given sufficient interest, I'd like to see us make progress on better axis
orientation handle (xy vs. yx as well as mirroring such as coordinate
systems with westing, southing instead of easting, northing) in
OGRSpatialReference, PROJ.4 and spatialreference.org.

There is some limited knowledge about axis orientation now in
OGRSpatialReference, as noted, via the AXIS keywords and OGRSpatialReference
has some methods to get the true EPSG axis definitions as opposed to
the default action which is still long,lat for geographic coordinate systems
to match common gis practice.  I'd like to introduce axis orientation keywords
into PROJ.4 which would be applied as part of pj_transform() (but not affecting
the core code in PROJ.4).   Hopefully proj4js could incorporate support
for such a keyword once done in PROJ.4.

Some coordination with existing hacks for axis support in MapServer
may be needed.

The other area I'd love to make progress, specially in spatialreference.org,
is having it provide a full list of EPSG provided datum shift parameters
when inspecting a coordinate system.  This will need to be accomplished
by direct query of the EPSG database since these options cannot currently
be carried through OGRSpatialReference in the form of WKT.

I'm willing to do some hacking on this.  I'll try and look into how to setup
a private development instance of spatialreference.org once that is in svn.

Some work might also be appropriate in how the libgeotiff EPSG translation
code decides on a datum shift for a given datum.  Currently it provides
no datum shift values if there are more than one possible under the assumption
picking randomly is worse than not picking and hopefully forcing the user
to realize they need to find one appropriate to their circumstances.  This
approach (of mine) has been rightly a subject of much complaint.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent