I recently installed GeoServer 2.0 and was very impressed with both the appearance and the functionality, most of which worked very well with a DB2 data store.
The preview using OpenLayers failed with coordinate out of bounds due to the following query:
SELECT "OBJECTID",db2gse.ST_AsBinary("SHAPE") as "SHAPE" FROM "SDE"."US_STATES" WHERE db2gse.st_intersects("SHAPE", db2gse.st_polyfromtext('POLYGON ((-198.751262695315 9.09648828125, -46.435737304686995 9.09648828125, -46.435737304686995 81.23451171875001, -198.751262695315 81.23451171875001, -198.751262695315 9.09648828125))',1014)) = 1
The longitude value -198.75 is causing the problem because we only allow longitude values between -180 and +180. It isn't clear how the extents of this polygon are being determined. The longitude values are about 20 degrees greater/less than the layer bounds in the longitude direction and about 10 degrees greater/less than the layer bounds in the latitude direction.
The preview using JPEG issues the following query:
SELECT "OBJECTID",db2gse.ST_AsBinary("SHAPE") as "SHAPE" FROM "SDE"."US_STATES" WHERE db2gse.st_intersects("SHAPE", db2gse.st_polyfromtext('POLYGON ((-178.37715450643776 18.765966666666667, -66.80984549356222 18.765966666666667, -66.80984549356222 71.56503333333333, -178.37715450643776 71.56503333333333, -178.37715450643776 18.765966666666667))',1014)) = 1
These coordinates are much more palatable and are very close to the bounds that are shown in the properties of the layer.
It results in a nice map of the United States.
Can anyone explain this?
David Adler ha scritto:
I recently installed GeoServer 2.0 and was very impressed with both the appearance and the functionality, most of which worked very well with a DB2 data store.
The preview using OpenLayers failed with coordinate out of bounds due to the following query:
SELECT "OBJECTID",db2gse.ST_AsBinary("SHAPE") as "SHAPE" FROM "SDE"."US_STATES" WHERE db2gse.st_intersects("SHAPE", db2gse.st_polyfromtext('POLYGON ((-198.751262695315 9.09648828125, -46.435737304686995 9.09648828125, -46.435737304686995 81.23451171875001, -198.751262695315 81.23451171875001, -198.751262695315 9.09648828125))',1014)) = 1
The longitude value -198.75 is causing the problem because we only allow longitude values between -180 and +180. It isn't clear how the extents of this polygon are being determined.
OpenLayers is coming up with them. It usually enlarges the area to
be requested a bit.
In general WMS clients won't be geographic aware and will ask for maps
that go beyond the normal geographic data range.
It's up to the server to deal with that.
Considering that it's still not uncommon to just throw 4326 when one
does not know the actual SRS (which might be projected) having the
server cut the area to the acceptable range will be just a way to shoot
ourselves in the feet.
Moreover people dealing with cartography at the dateline might actually
have coordinates that span the antimeridian, many data storage options
won't mind (shapefiles, mysql, postgis, ...)
So what do we do? Well, we had the same problem in Oracle, and in the
Oracle specific code there is a bit that checks with the database if
the current SRID is geodetic, and if so, it cuts the query window
to the normal geographic range to avoid Oracle returning unexpected
results.
I guess the same has to be done with DB2?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.