Hi Dave, thanks for the answer. I am being so annoying on this issue because I am trying to spend a bit of time to improvme rendering of coverage in the WCS branch since the first time such capapbility came out basically as a plus, we did not really spent time on it.
The axes order problem has a big impact on rendering coverages and since I want to integrate with the existing structure as smoothly as possible, I would like to clearly understand the assumptions you made and the solutions you found. Toward the end of the week we should merge the latest geoserver 1.3.x onto our branch after that I might bother you a bit more with this issue since I want to make sure that I avoid introducing strange tricks in the rendering chains since I would like to see decent perfomances on the coverage side. Anyhow, I am using the geoserver with the EPSG-HSQL data store and features are rendered smoothly. This at the beginning surprised me a bit. I spent some time debugging a GetMap request on the states shapefile. My conclusion is that everything works great because the features to be rendered have the same issue with the axes, that is, they claim to use EPSG:4326 lat,lon but the underlying geometry is in lon,lat form therefore everything is consistent (the world to screen transform, the create map envelope etc..). Am I wrong here? If I am wrong what is the correct explanation? When rendering coverages this assumption cannot be made, otherwise reprojections and such won't work, that explains why I am being so annoying. By the way, the rendering of features has dramatically improved with respect to the old geoserver, good job guys! Simone. On 2/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Sorry, simone, I just got back from holidays so I didnt reply to your > message yet. > > We've has a few past discussion about the CRS axis. There is definately > a problem, as both you and martin have pointed out. > > Unfortunately, the solution isnt so easy. As Paul just pointed out, > almost everyone has geographic data in the "normal" (x,y) coordinate > order AND they call it 4326 (which is y,x order). > > So, even if we fixed what martin outlined (thanks martin!) we'd still > have a bunch of confusion. > > 1. People will be calling their data 4326 even though its really not > 2. People will be calling their Bbox's 4326 even thought they really > arent > > Most people are not even aware of the problem and will just think that > geotools/geoserver/udig isnt working correctly. After all, almost > every single other piece of software treats 4326 as (x,y). > > So, if people have (x,y) geographic data and they tag it as 4326 then > geotools dont have much of a chance of doing anything correctly. > > This is the main reason that geoserver is based on the EPSG WKT > .properties file CRS info. If you move to the HSQL one, most users > will find that their data is rotated 90 degrees when they try to > reproject it. By using the .properties file, we find that it works for > almost everyone. > > Unfortunately, there's people like you and martin who actually have 4326 > data in the correct axis order. > > We know that this is an issue, but there's not a really good solution to > it. > > dave > ps. I dont think PROJ.4 does any axis transformation by default (but I'm > not sure). > > > > ---------------------------------------------------------- > This mail sent through IMP: https://webmail.limegroup.com/ > ------------------------------------------------------- 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
