[CITE-Forum] Solved

Sebastian Goerke goerke at lat-lon.de
Tue Apr 2 04:01:56 EDT 2013

Hash: SHA1

Hi Arnulf,

the WMS spec says in

If a request contains an invalid BBOX (e.g. one whose minimum X is
greater than or equal to the maximum X, or
whose minimum Y is greater than or equal to the maximum Y) the server
shall throw a service exception.

This implicates, that requesting a bbox with equal ll and ur is
impossible for compliant WMS implementations. As a consequence, there
is somehow an implicit requirement for WMS servers, not to advertise
such bounding boxes as they are not useable. Maybe this is something
for a change request.



- -- 
l a t / l o n  GmbH
Aennchenstrasse 19               53177 Bonn, Germany
phone ++49 +228 18496-0          fax ++49 +228 18496-29
http://www.lat-lon.de            http://www.deegree.org

Am 31.03.2013 16:36, schrieb Arnulf Christl:
> On 03/29/2013 06:56 PM, Andreas Schmitz wrote:
>> Arnulf Christl wrote:
>> Hi Arnulf,
>>> I might be wrong but apparently in some queries the test
>>> engine asks for a BBOX with zero extent. This produces an error
>>> on the server side (in my opinion correctly) which is
>>> interpreted by the test engine as a failure of the test in
>>> question.
>>> URL generated by the test engine: 
>>> http://metaspatial.net/cgi-bin/ogc-cite-data-wms.xml?&LaYeRs=Bridges&WiDtH=100&HeIgHt=100&I=50&BbOx=0.0007,0.0002,0.0007,0.0002&CrS=EPSG%3A4326&ReQuEsT=GetFeatureInfo&InFo_fOrMaT=text%2Fhtml&J=50&StYlEs=&FoRmAt=image%2Fpng&QuErY_LaYeRs=Bridges&VeRsIoN=1.3.0
When the bbox is corrected (by adding 0.00001 deg to the ur
>>> coordinate) it works fine: 
>>> http://metaspatial.net/cgi-bin/ogc-cite-data-wms.xml?&LaYeRs=Bridges&WiDtH=100&HeIgHt=100&I=50&BbOx=0.0007,0.0002,0.00071,0.00021&CrS=EPSG%3A4326&ReQuEsT=GetFeatureInfo&InFo_fOrMaT=text%2Fhtml&J=50&StYlEs=&FoRmAt=image%2Fpng&QuErY_LaYeRs=Bridges&VeRsIoN=1.3.0
>> I'm unsure how that happens, but deegree for example always
>> sends a service exception in case minx == maxx or miny == maxy,
>> and we pass the tests. However, your service advertises the
>> mentioned request box as the layer's bounding box, the scripts
>> probably just try to request the layer with its advertised
>> bounding box.
>> Best regards, Andreas Schmitz
> Hi Andreas, thanks for the quick answer. This is actually an
> interesting snag for testing. As you correctly suggest the problem
> arises because of the zero extent advertized in the capabilities of
> this layer - which is used by the test engine without checking for
> viability (a dumb client so to say).
> If not manually specified MapServer will dynamically compute the
> BBOX by querying the data in question. For the Bridge layer with a
> single point the BBOX is (correctly) computed to have identical
> coordinates for ll and ur - a zero extent. Which is probably
> correct even if not very useful. So both MapServer and the test
> engine do the correct thing but end up with a failure anyway.
> My workaround is now to manually configure a BBOX which is has a
> width and height larger zero. MapServer 6.2 passes the test without
> error now.
> Thanks for the hint.
> To avoid this from happening to other people we could simply add 
> another bridge to this CITE test data layer.
> Cheers, Arnulf
>> _______________________________________________ CITE-Forum
>> mailing list CITE-Forum at lists.opengeospatial.org 
>> https://lists.opengeospatial.org/mailman/listinfo/cite-forum
> _______________________________________________ CITE-Forum mailing
> list CITE-Forum at lists.opengeospatial.org 
> https://lists.opengeospatial.org/mailman/listinfo/cite-forum
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/


More information about the CITE-Forum mailing list