[Geoserver-devel] gt-imagemosaic-jdbc and axis-order problem

Bjorn_Hofling · February 28, 2013, 9:46am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cross-posting to both geoserver and geotools, because I'm not sure
where to correct this.

I have a JDBC-Imagepyramid datasource with a custom JDBCAccess class
and a config with <coordsys name="EPSG:31468"/>.

I try to access the data with the following WMS requests but WMS 1.3.0
fails:

#WMS 1.1.0, WGS84: works!

http://localhost:9090/geoserver/bvv/wms?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&BBOX=8.94724122,47.21154077,14.04130521,50.60175200&CRS=EPSG:4326&WIDTH=233&HEIGHT=231&LAYERS=dopjdbc&STYLES=&FORMAT=image/png&DPI=120&TRANSPARENT=TRUE

#WMS 1.3.0, WGS84: fails!

http://localhost:9090/geoserver/bvv/wms?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&BBOX=47.21154077,8.94724122,50.60175200,14.04130521&CRS=EPSG:4326&WIDTH=233&HEIGHT=231&LAYERS=dopjdbc&STYLES=&FORMAT=image/png&DPI=120&TRANSPARENT=TRUE

# WMS 1.1.0, 31468, false_easting first: works

http://localhost:9090/geoserver/bvv/wms?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&BBOX=4268853.907215,5234843.881984,4644617.698124,5609332.108789&CRS=EPSG:31468&WIDTH=233&HEIGHT=231&LAYERS=dopjdbc&STYLES=&FORMAT=image/png&DPI=120&TRANSPARENT=TRUE

#WMS 1.3.0, 31468, false_northing first: fails

http://localhost:9090/geoserver/bvv/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=5234843.881984,4268853.907215,5609332.108789,4644617.698124&CRS=EPSG:31468&WIDTH=233&HEIGHT=231&LAYERS=dopjdbc&STYLES=&FORMAT=image/png&DPI=120&TRANSPARENT=TRUE

With WMS 1.1.0 and axis-order false_easting first (=x first), I see
the expected map.

But with WMS 1.3.0 and axis-order false_northing (=y) first, I get an
empty map. When I look into the logs, this is no wonder:

27 Feb 16:27:41 WARN [org.geotools.gce.imagemosaic.jdbc] - The
requested envelope does not intersect the envelope of this mosaic,
result is a nodata image

27 Feb 16:27:41 WARN [org.geotools.gce.imagemosaic.jdbc] -
GeneralEnvelope[(5217821.6898565, 4253533.065954762),
(5624733.139761499, 4661551.259516895)]

27 Feb 16:27:41 WARN [org.geotools.gce.imagemosaic.jdbc] -
GeneralEnvelope[(4282000.0, 5238000.0), (4636000.0, 5606000.0)]

I further investigated this and found a problem in

ImageMosaicJDBCReader.transformRequestEvelope

With 1.1.0, input CRS (=state.requestEnvelope().getCoordRefSystem())
has EAST, NORTH. Is identical to this.crs. Identiy, return fine.

Now with WMS 1.3.0 we get as input CRS axis-order NORTH,EAST.
We calculate a MathTransform which is as expected the affine
transposition. Fine until here.

But then comes a section starting with the comment

//x Axis problem???

Here is the problem: Axis order is AGAIN switched, in this case in the
envelope. From my use case I would totally remove this section,
because it is already handled in GeoServer. But I have no idea in
which other cases this code makes sense (outside of GeoServer?).

Björn

- --
Dipl.-Inf. Björn Höfling
Software Developer (GIS, Java)
http://www.bjoernhoefling.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEvJ2oACgkQvyhstlk+X/0JAwCgtAOWlatOMY2XLu4bPEfLOWqj
YwgAn10QzVPJio9dm5x38l0oKmRTAvxo
=68oi
-----END PGP SIGNATURE-----

Christian_Mueller · March 4, 2013, 11:37am

Hi Björn

The module is part of geotools and used by geoserver. Since I do not want to break existing behaviour I can imagine the following solution.

Adding a new xml configuration element which defaults to false. If it is true, I can skip the code switching the x and y values.

In your concrete example, I assume if ignoreAxisOrder is true, your WMS 1.3.0 request will work but the WMS 1.0 requests will not. But we have to test.

Cheers
Christian

···

On 28 February 2013 10:46, Björn Höfling <bjoern.hoefling@…3672…> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cross-posting to both geoserver and geotools, because I’m not sure
where to correct this.

I have a JDBC-Imagepyramid datasource with a custom JDBCAccess class
and a config with .

I try to access the data with the following WMS requests but WMS 1.3.0
fails:

#WMS 1.1.0, WGS84: works!

http://localhost:9090/geoserver/bvv/wms?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&BBOX=8.94724122,47.21154077,14.04130521,50.60175200&CRS=EPSG:4326&WIDTH=233&HEIGHT=231&LAYERS=dopjdbc&STYLES=&FORMAT=image/png&DPI=120&TRANSPARENT=TRUE

