New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Axis order in WMS 1.3.0 #3582
Comments
Author: rouault |
Author: assefa I am not really familiar with the projection details so some questions: would OSREPSGTreatsAsLatLong return true for codes that use inverted axis? Is the axis ordering info read from the espg file? |
Author: rouault OSRImportFromEPSGA(hSRS, nEPSGCode); // see http://gdal.org/ogr/classOGRSpatialReference.html#aa6965a1df98cdc673dfb20697eab613 For OSREPSGTreatsAsLatLong() apparently it only deals with geographic systems and not projected systems. So perhaps the logic should be customized to deal with that case. |
Author: elzouavo |
Author: assefa Checking this earlier, I was able to test for wms cases the use of OSRxxx functions mentioned in this bug. It works as excepted, provided that all the utility files are found (gss.csv, ....) |
Author: rouault |
Author: warmerdam I'm pretty nervous about MapServer having to make extensive use of OGRSpatialReference for common cases of EPSG handling. Perhaps it would be better to pre-generate a small axis-orientation table and embed this in MapServer along with a script to regenerate it at will? |
Author: assefa |
Author: assefa Frank do you see any problem using the msIsAxisInverted function in msLoadProjectionString (mapfile.c)? |
Author: warmerdam This looks great, thanks! |
Author: elzouavo |
Author: assefa |
Author: mko , but according to http://www.epsg-registry.org/ epsg:4559 has east/north orientation, so the inverted flag should be removed for this code.'''2''' all occurrences of '''3''' MapServer 6 is still not in line with WMS 1.3.0 regarding the axis order. The list of inverted epsg codes is unsatisfying and will result in servers running MapServer 6 correctly handling the axis order (user-compiled version with a fully adjusted mapaxisorder.h), partly correct axis order (some adjustments), the default mapaxisorder.h, different pre-compiled package versions or even worse. Quickly querying the epsg database
there should be about 1700 epsg codes with axis order north/east; unaudited mapaxisorder.h attached to this ticket. In order to make MapServer serving WMS 1.3.0 correctly, we should examine the list of epsg codes and implement them. Otherwise users will have ongoing troubles with WMS 1.3.0. |
Author: assefa
Should this be applied this for 6.0, rc2 is tomorrow? I am questioning this mainly because the mechanism used to check this list goes through the table 1 by 1 and is not optimized for a large table. I don't thing it is really costly compared to drawing time though. Also the list is not confirmed although It is the best list available (at least for me since I lack specific knowledge on this matter). Maybe in a point release would be more appropriate. |
Author: assefa |
Author: assefa "anther possible optimization (for a future release) could be to use a bit array instead of a table of epsg codes as we have now. EPSG codes must be in the range 0-32767 AFAIK (codes above 32767 are not official EPSG AFAIK)... so that would mean a bit array of 4096 bytes (smaller than the current array of codes) and a lookup would be very fast" |
Author: dmorissette |
Author: assefa The comment was valid the first time the patch was put. Long story short, better create a new patch entry instead of using the same one to avoid this kind ofconfusion. |
Author: dmorissette |
attachment http://trac.osgeo.org/mapserver/attachment/ticket/3582/mapaxisorder.h :
|
attachment http://trac.osgeo.org/mapserver/attachment/ticket/3582/3582.patch :
|
Reporter: elzouavo
Date: 2010/10/21 - 08:57
Trac URL: http://trac.osgeo.org/mapserver/ticket/3582
WMS 1.3.0 standard says "Coordinates shall be listed in the order defined by the CRS and shall be mapped appropriately...".
MapServer 5.6.5 hard codes that EPSG codes between 4000 and 5000 all have axes with an inverted order.
Currently, I have to update my data servers to add the EPSG codes for French overseas territories (with GRS80). In addition I have to add the codes for the INSPIRE directive (for France metropolitan).
It turns out that EPSG codes:4559 (French Antilles) and EPSG:4471 (Mayotte) are in the range 4000-5000 but have not reversed axes order in the EPSG database (which is correct). So, customers who question my WMS servers must make wrong requests to have a right result!
With EPSG codes recommended by the European INSPIRE directive, only the EPSG:4258 is properly handled by MapServer 5.6.5 (range 4000-5000). All other concerning France (EPSG:3042, EPSG:3043 and EPSG:3044) and Pan-Europe EPSG:3034 and EPSG:3035, by definition, have reverse axes order. However, they are not in the range 4000-5000, MapServer takes as coordinate systems with "normal" axes order (longitude, latitude).
Again, customers who request my WMS servers must do (if possible ...) false queries for correct answers!
I realize that WMS 1.3.0 standard (and WFS 1.1.0) brings news in coordinate systems which are not easy to integrate.
OpenLayers 2.10 has added parameter yx for "layers" (which allows great flexibility).
I'm not a developer so I have no advice to give. But would not it be interesting to add a parameter in the configuration of MapServer to point to a list of codes that must be considered with inverse axes order.
Example:
CONFIG "CRS_YX" "C:/somedir/crs_yx.txt"
Best regards.
The text was updated successfully, but these errors were encountered: