[Geoserver-users] SLD

GeoServer GeoServer User
21

That would be ideal except that WFS is not the solution for large datasets. One of my datasets has over 200,000,000 rows and while I can draw it with a WMS by restricting the scale it is drawn at it just doesn't work with WFS due to it's size.

Plus a lot of WMS systems are used by javascript based mapping systems where WFS is usually not an option, plus there is the issue of not wanting to give people access to your dataset by bandwidth killing WFS.

--
Ross Elliott
Senior Software Engineer
Infoterra Ltd
T +44 (0)1252 362095
www.infoterra.co.uk

-----Original Message-----
From: geoserver-users-bounces@lists.sourceforge.net [mailto:geoserver-users-bounces@lists.sourceforge.net] On Behalf Of Chris Holmes
Sent: 30 January 2007 23:41
To: Gabriel Roldán
Cc: Brent Owens; geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] SLD

And the general course of action we recommend is that clients use GetFeature from the WFS, instead of GetFeatureInfo from the WMS. They accomplish basically the same thing, but GetFeature gives you much more control, instead of just a pixel location and some weird assumptions about how big the buffer is.

Chris

Gabriel Roldán wrote:

On a different note is anyone looking into getFeatureInfo for points
and lines, currently (I suspect) you have to get an excact point on a
line or point to get it to work. The UMN Mapserver guys fixed this by
adding a buffer to the passed in point so you can click near a
feature and still hit it.

This is a tough one.
What geoserver does (or used to do, long time not seeing the code) is
to use the bounding box of the pixel at the point (or maybe two pixels
around), in the layer's CRS, to make a bbox filter.

But the problem gets worst. It's supposed to work quite well if you
render each point as a tiny symbol (square, triangle, circle, etc.).
In this case the user has to affine his shooting. GetFeatureInfo is like playing darts.
Problem is that with different marker sizes and shapes, it is logical
if the user expects a proper response if he pointed over the symbol,
but the symbol has nothing to do with the actual geometry (sigh!)

Even worse, I had an experience where points were represented as
triangles, and your only chance of catching up on a GetFeatureInfo
were pointing at the center pixel of the lower side of the
triangle.... no way pointing at the center, which would be more
friendly... (though don't remember right now if the spec says
something related to how the marker should be positioned regarding the
point location)

So that's why I say its a tough problem.

So the question is, would it be enough of a solution if we just
increase the "pixel tolerance" around the requested point to create
the BBOX (actually
intersects?) filter?

Gabriel

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

The information in this e-mail and any attachment is confidential and may be privileged. If you have received this e-mail in error, please delete it immediately and destroy any copies on your system. You should not retain, copy or use this e-mail for any purpose, nor disclose all or any part of its content to any other person. Opinions expressed in this e-mail may not be endorsed by the company and unless explicitly indicated, this e-mail shall not form part of any binding agreement. Infoterra Limited a company registered in England under number 2359955 and having its registered office at Atlas House, 41 Wembley Road, Leicester, LE31UT. VAT number GB 476 0468 27

22

No, I think you misunderstand me.

You should definitely use WMS to display the data. I'm just saying instead of a GetFeatureInfo call you use a GetFeature call. You define the bounding box to be the are you're querying. Which should be small, about the size of the WMS GetFeatureInfo. But since the client knows the scale its at and the geographic coordinates, it can send a more accurate bounding box. The WFS can return GML, just like the WMS does. I actually have an issue open to allow them to use the exact same output formats, so we can have WFS GetFeature return the same sort of HTML response.

So yeah, it's a combination of WMS and WFS. Which is easy with GeoServer since all layers have both turned on by default. You just use the WFS GetFeature when you want info for the features, you don't actually render them. I suppose the one issue is if you have scale defined and you're zoomed way out - but I don't know how many WMS's are advanced enough to return only the info for the scale you're at.

MapBuilder I believe is now doing querying with GetFeature. And I don't think openlayers yet has querying capabilities, but they do have other WFS support so it wouldn't be too hard to do.

best regards,

Chris

Ross Elliott wrote:

That would be ideal except that WFS is not the solution for large datasets. One of my datasets has over 200,000,000 rows and while I can draw it with a WMS by restricting the scale it is drawn at it just doesn't work with WFS due to it's size.

Plus a lot of WMS systems are used by javascript based mapping systems where WFS is usually not an option, plus there is the issue of not wanting to give people access to your dataset by bandwidth killing WFS.

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

23

OK, that makes sense, just need to persuade the commercial clients to do it this way.

--
Ross Elliott
Senior Software Engineer
Infoterra Ltd
T +44 (0)1252 362095
www.infoterra.co.uk

-----Original Message-----
From: Chris Holmes [mailto:cholmes@anonymised.com]
Sent: 31 January 2007 14:34
To: Ross Elliott
Cc: Gabriel Roldán; Brent Owens; geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] SLD

No, I think you misunderstand me.

You should definitely use WMS to display the data. I'm just saying instead of a GetFeatureInfo call you use a GetFeature call. You define the bounding box to be the are you're querying. Which should be small, about the size of the WMS GetFeatureInfo. But since the client knows the scale its at and the geographic coordinates, it can send a more accurate bounding box. The WFS can return GML, just like the WMS does.
  I actually have an issue open to allow them to use the exact same output formats, so we can have WFS GetFeature return the same sort of HTML response.

So yeah, it's a combination of WMS and WFS. Which is easy with GeoServer since all layers have both turned on by default. You just use the WFS GetFeature when you want info for the features, you don't actually render them. I suppose the one issue is if you have scale defined and you're zoomed way out - but I don't know how many WMS's are advanced enough to return only the info for the scale you're at.

MapBuilder I believe is now doing querying with GetFeature. And I don't think openlayers yet has querying capabilities, but they do have other WFS support so it wouldn't be too hard to do.

best regards,

Chris

Ross Elliott wrote:

That would be ideal except that WFS is not the solution for large datasets. One of my datasets has over 200,000,000 rows and while I can draw it with a WMS by restricting the scale it is drawn at it just doesn't work with WFS due to it's size.

Plus a lot of WMS systems are used by javascript based mapping systems where WFS is usually not an option, plus there is the issue of not wanting to give people access to your dataset by bandwidth killing WFS.

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

The information in this e-mail and any attachment is confidential and may be privileged. If you have received this e-mail in error, please delete it immediately and destroy any copies on your system. You should not retain, copy or use this e-mail for any purpose, nor disclose all or any part of its content to any other person. Opinions expressed in this e-mail may not be endorsed by the company and unless explicitly indicated, this e-mail shall not form part of any binding agreement. Infoterra Limited a company registered in England under number 2359955 and having its registered office at Atlas House, 41 Wembley Road, Leicester, LE31UT. VAT number GB 476 0468 27

24

The WMS path option is just for the get capabilities request; it will format your layers in a tree hierarchy based on the wms path. It won't actually effect what layers are rendered in a map. I will add this to the FAQ.

The layer grouping, at least through the web UI, only allows for one group. But the rest of the code allows for as many groups as you want. We just haven't changed the UI to allow for many groups, not until we change what technology we use.

Brent Owens
(The Open Planning Project)

Ross Elliott wrote:

You understand exactly what I want it to do. I did look at both of these
options before but they don't quite deliver what a WMS client or user
would expect, whilst a user would like a nested layer tree returned they
would also expect (as would the WMS client) to be able to select a
parent layer and display all the child layers and Geoserver doesn't
quite do this yet from what I can see (especially as under 1.4 the WMS
path stuff seems to be broken) and from what I understand the layer
grouping looks like you can only have one layer group. It's not a big
deal and I'm sure things will change over time.