[Geoserver-users] GeoServer/WFS range checking?

GeoServer GeoServer User
1

I am running GeoServer 1.7.0, using ArcSDE 9.3 as my back end.

Does GeoServer/WFS range check long/lat coordinates in a bounding box for
example? I would think if you gave a bogus long/lat coordinate like
-99999999... you would get back some sort of exception.

Here is a sample request.

<wfs:GetFeature
  service="WFS"
  version="1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
  xmlns:gml="http://www.opengis.net/gml&quot;
  xmlns:wfs="http://www.opengis.net/wfs&quot;
  xmlns:ogc="http://www.opengis.net/ogc&quot;
  xsi:schemaLocation="http://www.opengis.net/wfs
http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd&quot;&gt;

  outputFormat="GML2"
  <wfs:Query typeName="topp:MAPDATA.WVS001M_GAZETTE_GAZETTE">
    <wfs:PropertyName>COUNTRY_DESCRIPTION</wfs:PropertyName>
      <ogc:Filter>

      <ogc:BBOX>
        <ogc:PropertyName>SHAPE</ogc:PropertyName>
        <gml:Box>
          <gml:coordinates>-99999999999,27 -13,30</gml:coordinates>
        </gml:Box>
      </ogc:BBOX>

      </ogc:Filter>
  </wfs:Query>
</wfs:GetFeature>

I get valid data in my response, and if you look at the what the data is
bounded by, my request is clearly out of range.

<gml:boundedBy>
<gml:Box srsName="http://www.opengis.net/gml/srs/epsg.xml#4326&quot;&gt;
  <gml:coordinates xmlns:gml="http://www.opengis.net/gml&quot; decimal="." cs=","
ts="">-179.938,-73.3586 179.07381,81.4986</gml:coordinates>
  </gml:Box>
  </gml:boundedBy>

Any insight is appreciated.

Thanks,
Rett
--
View this message in context: http://www.nabble.com/GeoServer-WFS-range-checking--tp22164066p22164066.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

2

Rett wrote:

I am running GeoServer 1.7.0, using ArcSDE 9.3 as my back end.

Does GeoServer/WFS range check long/lat coordinates in a bounding box for
example? I would think if you gave a bogus long/lat coordinate like
-99999999... you would get back some sort of exception.

Here is a sample request.

<wfs:GetFeature
  service="WFS"
  version="1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
  xmlns:gml="http://www.opengis.net/gml&quot;
  xmlns:wfs="http://www.opengis.net/wfs&quot;
  xmlns:ogc="http://www.opengis.net/ogc&quot;
  xsi:schemaLocation="http://www.opengis.net/wfs
http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd&quot;&gt;

  outputFormat="GML2"
  <wfs:Query typeName="topp:MAPDATA.WVS001M_GAZETTE_GAZETTE">
    <wfs:PropertyName>COUNTRY_DESCRIPTION</wfs:PropertyName>
      <ogc:Filter>

      <ogc:BBOX>
        <ogc:PropertyName>SHAPE</ogc:PropertyName>
        <gml:Box>
          <gml:coordinates>-99999999999,27 -13,30</gml:coordinates>
        </gml:Box>
      </ogc:BBOX>

      </ogc:Filter>
  </wfs:Query>
</wfs:GetFeature>

I get valid data in my response, and if you look at the what the data is
bounded by, my request is clearly out of range.

<gml:boundedBy>
<gml:Box srsName="http://www.opengis.net/gml/srs/epsg.xml#4326&quot;&gt;
  <gml:coordinates xmlns:gml="http://www.opengis.net/gml&quot; decimal="." cs=","
ts="">-179.938,-73.3586 179.07381,81.4986</gml:coordinates> </gml:Box>
  </gml:boundedBy>

As far as I remember if you go to config/wfs/contents and enable "strict
cite compliance" you'll get a service exception when you are using wgs84
and go out of its bounds, but that won't work for any projection, just
for wgs84.
Anyways, there is a reason why that flag is not on by default, most clients will make the kind of request you just made (with less extreme
values) as people zoom out (think udig + wfs) and expect data back,
if we enable that by default, we'd break them all.
So make sure that this is really what you want.

Cheers
Andrea

3

That was my understanding as well. The SRS for my data is WGS84.

srsName="http://www.opengis.net/gml/srs/epsg.xml#4326

EPSG: 4326 = WGS84

If you enter long/lat coordinates out of range for WGS84 (-180, -90, 180,
90) you should get an exception.

I have enabled "strict cite compliance" with the same result. Either way, I
am allowed to enter long lat coordinates way out of range without an
exception. It seems to return data that is within a ballooned theoretical
bounding box with coordinates (-99999999, xx, xx, xx).

Maybe the strict cite compliance does not range check against your SRS? And
it only tests compliance of your OGC request in general?

Andrea Aime-4 wrote:

Rett wrote:

I am running GeoServer 1.7.0, using ArcSDE 9.3 as my back end.

Does GeoServer/WFS range check long/lat coordinates in a bounding box for
example? I would think if you gave a bogus long/lat coordinate like
-99999999... you would get back some sort of exception.

