[CITE-Forum] Solved

Richard Martell rmartell at galdosinc.com
Tue Apr 9 14:05:56 EDT 2013


Hi all,


Clause 6.7.4 in ISO 19128 (WMS 1.3) states that: 

"A Bounding Box shall not have zero area."


This constraints applies to both service metadata and requests.
If the current test suite does not verify this for the capabilities 
document (getcapabilities.xml doesn't appear to), then a new test 
is warranted.


--
Richard


> -----Original Message-----
> From: 
> cite-forum-bounces+rmartell=galdosinc.com at lists.opengeospatial
> .org 
> [mailto:cite-forum-bounces+rmartell=galdosinc.com at lists.openge
> ospatial.org] On Behalf Of Sebastian Goerke
> Sent: Tuesday, 02 April, 2013 01:02
> To: cite-forum at lists.opengeospatial.org
> Subject: Re: [CITE-Forum] Solved
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Arnulf,
> 
> the WMS spec says in 7.3.3.6
> BBOX:
> 
> 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.
> 
> Regards
> 
> Sebastian
> 
> - -- 
> 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=B
> ridges&WiDtH=100&HeIgHt=100&I=50&BbOx=0.0007,0.0002,0.0007,0.0
> 002&CrS=EPSG%3A4326&ReQuEsT=GetFeatureInfo&InFo_fOrMaT=text%2F
> html&J=50&StYlEs=&FoRmAt=image%2Fpng&QuErY_LaYeRs=Bridges&VeRs
> IoN=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=B
> ridges&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&Ve
> RsIoN=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
> > 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
> 
> iEYEARECAAYFAlFakHQACgkQq1hDh4aJykJrOgCguXu4Xz3ilBCXFTQZrKLVoF/x
> AoIAoJ5yxZIr977VoAnwNiG0SqYqKnEF
> =+TKA
> -----END PGP SIGNATURE-----
> _______________________________________________
> CITE-Forum mailing list
> CITE-Forum at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/cite-forum
> 


More information about the CITE-Forum mailing list