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.
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
+49- Celebrity
david_r wrote:
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.
redgeographics wrote:
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?
+49- Celebrity
david_r wrote:
Wouldn'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 ;)
redgeographics wrote:
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." ;-)
canerakin wrote:
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.
david_r wrote:
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.
cshir065 wrote:
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).
+49- Celebrity
cshir065 wrote:
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 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.
+31- Influencer
redgeographics wrote:
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
ebygomm wrote:
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
canerakin wrote:
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?
david_r wrote:
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.
cshir065 wrote:
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.
+17- Contributor
david_r wrote:
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?
+43- 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).
mark2atsafe wrote:
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.
fmelizard wrote:
@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.
+31- Influencer
mark2atsafe wrote:
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?
+31- Influencer
mark2atsafe wrote:
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.
ebygomm wrote:
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
+31- Influencer
david_r wrote:
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.
ebygomm wrote:
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
Reply
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.