-
-
Notifications
You must be signed in to change notification settings - Fork 375
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
Centerline GEOMTRANSFORM Support #6417
Conversation
This reverts commit 7d261af.
I am missing mapgraph.c and mapgraph.h when I tried to build. |
…an up to the centerline function.
The repeated labels next. Not drawing the first label at the bottom of a bay is a good idea, but what if the requested image bbox cuts the lake at the middle? How could you define that the first label on the centerline would be OK then? |
Agree'd on the C++ification. Does "add suggestion to batch" essentially build a single pull request? I've not noticed that option before. |
a single commit added at the end of that PR. That's the preferred solution to avoid stressing too much the CI |
Co-authored-by: Even Rouault <even.rouault@spatialys.com>
…lly allocated shape obj.
Any objections to merging? I think it's in pretty good shape... --Steve |
Working great here. +1 |
It a fantastic new feature! I just love it. To bad that the chaining (smoothsia(centerline([shape]))) doesn't work. It worked up until 8 days ago. It is strange since other chaining like (simplifypt(centerline([shape]... is working. I have even tried to look at the source code, but that parsing is a little too complicated for me. |
@LarsSchy, true, smoothsia no longer works for me either (alone, not even chained). |
That's so weird and I experience the same thing. I imagine it's very fixable given a little time. |
Good news is everything compiles fine and an image is generated. If I add a label to the the following layer definition then I can get an image back:
However if I change to the following:
Then I always get back the following error no matter what parameter I set for
Am I configuring the layer incorrectly? |
Configuration looks ok at first glance. That error message occurs when there are no edges added to the directed graph computed from the Voronoi diagram. I've only seen that happen in cases with super simple geometries like a square or triangle with vertices only at the corners. The algorithm removes Densifying solves that problem. What do you get if you just do?
Any chance you could share your test case? --Steve |
…ype on the new shape. It should preserve the input shape type.
@sdlime - same error with that change (plus an additional parsing error which seems to be thrown after the first error):
I used the following data for the test case: http://naciscdn.org/naturalearth/packages/natural_earth_vector.gpkg.zip Command:
Map file:
|
My experiments are working fine now with: (smoothsia(centerline([shape]))) ! I looked at the natural earth data from Seth. When I looked at the clipped data in QGIS, I can see several very small triangles. Some are in the data set from the beginning and some are due to the clipping. ogr2ogr natural_earth_vector_lakes10m_clip.gpkg -clipsrc -68.7202 53.075 -67.7202 54.075 natural_earth_vector.gpkg ne_10m_lakes |
Thanks @LarsSchy for the investigations. That corresponds with Steve's comment about simple features. Maybe these errors should be logged and ignored so that centerlines can still be generated for other features in the layer? |
The problem with that natural earth data is the super small polygons, there's one in that viewport that has an area of .000001 the error message @geographika was seeing was related to that geometry. The error message is relevant, a solution is to densify, but you have to use such a small value that it becomes counter productive. I needed a value of .001 in the densify function to get things to complete. A better solution will be to filter out those small geometries ahead of time, so for example if I do:
to the lakes_label layer then things work fine. Making sure that only shapes that are candidates for labeling are going to be processed is probably going to be a common step - it also is more performant. So I don't see a blocker here. There may be some opportunities for some optimization with simple geometries - perhaps an alternative way to generate a centerline without going through a Voronoi diagram-based process. --Steve |
I think that's going to be difficult based on the way the parser works since there may be downstream processing (e.g. SmoothSIA) so there's no way to bail mid-expression evaluation with a "never mind" response. I don't know if that's possible or not. |
Thanks Steve for the explanation. I guess I chose the wrong dataset to test with! Is it correct that the new keywords from this feature to add to https://mapserver.org/mapfile/geomtransform.html are |
If you didn't hit a case like that then someone else would have! I think there will be further enhancements necessary in this area as the feature gets used.
Yup, those are the new GEOMTRANSFORM functions. The first 3 are probably relevant for drawing labels and would typically be applied at the LAYER level because of the way the path following labels work. Outer and inner may also be useful at the STYLE level for rendering effects. |
Rework of the original #5854 pull request. Cleaned up a few pieces of the implementation and renamed skeletonize to centerline - it's a much more accurate name.