I am ansering the two previous email from Martin.
On 2/18/06, Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
> Simone Giannecchini a écrit :
> > In the getmap request, if I am right, the envelope is lon-lat
> > regardless the crs. This means that if I request a map with SRS
> > epsg:4326 we receive a bbox with lon first but we should internally
> > handle with lat first.
>
> If I'm understanding right, the WMS specification always put longitude
> first. But I was at the OGC meeting last September, and the CRS working
> group insisted loudly that the WMS specification is wrong in this
> regards, and the official order should really be (latitude,longitude). I
> don't know how they plan to do that.
>
> The confusion exists in the EPSG factories too. In Geotools, epsg-wkt
> always use (longitude,latitude) order as in WMS usage, while epsg-hsql,
> epsg-access and epsg-postgresql use the official (latitude,longitude)
> order. However, this confusion is not particular to Geotools. In the OGC
> meeting, it has been reported that (longitude,latitude) and
> (latitude,longitude) orders are found in different products for the same
> EPSG code.
>
> In Geotools 2.2, the following class has been added as a partial attempt
> to adress this problem:
>
> org.geotools.referencing.factory.OrderedAxisAuthorityFactory
>
> This class creates CRS using an arbitrary factory (e.g. epsg-hsql) and
> reorder axis in (longitude,latitude) order before to returns it to the
> user. This provided as an attempt to bring epsg-hsql to users expecting
> the same axis order than epsg-wkt.
>
Cool, I will take a look at it.
>
> > Despite of this in RenderUtilities the worldToScreenTransform assumes
> > that the crs is always lon,lat, is this an error or it is stupid me?
>
> I have not yet looked at RenderUtilities, but if it assumes that CRS is
> always (longitude,latitude), than I think that RendererUtilities would
> need to be improved. A good renderer should always work with arbitrary
> axis order for every operations.
>
Coudl you spend 5 minutes and take a look? I am trying to improve the
rendering of raster in our GeoServer and all this confusion about axis
order is a real pain for me. I fixed the problem writing a new
worldToScreenTransform method which takes into account the CRS without
making any assumptions.
I think the source of all my problems is the usage of the JTS envelope
plus epsg_wkt. The JTS envelope does not carry along a crs while the
espg_wkt uses lon,lat instead of lat,lon. In the version of the WCS we
are building right now we have removed dependecies from JTS.Envelope
everywhere but a lot of them remain in the WMS for features. The point
of all this discussion is see if we can reamove this depency and adopt
the GeneralEnvelope as we do in the WCS.
> Martin.
>
>
On 2/18/06, Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
> Jody Garnett a écrit :
> >> Despite of this in RenderUtilities the worldToScreenTransform assumes
> >> that the crs is always lon,lat, is this an error or it is stupid me?
> >>
> > Um we use StreamingRenderer all the time with all sorts of projections.
>
>
> Yes, but if the projections come from epsg-wkt, lets remind that this
> factory uses (longitude,latitude) axis order for every CRS, in
> disagrement with the official EPSG database. Was StreamingRenderer tried
> with CRS created by epsg-hsql?
>
> Martin.
All the test I have done were performed using epsg-hsql. I can
confidently state that if the crs is EPSG:4326 and comes from
ESPG-HSQL the actual worldToScreen Transform failes. Let's see how
this happens:
/**
* Sets up the affine transform <p/>
* ((Taken from the old LiteRenderer))
*
* @param mapExtent the map extent
* @param paintArea the size of the rendering output area
* @return a transform that maps from real world coordinates to the screen
*/
public static AffineTransform worldToScreenTransform( Envelope
mapExtent, Rectangle paintArea ) {
double scaleX = paintArea.getWidth() / mapExtent.getWidth();
double scaleY = paintArea.getHeight() / mapExtent.getHeight();
double tx = -mapExtent.getMinX() * scaleX ;
double ty = (mapExtent.getMinY() * scaleY) + paintArea.getHeight();
AffineTransform at = new AffineTransform(scaleX, 0.0d, 0.0d,
-scaleY, tx, ty);
AffineTransform
originTranslation=AffineTransform.getTranslateInstance(paintArea.x,
paintArea.y);
originTranslation.concatenate(at);
return originTranslation!=null?originTranslation:at;
}
This is the incriminated method. As you can easily see from the
computation of scaleX, the assumption that the CRS for the supplied
ampExtent (a JTS Envelope) is LON,LAT hence this method fails if the
CRS is LAT,LON.
Tomorrow I will investigate how this problem has been overcome in the
features rendering part of the StreamingRenderer, in order if possible
to provide the same solution in the GridCoverageRenderer I am
refactoring for the Coverage branch.
Anyway, it might be tht I am wrong and the problem I see does not
exist. I would like one of the active developers of the Geserver to
take 5 minutes to read these emails in order to hear what they say
about this.
Simone.
-------------------------------------------------------
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
