I'm trying to count the vertices on line segments. The data is a .GDB and has complex line segments that contain fillets and arcs. The VertexCounter is calculating an incorrect number of vertices for line segments that contain arcs. Is there a work-around for these more complex line segments?
Question
VertexCounter transformer giving incorrect vertex count on line segments containing arcs.
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
I agree about sample data being useful. Also, how many vertices should, in your opinion, FME return when encountering an arc?
Notice also that there are 3 different types of arcs in FME:
http://docs.safe.com/fme/2019.0/html/FME_Desktop_Documentation/FME_Workbench/!FME_Geometry/Arcs.htm
+63
I agree about sample data being useful. Also, how many vertices should, in your opinion, FME return when encountering an arc?
Notice also that there are 3 different types of arcs in FME:
http://docs.safe.com/fme/2019.0/html/FME_Desktop_Documentation/FME_Workbench/!FME_Geometry/Arcs.htm
4 actually (by centerpoint, by centerpoint with ends, by 3 points and by bulge). According to the VertexCounter they all have 1 vertex though.
I am not sure what I would prefer to see to be honest, depending on how it's defined an arc in a complex line doesn't actually add a vertex imho.
4 actually (by centerpoint, by centerpoint with ends, by 3 points and by bulge). According to the VertexCounter they all have 1 vertex though.
I am not sure what I would prefer to see to be honest, depending on how it's defined an arc in a complex line doesn't actually add a vertex imho.
Wouldn't an "arc with centerpoint (no ends)" be considered a circle or an ellipse?
+63Wouldn't an "arc with centerpoint (no ends)" be considered a circle or an ellipse?
Only if it has a sweep angle of 360 degrees I would say. But we're getting into deep geo-existential subjects here ;)
Only if it has a sweep angle of 360 degrees I would say. But we're getting into deep geo-existential subjects here ;)
Yes, it's getting nerdy in here, but I like it ;-)
From the docs "The arc's definition implies start and end locations, but sometimes these locations may also be set explicitly." So my take is that the ArcByCenterPoint always has both end points, either implicitely or explicitely, so for the VertexCounter at least there should be no difference.
Also in the docs: "There are 3 ways to represent an Arc in FME." ;-)
Would you be able to provide sample data?
I'm unable to provide sample data but I can provide a screenshot of a typical line segment in my dataset. If you notice in the attribute table, the highlighted record has a column for VxCount_Pre, PREcoord_count, and POSTcoord_count. VxCount_Pre is the vertex count that I calculated in ArcMap using the Field Calculator. The PRE and POST coord_count are from the VertexCounter Transformer. As you see, the numbers don't match.
The line segment is highlighted in green and has it's corner rounded using the fillet tool in ArcMap. Rather than this be just one line segment, it seems like FME is considering this a line segment and an arc.
I agree about sample data being useful. Also, how many vertices should, in your opinion, FME return when encountering an arc?
Notice also that there are 3 different types of arcs in FME:
http://docs.safe.com/fme/2019.0/html/FME_Desktop_Documentation/FME_Workbench/!FME_Geometry/Arcs.htm
I would like VertexCounter to return the actual number of vertices that each line contains.
I would like VertexCounter to return the actual number of vertices that each line contains.
So if I understand this correctly, the following line with 3 segments should return 4 vertices?
Green are straight segments, red is an arc segment (regardless of type).
+63I'm unable to provide sample data but I can provide a screenshot of a typical line segment in my dataset. If you notice in the attribute table, the highlighted record has a column for VxCount_Pre, PREcoord_count, and POSTcoord_count. VxCount_Pre is the vertex count that I calculated in ArcMap using the Field Calculator. The PRE and POST coord_count are from the VertexCounter Transformer. As you see, the numbers don't match.
The line segment is highlighted in green and has it's corner rounded using the fillet tool in ArcMap. Rather than this be just one line segment, it seems like FME is considering this a line segment and an arc.
I wonder if there's been some stroking done to it somewhere along the line. Could you do this for us?
- Load the data in Data Inspector again.
- In the Display Control panel, right-click on the layer and make sure the option Mark Coordinates is set
- Zoom in a bit closer to that feature and take another screenshot.
+54- Evangelist
I wonder if there's been some stroking done to it somewhere along the line. Could you do this for us?
- Load the data in Data Inspector again.
- In the Display Control panel, right-click on the layer and make sure the option Mark Coordinates is set
- Zoom in a bit closer to that feature and take another screenshot.
Easy enough to recreate, the vertex counter does appear to stroke the arc in order to count the coordinates. Not sure what I'd expect to be the correct output in this situation, but I don't think it's correct to describe a line made up of two lines and an arc as having only 4 vertices either though
Easy enough to recreate, the vertex counter does appear to stroke the arc in order to count the coordinates. Not sure what I'd expect to be the correct output in this situation, but I don't think it's correct to describe a line made up of two lines and an arc as having only 4 vertices either though
Interesting to see that the VertexCounter is stroking the arcs internally. In my opinion this would be a very useful thing to note in the transformer documentation, @mark2atsafe
Would you be able to provide sample data?
So here is the line zoomed in with 'Mark Coordinates' checked in the Display Control panel. This line in GIS only has 4 vertices. It is a single line. How is the VertexCounter getting 21 vertices?
So if I understand this correctly, the following line with 3 segments should return 4 vertices?
Green are straight segments, red is an arc segment (regardless of type).
David, it is one line segment with 4 vertices.
So here is the line zoomed in with 'Mark Coordinates' checked in the Display Control panel. This line in GIS only has 4 vertices. It is a single line. How is the VertexCounter getting 21 vertices?
I suspect @egomm is right, the VertexCreator seems to stroke the arcs internally before counting the vertices.
You should consider contacting Safe support to confirm. Point them to this thread for details.
+22- Safer
I suspect @egomm is right, the VertexCreator seems to stroke the arcs internally before counting the vertices.
You should consider contacting Safe support to confirm. Point them to this thread for details.
@cshir065 Arcs of all types within an IFMEPath get stroked by the VertexCounter and return a high vertex count. But arcs not within IFMEPaths, will get a _coordcount of 1. Also, the node between two adjoining lines within an IFMEPath is not counted twice by the VertexCreator. Would it make sense that arcs within IFMEPath be counted as 1 vertex?
+59- Safer
Thought I'd paste a quick answer to address some of the comments and see if we can come up with a workaround...
I think that really ought to be changed to not stroke an arc. I don't see why it should be stroked at all. I'll liaise with Dan and the developers to see if we can get that changed, or if there's a reason it really ought to be stroked.
Do note that the Stroking Tolerance parameter (under Workspace Parameters in the Navigator) will affect the result. So if that's set to a particularly high number, then it would return 4 points for an arc.
One workaround would be to use the PathSplitter to separate out the arc. I think this must be a path. I don't see how you can get a line with embedded arc any other way. So PathSplitter, count the vertices (and maybe subtract the number of features to ensure where two lines meet isn't counted twice). Or just PathSplitter and filter arcs to handle them differently (count them however you want).
The other thought I had was a Chopper - but that strokes the arc too. Still you could probably filter out the mid-section vertices (use a DuplicateFilter on x/y, count the remaining features, add two to the count for the start/end points).
Thought I'd paste a quick answer to address some of the comments and see if we can come up with a workaround...
I think that really ought to be changed to not stroke an arc. I don't see why it should be stroked at all. I'll liaise with Dan and the developers to see if we can get that changed, or if there's a reason it really ought to be stroked.
Do note that the Stroking Tolerance parameter (under Workspace Parameters in the Navigator) will affect the result. So if that's set to a particularly high number, then it would return 4 points for an arc.
One workaround would be to use the PathSplitter to separate out the arc. I think this must be a path. I don't see how you can get a line with embedded arc any other way. So PathSplitter, count the vertices (and maybe subtract the number of features to ensure where two lines meet isn't counted twice). Or just PathSplitter and filter arcs to handle them differently (count them however you want).
The other thought I had was a Chopper - but that strokes the arc too. Still you could probably filter out the mid-section vertices (use a DuplicateFilter on x/y, count the remaining features, add two to the count for the start/end points).
Thanks, @mark2atsafe I'll try this work-around.
@cshir065 Arcs of all types within an IFMEPath get stroked by the VertexCounter and return a high vertex count. But arcs not within IFMEPaths, will get a _coordcount of 1. Also, the node between two adjoining lines within an IFMEPath is not counted twice by the VertexCreator. Would it make sense that arcs within IFMEPath be counted as 1 vertex?
@danatsafe I'm not sure if arcs within the IFMEPath be counted as 1 vertex makes sense to me.
+54- Evangelist
Thought I'd paste a quick answer to address some of the comments and see if we can come up with a workaround...
I think that really ought to be changed to not stroke an arc. I don't see why it should be stroked at all. I'll liaise with Dan and the developers to see if we can get that changed, or if there's a reason it really ought to be stroked.
Do note that the Stroking Tolerance parameter (under Workspace Parameters in the Navigator) will affect the result. So if that's set to a particularly high number, then it would return 4 points for an arc.
One workaround would be to use the PathSplitter to separate out the arc. I think this must be a path. I don't see how you can get a line with embedded arc any other way. So PathSplitter, count the vertices (and maybe subtract the number of features to ensure where two lines meet isn't counted twice). Or just PathSplitter and filter arcs to handle them differently (count them however you want).
The other thought I had was a Chopper - but that strokes the arc too. Still you could probably filter out the mid-section vertices (use a DuplicateFilter on x/y, count the remaining features, add two to the count for the start/end points).
Is there a way to identify if a feature is a path without splitting it?
+54- Evangelist
Thought I'd paste a quick answer to address some of the comments and see if we can come up with a workaround...
I think that really ought to be changed to not stroke an arc. I don't see why it should be stroked at all. I'll liaise with Dan and the developers to see if we can get that changed, or if there's a reason it really ought to be stroked.
Do note that the Stroking Tolerance parameter (under Workspace Parameters in the Navigator) will affect the result. So if that's set to a particularly high number, then it would return 4 points for an arc.
One workaround would be to use the PathSplitter to separate out the arc. I think this must be a path. I don't see how you can get a line with embedded arc any other way. So PathSplitter, count the vertices (and maybe subtract the number of features to ensure where two lines meet isn't counted twice). Or just PathSplitter and filter arcs to handle them differently (count them however you want).
The other thought I had was a Chopper - but that strokes the arc too. Still you could probably filter out the mid-section vertices (use a DuplicateFilter on x/y, count the remaining features, add two to the count for the start/end points).
A thing to consider, if breaking a path down into constituent parts, if the arcs are at the beginning or end of the feature, counting coordinates and then subtracting the number of features the end result is going to be one less than what is probably desired.
Is there a way to identify if a feature is a path without splitting it?
If, by path you mean a path containing at least one arc, see:
https://knowledge.safe.com/questions/90393/how-to-filter-polygon-which-are-composed-of-both-l.html
+54- Evangelist
If, by path you mean a path containing at least one arc, see:
https://knowledge.safe.com/questions/90393/how-to-filter-polygon-which-are-composed-of-both-l.html
No, a path with or without arcs.
No, a path with or without arcs.
I think a PythonCaller with this check should work:
geom = feature.getGeometry()
if isinstance(geom, fmeobjects.FMEPath):
# feature geometry is an FMEPath instance