Simone Giannecchini wrote:
Hi Jody,
I have to admit that I have not had much time to follow the discussion
for GeoServer 1.4 (my fault). I will take a look as soon as possible
and I will also try to participate the IRC meetings.
Just a clarification, with these emails, I am trying to understand how
management of features works inside geoserver, I am not focusing on
WMS or WFS specifications. Assumptions made which work for features
might not work for coverages (and in fact they do not work).
The past versions of the WCS branch have been based on too many tricks
in order to bypass problems, I personally hate that but there was no
time (and not enough knowledge on our side I have to confess) to make
things better. What I am trying to do now, since now I am responsible
for the two branches (geoserver and geotools), is understanding
clearly how the official geoserver works otherwise the time spent on
the coverage branch will be wasted.
I had an email/jira back in September that really is *what we must do* -
from a doc that will come out in March:
The interpretation of this SRS tag is divided depending on the format
returned:
· EPSG:4326
The interpretation of this SRS is ambiguous in practice. The pragmatic
solution is to interpret the ordinates in eastward/northward order,
ignoring the specified order in the EPSG database.
This follows industry practice, and the use of EPSG codes by the early
WMS services. This is only a problem for a small percentage of the
allowable codes.
The approach is in conflict with the latest Web Map Server
specification, and represents a difference between practice and
correctness.
* URI
Understood to indicate CRS information directly as specified by
the European Petroleum Standards Group.
* WKT
Provides the WKT representation of the information retrieved.
* AUTO:42000,0,0,0
Reference to the AUTO projections maintained by the Web Map
Server specifications (both AUTO, and AUTO2 are in use). The
numbers used are “units”, “lat” and “long”. Please consult
document the WMS 1.1.1 specification for more information.
The best advice we were offered over the course of our integrated
client work was to treat “EPSG:1234” in the historical manner. Use the
new URI format wherever possible (as its meaning is clear and consistent).
In short "EPSG:####" will always be ill defined, and needs be we must
revert to the easting/northing access order. This
effects both WMS and WFS 1.0. These OGC specifications are kinda messed
and their is nothing we can do to untangle it
(except provide a swap access button on the configuration page). I do
not know if WCS is effected but I suspect so.
Enough cold hard truth.
What we can do is use the proper shiny new SRS URI format, it means the
same thing everywhere and is not effected
by mistakes from the past.
In short if you are using coverages at the geotools level - I never want
to hear us talk about "EPSG:4326" again. That is a
problem we can leave at the GeoServer side of the fence.
Since I have wasted weeks on this issue, I am going to go look up the
new format for you.
- OGC document 04-077, which defines URN's for Coordinate Reference Systems in
GML
- urn:ogc:def:crs:OGC:1.3:CRS84 is lon/lat WGS 84
- urn:ogc:crs:EPSG:6.7:4326 is lat/lon WGS 84
So the OGC steps in as their own authority here and defines "OGC:CRS84".
Once again the move to WFS1.1 and URI for SRS will solve this problem.
Jody
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
