New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC 118 & Geotransform #5744
Comments
Same result with GEOMTRANSFORM "vertices". |
I think it's a bug, likely in the query map code. What happens if you add:
to your mapfile? |
Same result. |
Then it's a problem in the msDrawQuery() function in mapdraw.c not properly handling GEOMTRANSFORMs... nuts. Dan alluded to other issues in the limitations section of the RFC and I guess this is another one. I'm curious if POLYGONs behave the same. The function in question uses msDrawShape() for polygons but calls lower-level functions for lines. |
That's what I was hoping would happen - it's a good hint.. The question is if msDrawShape() can also be used for line features in msDrawQuery(). |
I can't answer to this question :) |
@pelord, what does your vertline symbol definition look like? |
|
@geographika Do you think this could be related to your issue? http://osgeo-org.1560.x6.nabble.com/Combining-WMS-Filter-and-Style-Parameters-td5411882.html |
@pelord - yes it looks like it is the same issue, although I'm not using The example uses test_wms_filter.map.txt (remove the A basic WMS request with the
Works fine: A basic WMS request with the
The failing case is below -
|
Let me know if I could help! |
I've done some debugging, and I think I know why this is happening, but not much idea how to fix it. I believe it is the same issue as referenced in the RFC:
I believe this is a similar case for A layer with a filter uses There is a comment in
|
A minor update, I tried setting In a much more complex system with a MSSQL based layer it does seem to resolve my issue, and display filtered features with the correct style. Not sure if that provides anything useful. |
Can you guys give the pull request a test? There are likely still issues with HILITE querymap styles and knowing which defined style to change colors on in certain cases. However, this should address cases where a style sets an outline width and/or uses GEOMTRANSFORM at the style level. |
Sorry, I do not have the experience/environnement for compiling Mapserver and test it. I'll try soon to do it but it might be extremely time consuming for me. |
@sdlime - I've compiled the code from the issue-5744 branch (just for info this is about 6 months of commits behind master). Unfortunately I still have the same issue where applying a filter reverts to using the first style - the third test here. |
Anyway to create a succinct version of the 3rd test? |
@sdlime - I can add as an msautotest to your branch? |
No, that's ok, I now see the mapfile and sample calls above and can work with that. I don't think this is the same issue. @pelord's problems were specific to lines and the msDrawQueryLayer() code was clearly not following the same approach as msDrawVectorLayer() in terms of dealing with outlinewidth, GEOMTRANFORMed styles, etc... That's what the pull request fixes. Your issue is with point layers which would have been drawn correctly as the code sits now. The msDrawQueryLayer() code doesn't assign a class index to a selected feature. That's done upstream in the query code (since that's where template references could possibly live). The drawing code just leverages the set class index and then tweaks colors if necessary (TYPE HILITE). Seems to me like the class index isn't being set properly elsewhere. That will be easy to verify. I know the main query functions respect the CLASSGROUP but I don't know what the WMS code is doing. |
I can confirm that the class index in the 3rd case is reported as 0, so CLASSGROUP "green". The problem is elsewhere in the query code I think. I can further confirm that when msQueryByFilter() is called, layer INLINE has class group set to "green", so the default value but when msDrawQueryLayer() is called, layer INLINE has class group set to "red". The problem is in the WMS code, it's setting class group after the filtering is done and not before. |
@dmorissette, you're way more familiar with the WMS code than I am - only the previous comment is really relevant. Does the issue of setting a layers class group after doing a query seem like something that could be happening? I think changing where the query is executed in msWMSLoadGetMapParams() would do it - or moving the query into msWMSGetMap(),,, |
This has been fixed in both master and branch-7-4. Closing... --Steve |
I am currently testing version 7.6.2 and I confirm that this problem is fixed. Sorry for the delay! |
Thanks @pelord! |
Here my class for a linestring stored in postgis as a multilinestring.
If I don't apply a wms filter, everything is rendered (getmap) as in the class's definition.
If a apply a filter (rfc 118):
<Filter xmlns="http://www.opengis.net/ogc"><PropertyIsEqualTo matchCase="true"><PropertyName>state</PropertyName><Literal>bad</Literal></PropertyIsEqualTo>
Here the result.
A query on wms with geotransform end/start seem to render a densified version of the linestring.
Here the vertices of this line:
I've tried to convert the multilinestring to a linestring as done on gis.stackexchange with the same result.
Is it an issue or a bad mapfile definition?
MapServer version 7.2.1
The text was updated successfully, but these errors were encountered: