I have some questions about the GetFeatureInfo request. This works well with Polygon geometry but not on LineString or Point one.
In the org.vfny.geoserver.responses.wms.featureInfo.AbstractFeatureInfoResponse class, at lines 207 to 221, we use a GEOMETRY_WITHIN filter. After converting a screen coordinate to a real coordinate, it is pretty impossible to have an exact coordinate, which is within (or intersects ? Don't know the behavior of "within" filter for points and linestrings) a feature geometry of point or linestring type.
By using a GEOMETRY_WITHIN filter, we could solve this issue. The distance parameter would be equal to an offset of 1 pixel transformed in a real map distance.
Charles
Do you mean GEOMETRY_DWITHIN for the one to fix it? I think a transform
of 1 pixel would be a sensible way to solve the issue.
Chris
On Tue, 12 Oct 2004, Charles Kolbowicz wrote:
I have some questions about the GetFeatureInfo request. This works well
with Polygon geometry but not on LineString or Point one.
In the
org.vfny.geoserver.responses.wms.featureInfo.AbstractFeatureInfoResponse
class, at lines 207 to 221, we use a GEOMETRY_WITHIN filter. After
converting a screen coordinate to a real coordinate, it is pretty
impossible to have an exact coordinate, which is within (or intersects ?
Don't know the behavior of "within" filter for points and linestrings) a
feature geometry of point or linestring type.
By using a GEOMETRY_WITHIN filter, we could solve this issue. The
distance parameter would be equal to an offset of 1 pixel transformed in
a real map distance.
Charles
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Do you mean GEOMETRY_DWITHIN for the one to fix it?
Yes, that's it...
I think a transform of 1 pixel would be a sensible way to solve the issue.
After use, 3 pixels is better. It seems to be a good solution temporarily, considering default size for point symbolizer is 6 px (SLD specification). And it offers an easier selection. For testing, I have modified the org.vfny.geoserver.responses.wms.featureInfo.AbstractFeatureInfoResponse class from lines 28, 209 and 219 (see attachment).
However in many cases, this solution reaches its limits. In particular with wider point symbolizers or stroke parameters, a user could only click in a 6 pixels wide area, not further. The GetFeatureInfo request does not yet take care of symbolizer size for retrieving selected features.
Charles
(attachments)
AbstractFeatureInfoResponse.java (9.88 KB)
>I think a transform
>of 1 pixel would be a sensible way to solve the issue.
>
>
After use, 3 pixels is better. It seems to be a good solution
temporarily, considering default size for point symbolizer is 6 px (SLD
specification). And it offers an easier selection. For testing, I have
modified the
org.vfny.geoserver.responses.wms.featureInfo.AbstractFeatureInfoResponse
class from lines 28, 209 and 219 (see attachment).
However in many cases, this solution reaches its limits. In particular
with wider point symbolizers or stroke parameters, a user could only
click in a 6 pixels wide area, not further. The GetFeatureInfo request
does not yet take care of symbolizer size for retrieving selected features.
Paul suspected that 1 pixel would probably not work so well. He had a
good suggestion, that might be a bit helpful, is to make the number of
pixels user configurable as one of the WMS options. Knowing the
symbolizer size is obviously a much more elegant solution, especially as
it could be done per layer and per symbolizer, while the user config pixel
size would be global. But it would allow users to make it as big or small
as they want as needed. This config option would go right next to the
anti-aliasing option, so if you want to throw it in right next to it that
could be a good thing.
Chris
Hi all,
It seems that the WMS GetFeatureInfo request does not close correctly the connection to a PostGIS datastore after its response. After a while, PostGIS does not accept any connection and the server is down.
However the WMS GetMap request seems to close all correctly after each response.
Has someone got an idea ? Thanks in advance
Charles
This most likely has to do with the PostGis FeatureReader not have
close() called at the end of the request's response. Just check to
ensure that after the iteration of features is completed
FeatureReader.close() is called.
David
On Mon, 2004-10-18 at 14:44, Charles Kolbowicz wrote:
Hi all,
It seems that the WMS GetFeatureInfo request does not close correctly
the connection to a PostGIS datastore after its response. After a while,
PostGIS does not accept any connection and the server is down.
However the WMS GetMap request seems to close all correctly after each
response.
Has someone got an idea ? Thanks in advance
Charles
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Thanks for your help, it was exactly that. I have modified two classes by adding reader.close() :
* org.vfny.geoserver.responses.wms.featureinfo.HTMLTableFeatureInfoResponse, add at line 143 ;
* org.vfny.geoserver.responses.wms.featureinfo.TextFeatureInfoResponse, add at line 129.
Otherwise I have sometimes seen that variables are declared inside loops. It can be bad in memory use, especially for FeatureXXX types.
Regards
Charles
David Zwiers a écrit :
This most likely has to do with the PostGis FeatureReader not have
close() called at the end of the request's response. Just check to
ensure that after the iteration of features is completed
FeatureReader.close() is called.
David
On Mon, 2004-10-18 at 14:44, Charles Kolbowicz wrote:
Hi all,
It seems that the WMS GetFeatureInfo request does not close correctly the connection to a PostGIS datastore after its response. After a while, PostGIS does not accept any connection and the server is down.
However the WMS GetMap request seems to close all correctly after each response.
Has someone got an idea ? Thanks in advance
Charles
(attachments)
TextFeatureInfoResponse.java (5.45 KB)
HTMLTableFeatureInfoResponse.java (6.24 KB)