Hello All . . .
With regard to AXIS implementations:
I view the AXIS business in the same way most folks think of the Vista User Access Control: How do you turn the ?*%^~& thing off? While it is nice to be technically correct, in practical reality, it is a pain. Perhaps the CAD/GIS world I've been living in all these years is too limited; I can accept that. It's just that rigorously adopting the AXIS specifications of all coordinate systems produces many more support and maintenance headaches than it can ever be worth. When users import a data set into GIS, they expect to see what they normally see on a map. If they don't, they call for help. Being technically correct doesn't help pay the bills. Just my humble opinion.
In any case, that's why the CS_MAP approach is very simple and is probably what has been referred to as the "MapServer hack". Simply put, it's a simple enumeration of the various states:
{ 0, "X/Lng increases to the east, Y/Lat increases to the north" }, /* Default value */
{ 1, "X/Lng increases to the east, Y/Lat increases to the north" },
{ 2, "X/Lng increases to the west, Y/Lat increases to the north" },
{ 3, "X/Lng increases to the west, Y/Lat increases to the south" },
{ 4, "X/Lng increases to the east, Y/Lat increases to the south" },
{ -1, "Y/Lat increases to the east, X/Lng increases to the north" },
{ -2, "Y/Lat increases to the west, X/Lng increases to the north" },
{ -3, "Y/Lat increases to the west, X/Lng increases to the south" },
{ -4, "Y/Lat increases to the east, X/Lng increases to the south" }
This might be worth considering.
With regard to Datum parameters:
In the current CS-MAP you'll find a significant amount of code which deals with these issues. It's incorporated into the EpsgStuff modules. Using the EPSG database in csv form, it builds list of all the different ways to get from one datum to another. It properly handles concatenated operations and supports filtering out stuff like longitude translation (i.e. prime meridian shifting) and null transformations. CS-MAP uses it to decide what to compare against when seeking the verify if a CS-MAP definition jives with the EPSG version (most, but all, do). It ain't perfect, but perhaps it's a useful base for more work in this regard.
Norm
-----Original Message-----
From:
[hidden email] [mailto:
[hidden email]] On Behalf Of Frank Warmerdam
Sent: Thursday, October 01, 2009 1:06 PM
To: Christopher Schmidt
Cc:
[hidden email]
Subject: Re: [MetaCRS] proj4js and axis order
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,
[hidden email]
light and sound - activate the windows |
http://pobox.com/~warmerdamand watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
