Ciao Martin, thanks for the reply,
On 5/20/06, Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
Simone Giannecchini a écrit :
> Martin already implemented the OrderedAxisAuthorityFactory which
> should take care of this. I used it and I have to say that it works
> fine except that if I ask for an EPSG:4326 crs it gives, correctly, a
> lon,lat WGS84 but with no identifiers related to EPSG, so basically it
> is just a simple WGS84 geographic CRS with lon,lat axis and no
> authorithy identification. This is not suitable for most use cases in
> GeoServer since I need the Authority in order to be able to use the
> code in GetCapabilities and such.
The lack of authority identification is intentional. My interpretation was that
if
OrderedAxisAuthorityFactory modifies the axis order, it would be incorrect to
>claim that the
returned CRS is EPSG:4326. So OrderedAxisAuthorityFactory intentionally >remove
the authority
identification before to returns the transformed CRS. However, if it is a problem,
>we may revisit
that (or make it optional). But we would still have a philosophical issue: is it
>correct to keep an
"EPSG:4326" identification on something that is not anymore EPSG:4326 (well,
>not strictly speaking -
I realize that common usage still call that EPSG:4326).
Well, I looked up the code of that class and I noticed that you strip
some info and change some other when reordering the axis. This actions
are understandable but I am more concerned with what common practice
and OGC says about this thing. I am pretty sure that in gdal (which
uses Proj) EPSG:4326 is lon,lat as expected, moreover Jody told me
that OGC, after a long debat, now states that EPSG:4326 is lon,lat and
not lat,lon as EPSG db (please Jody help me here).
What I suggest is having an authority that tries to follow OGC
convention and common convention and probably without making it the
default one (although I personally would like to do it), in order to
have CRSs behave as expected: if I ask EPSG:4326 I would like to see
lon,lat instead of lat,lon and, morevoer, once I get this crs and I
ask for the code I want to get 4326 not "modified axis whatever" :-) .
> David is going to refactor the streaming renderer shortly, I think it
> would be worth to tackle this problem before he start doing his job,
> which btw is great since performances of the StreamingRenderer has
> improved a lot.
I can' resist to the tentation to remind that J2D-render was handling correctly
axis swapping for
years (but lack Feature and Style support, I admit)...
Do not worry Martin, I am looking at the code of the J2DRenderer and I
am also looking at the new classes you are developing in order to
remove any possible wrong assumption regarding the axes order in
StremingRenderer, but the issue we are discussin here is affecting us
all, feature, coverage and renderers. No matter how careful you are
with checking axes order, if the axes order is wrong you'll neve make
things right.
Good news is, I might have found a guy to do his master thesis on
advanced geospatial rendering. I would like to reuse your experience,
the GO1 code, the old J2DRenderer code and a bit of my experience. He
should start in september, let's hope tht we get this thing going.
Simone.
Martin.
--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant
http://simboss.wordpress.com/
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
