I’m currently implementing a clustering solution using the PointStacker Rendering Transformation. It works great, but I can’t figure out how to do a GetFeatureInfo on the clustered points so that I can get a list of the individual features that the point consists of.
Is it possible to do this? If not could some perhaps suggest an alternative method of implementing the clustering of points from a postgis database and clustering points close to each other dependent on zoom level like what the PointStacker does.
You’re correct, inability to provide access to the underlying points is a limitation of the current PointStacker implementation. I’m not sure whether it’s possible to solve this within GeoServer using GetFeatureInfo. So database-side clustering might be a better option.
I’m currently implementing a clustering solution using the PointStacker Rendering Transformation. It works great, but I can’t figure out how to do a GetFeatureInfo on the clustered points so that I can get a list of the individual features that the point consists of.
Is it possible to do this? If not could some perhaps suggest an alternative method of implementing the clustering of points from a postgis database and clustering points close to each other dependent on zoom level like what the PointStacker does.
Any input would be much appreciated,
Many Thanks,
Mark
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
Thanks for your response Martin. I’ll have a look into clustering on the database-side, I don’t suppose you / any one else is aware of any particularly good solutions for doing this? I would really like to find a solutions that can take into account the zoom level when doing the clustering.
You’re correct, inability to provide access to the underlying points is a limitation of the current PointStacker implementation. I’m not sure whether it’s possible to solve this within GeoServer using GetFeatureInfo. So database-side clustering might be a better option.
I’m currently implementing a clustering solution using the PointStacker Rendering Transformation. It works great, but I can’t figure out how to do a GetFeatureInfo on the clustered points so that I can get a list of the individual features that the point consists of.
Is it possible to do this? If not could some perhaps suggest an alternative method of implementing the clustering of points from a postgis database and clustering points close to each other dependent on zoom level like what the PointStacker does.
Any input would be much appreciated,
Many Thanks,
Mark
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On Wed, Mar 20, 2013 at 7:59 PM, Martin Davis <mtnclimb@anonymised.com> wrote:
You're correct, inability to provide access to the underlying points is a
limitation of the current PointStacker implementation. I'm not sure whether
it's possible to solve this within GeoServer using GetFeatureInfo. So
database-side clustering might be a better option.
Just for the sake of the conversation, a couple of observations:
- GetFeatureInfo is not aware of rendering transformations at the
moment, as such it is
returning the original data instead
- even assuming GFI applies the rendering transformation and returns
the result of
the transformation, the results would still be a summary, not a list
of the points that
were used to form the output point no?
Some change would be needed, say for example adding a string field
that contains
a comma separate list of the feature ids of the features that formed the point
(and then the client would have to parse it and make a separate WFS GetFeature
request to retrieve the original features with all the attributes)
I’ve been involved with projects that have done DB-side clustering (both in PG and in SQLServer), but I don’t have any code or docs about it. A Google search should turn up something. If I get some time I’ll try and write down a sketch of how it can work.
It’s pretty easy to snap point features into a grid and show a point at the centre of the grid. Showing a nice-looking point is a bit trickier, and obtaining the actual features in a cluster requires another piece of trickery.
Thanks for your response Martin. I’ll have a look into clustering on the database-side, I don’t suppose you / any one else is aware of any particularly good solutions for doing this? I would really like to find a solutions that can take into account the zoom level when doing the clustering.
You’re correct, inability to provide access to the underlying points is a limitation of the current PointStacker implementation. I’m not sure whether it’s possible to solve this within GeoServer using GetFeatureInfo. So database-side clustering might be a better option.
I’m currently implementing a clustering solution using the PointStacker Rendering Transformation. It works great, but I can’t figure out how to do a GetFeatureInfo on the clustered points so that I can get a list of the individual features that the point consists of.
Is it possible to do this? If not could some perhaps suggest an alternative method of implementing the clustering of points from a postgis database and clustering points close to each other dependent on zoom level like what the PointStacker does.
Any input would be much appreciated,
Many Thanks,
Mark
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
If GFI did access the RT output, I was thinking that it would be possible to add a mode to the PointStacker RT where it returned all the original features, but with a point coordinate set to the location of the computed cluster point. Then this mode could be enabled in the GFI call, thus retrieving all the original features. But with the current disconnect between GFI and RT, this won’t work.
If it’s possible to use a WPS call instead of GFI, then the above enhancement could be made to work. (Or if only it was possible to back a layer by a WPS process… which I believe is being talked about?)
The capability is tantalizingly close - so this seems like a good use case to motivate improvements in GS functionality.
You’re correct, inability to provide access to the underlying points is a
limitation of the current PointStacker implementation. I’m not sure whether
it’s possible to solve this within GeoServer using GetFeatureInfo. So
database-side clustering might be a better option.
Just for the sake of the conversation, a couple of observations:
GetFeatureInfo is not aware of rendering transformations at the
moment, as such it is
returning the original data instead
even assuming GFI applies the rendering transformation and returns
the result of
the transformation, the results would still be a summary, not a list
of the points that
were used to form the output point no?
Some change would be needed, say for example adding a string field
that contains
a comma separate list of the feature ids of the features that formed the point
(and then the client would have to parse it and make a separate WFS GetFeature
request to retrieve the original features with all the attributes)
On Thu, Mar 21, 2013 at 7:18 PM, Martin Davis <mtnclimb@anonymised.com> wrote:
Agreed - all good points.
If GFI did access the RT output, I was thinking that it would be possible to
add a mode to the PointStacker RT where it returned all the original
features, but with a point coordinate set to the location of the computed
cluster point. Then this mode could be enabled in the GFI call, thus
retrieving all the original features. But with the current disconnect
between GFI and RT, this won't work.
You'd get a MultiPoint, but with just the coordinates, you would not have
their attributes. That's why I was suggesting to get a list of feature
ids instead.
A more compact solution would be to issue a polygon with the convex hull
of all the points used in the cluster, which could also be used in GetFeature
to retrieve all the features and their attributes
If GFI did access the RT output, I was thinking that it would be possible to
add a mode to the PointStacker RT where it returned all the original
features, but with a point coordinate set to the location of the computed
cluster point. Then this mode could be enabled in the GFI call, thus
retrieving all the original features. But with the current disconnect
between GFI and RT, this won’t work.
You’d get a MultiPoint, but with just the coordinates, you would not have
their attributes. That’s why I was suggesting to get a list of feature
ids instead.
I meant that the new mode would compute a cluster point for groups of features, but then return each original feature but having as geometry the computed cluster point. So the GFI spatial filter would select all the features in the cluster, and would get back full attribution for each one of them. (PointStacker reads all the features in the map window before outputting them, so it can choose to output any mixture of attributes and spatial required).
A more compact solution would be to issue a polygon with the convex hull
of all the points used in the cluster, which could also be used in GetFeature
to retrieve all the features and their attributes
Interesting idea. The clustering is based on a square grid, so it could just return the grid cell outline. But what query would retrieve this polygon? The RT output is only available to the renderer, right? So doesn’t this mean that WPS would have to be used to call the PointStacker process directly?
But I just remembered a tricky issue about calling PointStacker via WPS: the grid resolution is determined from the map window dimensions. These are available inside the rendering pipeline, but won’t be in a WPS call. Probably not impossible to detemine them on the client side, but that stars to get a bit ugly. So that brings us back to the idea that it would be nice to be able to run a GFI against the RT output.
On Thu, Mar 21, 2013 at 7:31 PM, Martin Davis <mtnclimb@anonymised.com> wrote:
I meant that the new mode would compute a cluster point for groups of
features, but then return *each original feature* but having as geometry the
computed cluster point. So the GFI spatial filter would select all the
features in the cluster, and would get back full attribution for each one of
them. (PointStacker reads all the features in the map window before
outputting them, so it can choose to output any mixture of attributes and
spatial required).
Ah, I see. Yeah, makes sense.
A more compact solution would be to issue a polygon with the convex hull
of all the points used in the cluster, which could also be used in
GetFeature
to retrieve all the features and their attributes
Interesting idea. The clustering is based on a square grid, so it could
just return the grid cell outline. But what query would retrieve this
polygon? The RT output is only available to the renderer, right? So
doesn't this mean that WPS would have to be used to call the PointStacker
process directly?
Hum, no, you just have to do GFI in GML or JSON format, and you get
full attributes,
including the geometry.
Interesting idea. The clustering is based on a square grid, so it could
just return the grid cell outline. But what query would retrieve this
polygon? The RT output is only available to the renderer, right? So
doesn’t this mean that WPS would have to be used to call the PointStacker
process directly?
Hum, no, you just have to do GFI in GML or JSON format, and you get
full attributes,
including the geometry.
Not sure I see how the output format fixes the problems of (a) GFI not calling the RT and (b) the PointStacker RT needing the WMS info about the map size ?
On Thu, Mar 21, 2013 at 7:47 PM, Martin Davis <mtnclimb@anonymised.com> wrote:
Hum, no, you just have to do GFI in GML or JSON format, and you get
full attributes,
including the geometry.
Not sure I see how the output format fixes the problems of (a) GFI not
calling the RT and (b) the PointStacker RT needing the WMS info about the
map size ?
Ah ok, I thought you meant that the polygon was not available as a result of
the GFI output.
About a), the whole discussion is based on the hp that someone implements
RT in GetFeatureInfo (the whole thread is purely hypothetical)
About b), if someone does a) we can also inject the same WMS calls params
in the GetFeatureInfo call, with a variant though: the GetFeatureInfo uses
a small box (3x3 pixels by default, can be enlarged using the buffer param)
so those params would have to be adapted as a consequence, and
the RT would have to be written so that it grows its operating context enough
to work properly (just like some, but not all, RT do).
Hum, no, you just have to do GFI in GML or JSON format, and you get
full attributes,
including the geometry.
Not sure I see how the output format fixes the problems of (a) GFI not
calling the RT and (b) the PointStacker RT needing the WMS info about the
map size ?
Ah ok, I thought you meant that the polygon was not available as a result of
the GFI output.
About a), the whole discussion is based on the hp that someone implements
RT in GetFeatureInfo (the whole thread is purely hypothetical)
Yes, understood. I thought it was interesting to explore what new capabilities this might offer (or at least in this case some nice (essential?) enhancements to an existing function).
About b), if someone does a) we can also inject the same WMS calls params
in the GetFeatureInfo call, with a variant though: the GetFeatureInfo uses
a small box (3x3 pixels by default, can be enlarged using the buffer param)
so those params would have to be adapted as a consequence, and
the RT would have to be written so that it grows its operating context enough
to work properly (just like some, but not all, RT do).
Great. And yes, understood that the RT would have to be smart about how it made use of the information available. (It took me a while to wrap my head around this for the RTs I did last year - so I’m well aware that it’s non-trivial! The nice thing is that once it’s done it’s totally transparent to the user - which is usually a solid indicator of a good design).
I was looking for exactly the same thing. I am using OpenLayers with
WMSGetFeatureInfo.
All I did to get it working was assign an additional basic point style to
the layer in Geoserver, and when running the WMSGetFeatureInfo I just pass
across that style instead of the cluster style.
That’s a good pragmatic solution. I would expect that the GetFeatureInfo result would not always have the same number of features which are displayed in the cluster point, however. But for many purposes this may not matter.
I was looking for exactly the same thing. I am using OpenLayers with
WMSGetFeatureInfo.
All I did to get it working was assign an additional basic point style to
the layer in Geoserver, and when running the WMSGetFeatureInfo I just pass
across that style instead of the cluster style.