Here is a sample request.

<wfs:GetFeature
  service="WFS"
  version="1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
  xmlns:gml="http://www.opengis.net/gml&quot;
  xmlns:wfs="http://www.opengis.net/wfs&quot;
  xmlns:ogc="http://www.opengis.net/ogc&quot;
  xsi:schemaLocation="http://www.opengis.net/wfs
http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd&quot;&gt;

  outputFormat="GML2"
  <wfs:Query typeName="topp:MAPDATA.WVS001M_GAZETTE_GAZETTE">
    <wfs:PropertyName>COUNTRY_DESCRIPTION</wfs:PropertyName>
      <ogc:Filter>

      <ogc:BBOX>
        <ogc:PropertyName>SHAPE</ogc:PropertyName>
        <gml:Box>
          <gml:coordinates>-99999999999,27 -13,30</gml:coordinates>
        </gml:Box>
      </ogc:BBOX>

      </ogc:Filter>
  </wfs:Query>
</wfs:GetFeature>

I get valid data in my response, and if you look at the what the data is
bounded by, my request is clearly out of range.

<gml:boundedBy>
<gml:Box srsName="http://www.opengis.net/gml/srs/epsg.xml#4326&quot;&gt;
  <gml:coordinates xmlns:gml="http://www.opengis.net/gml&quot; decimal="."
cs=","
ts="">-179.938,-73.3586 179.07381,81.4986</gml:coordinates>
  </gml:Box>
  </gml:boundedBy>

As far as I remember if you go to config/wfs/contents and enable "strict
cite compliance" you'll get a service exception when you are using wgs84
and go out of its bounds, but that won't work for any projection, just
for wgs84.
Anyways, there is a reason why that flag is not on by default, most
clients will make the kind of request you just made (with less extreme
values) as people zoom out (think udig + wfs) and expect data back,
if we enable that by default, we'd break them all.
So make sure that this is really what you want.

Cheers
Andrea

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
CA
-OSBC tackles the biggest issue in open source: Open Sourcing the
Enterprise
-Strategies to boost innovation and cut costs with open source
participation
-Receive a $600 discount off the registration fee with the source code:
SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://www.nabble.com/GeoServer-WFS-range-checking--tp22164066p22181078.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

4

Rett wrote:

That was my understanding as well. The SRS for my data is WGS84.

srsName="http://www.opengis.net/gml/srs/epsg.xml#4326

EPSG: 4326 = WGS84

If you enter long/lat coordinates out of range for WGS84 (-180, -90, 180,
90) you should get an exception.

Yeah, thought as I said before, it's unrealistic behavior for
practical purposes, works only if you have complete control of
your clients and make sure they will never make a "wrong" request.

I have enabled "strict cite compliance" with the same result. Either way, I
am allowed to enter long lat coordinates way out of range without an
exception. It seems to return data that is within a ballooned theoretical
bounding box with coordinates (-99999999, xx, xx, xx).

Maybe the strict cite compliance does not range check against your SRS? And
it only tests compliance of your OGC request in general?

Nah, checked the code and the control is there, but triggers in only in
specific cases. We can expand the control, thought I'm very hesitant
to work on this, cause as I said, it's unrealistic given the clients
that are out there.

Can you open a "improvement" request on jira.codehaus.org for this?
Also, if you're comfortable coding, a patch would be welcomed.
The current check is in the GetFeature class, in the wfs module,
you'd just have to extend its applicability. On our part, we'd review
and patch and check GeoServer still passes the CITE compliance tests.

Cheers
Andrea

5

Andrea Aime-4 wrote:

Nah, checked the code and the control is there, but triggers in only in
specific cases.

I have discovered some new information regarding this issue.

I saw the specific cases in the code where range checking will occur. I've
traced it through many of the if statements. But it seems to never get to
the "visit" part in the code.

According to java docs, the accept method calls the visit method.
I put a print out before and after the accept call.

LOGGER.severe("BEFORE - accept(fvisitor, null)");
query.getFilter().accept(fvisitor, null);
LOGGER.severe("AFTER - accept(fvisitor, null)");

And I added a print out in the visit method and also a System.exit to ensure
if I got to that point, I would know.

public Object visit(BBOX filter, Object data) {

LOGGER.severe("In VISIT METHOD - Now Exiting");
System.exit(0);

I get the printouts before and after the accept call, but no printouts from
the visit method, nor the System.exit being performed.

As a simple test I tried to invoke the visit method manually with this
snippet.

BBOX temp = null;
fvisitor.visit(temp,null);

After doing so I see the LOGGER.severe("In VISIT METHOD - Now Exiting");
printout, and then the System.exit is performed.

With this data it looks like GetFeature.java does not call the visit method
defined here and is not performing any range checking at all.

Any help is appreciated.

Thanks,
Rett
--
View this message in context: http://www.nabble.com/GeoServer-WFS-range-checking--tp22164066p23141356.html
Sent from the GeoServer - User mailing list archive at Nabble.com.