#WMS 1.3.0, WGS84: fails!

http://localhost:9090/geoserver/bvv/wms?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&BBOX=47.21154077,8.94724122,50.60175200,14.04130521&CRS=EPSG:4326&WIDTH=233&HEIGHT=231&LAYERS=dopjdbc&STYLES=&FORMAT=image/png&DPI=120&TRANSPARENT=TRUE

WMS 1.1.0, 31468, false_easting first: works

http://localhost:9090/geoserver/bvv/wms?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&BBOX=4268853.907215,5234843.881984,4644617.698124,5609332.108789&CRS=EPSG:31468&WIDTH=233&HEIGHT=231&LAYERS=dopjdbc&STYLES=&FORMAT=image/png&DPI=120&TRANSPARENT=TRUE

#WMS 1.3.0, 31468, false_northing first: fails

http://localhost:9090/geoserver/bvv/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=5234843.881984,4268853.907215,5609332.108789,4644617.698124&CRS=EPSG:31468&WIDTH=233&HEIGHT=231&LAYERS=dopjdbc&STYLES=&FORMAT=image/png&DPI=120&TRANSPARENT=TRUE

With WMS 1.1.0 and axis-order false_easting first (=x first), I see
the expected map.

But with WMS 1.3.0 and axis-order false_northing (=y) first, I get an
empty map. When I look into the logs, this is no wonder:

27 Feb 16:27:41 WARN [org.geotools.gce.imagemosaic.jdbc] - The
requested envelope does not intersect the envelope of this mosaic,
result is a nodata image

27 Feb 16:27:41 WARN [org.geotools.gce.imagemosaic.jdbc] -
GeneralEnvelope[(5217821.6898565, 4253533.065954762),
(5624733.139761499, 4661551.259516895)]

27 Feb 16:27:41 WARN [org.geotools.gce.imagemosaic.jdbc] -
GeneralEnvelope[(4282000.0, 5238000.0), (4636000.0, 5606000.0)]

I further investigated this and found a problem in

ImageMosaicJDBCReader.transformRequestEvelope

With 1.1.0, input CRS (=state.requestEnvelope().getCoordRefSystem())
has EAST, NORTH. Is identical to this.crs. Identiy, return fine.

Now with WMS 1.3.0 we get as input CRS axis-order NORTH,EAST.
We calculate a MathTransform which is as expected the affine
transposition. Fine until here.

But then comes a section starting with the comment

//x Axis problem???

Here is the problem: Axis order is AGAIN switched, in this case in the
envelope. From my use case I would totally remove this section,
because it is already handled in GeoServer. But I have no idea in
which other cases this code makes sense (outside of GeoServer?).

Björn

Dipl.-Inf. Björn Höfling
Software Developer (GIS, Java)
http://www.bjoernhoefling.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEvJ2oACgkQvyhstlk+X/0JAwCgtAOWlatOMY2XLu4bPEfLOWqj
YwgAn10QzVPJio9dm5x38l0oKmRTAvxo
=68oi
-----END PGP SIGNATURE-----

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Bjorn_Hofling · March 5, 2013, 10:42pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Christian,

On 03/04/2013 12:37 PM, Christian Mueller wrote:

Hi Björn

The module is part of geotools and used by geoserver. Since I do
not want to break existing behaviour I can imagine the following
solution.

Adding a new xml configuration element <ignoreAxisOrder> which
defaults to false. If it is true, I can skip the code switching the
x and y values.

Since I too do not know which applications need this
axis-order-switching code, your solution sounds great.

In your concrete example, I assume if ignoreAxisOrder is true,
your WMS 1.3.0 request will work but the WMS 1.0 requests will not.
But we have to test.

No. When I comment out the axis-order code, it works perfectly well
for both WMS 1.1.0 and 1.3.0 versions.

The reason for this is that in 1.3.0 GeoServer already changes the
axis order in the input CRS and thus the calculated MathTransform is
already the transposition of x and y, i.e is the matrix

01
10

The MathTransform code is in line 343 of
modules/plugin/imagemosaic-jdbc/src/main/java/org/geotools/gce/imagemosaic/jdbc/ImageMosaicJDBCReader.java

But this hold of cause only in my case. I'm too unfamilar with the
Axis-Order-Handling of GeoServer. Maybe someone else knows for sure?

Björn

- --
Dipl.-Inf. Björn Höfling
Software Developer (GIS, Java)
http://www.bjoernhoefling.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlE2dL4ACgkQvyhstlk+X/3mcwCgpU4D8NLQs+e9KpOy2N+/qOoK
y6MAnjLHhv+xsgZsl97HvV1Kt0wSOvDr
=HNVs
-----END PGP SIGNATURE-----