Question

cleaning GPS line work


Badge

Hello

I am trying to clean up some GPS line work before it is loaded into our database. THe lines need to be free of self intersections. I have come close to accomplishing this by buffering the line and then using the centreline replacer to create a smoothed line. The problem is that the centreline replacer is creating short dangles along the length of the line. The actual centreline it is creating is good enough for my purposes I just need to remove the dangles. If anyone has any ideas on how to do this it would be much appreciated.

In this screen shot the Green line is the original line with self intersections and the red line is the result of the centreline replacer.


22 replies

Badge +9

Have you tried the GeometryValidator already? That should correct your self intersecting lines if you set the attempt repair to yes..

Badge

Have you tried the GeometryValidator already? That should correct your self intersecting lines if you set the attempt repair to yes..

Yes I tried Geometry validator. It didn't catch all self intersection and failed to repair several that it did catch

Userlevel 5

Maybe try the Generalizer? There is also the SpikeRemover.

Userlevel 4
Badge +25

You could run the centreline through a Deaggregator and then try to get rid of the dangles in some way. Maybe test their length and throw away features less than x in length. Reducing the buffer size would probably help in this scenario.

But still, I would like to clean up the original data, not create a new centreline from it. But I think we'd need the data to do that. I'd like to know why the GeometryValidator isn't identifying or removing all of the self-intersections.

Badge

I was able to get the Geometry Validator to catch all the self intersections by all checking off "Contains NAN" and "Degenerate or Corrupt Geometries" as well as "self intersects in 2D" but it still doesn't seem to be repairing the self intersections. The screenshot below shows the same feature as the first screenshot as it came out of the geom validator repaired port.

Badge

You could run the centreline through a Deaggregator and then try to get rid of the dangles in some way. Maybe test their length and throw away features less than x in length. Reducing the buffer size would probably help in this scenario.

But still, I would like to clean up the original data, not create a new centreline from it. But I think we'd need the data to do that. I'd like to know why the GeometryValidator isn't identifying or removing all of the self-intersections.

When I use the deaggregator The "main" centreline gets split into many short segments many of which are shorter than the dangles so filter the dangle out by length isn't working. Is there any way to get the centreline replacer to only generate one line down the centre of the polygon?

 

 

Badge +16

Have you tried several iterations of the GeometryValidator?

Badge

Have you tried several iterations of the GeometryValidator?

I just tried running it through 2 geometry validators. On the second iteration they all pass the validation check even though there is still an visually obvious self intersection in the line.

 

 

Badge +9

Have you tried the generalizer as suggested by david_r ? I suppose it depends on how much you want to compromise your original data but I think it would work and remove the 2d intersects by straightening out the line shown in your original dataset in green.

You could do minimal generalisation on all data and then extreme generalisation on those that fail 2d intersection. Or only generalise the lines that fail?

Userlevel 4
Badge +25
When I use the deaggregator The "main" centreline gets split into many short segments many of which are shorter than the dangles so filter the dangle out by length isn't working. Is there any way to get the centreline replacer to only generate one line down the centre of the polygon?

 

 

Right, I was thinking if you made the buffer really small then the dangles would be smaller than any short segments in the main centreline. Anyway, I'm going to file some enhancement requests with our developers - they won't help right now, but hopefully will help others in the future.

 

 

Badge

Have you tried the generalizer as suggested by david_r ? I suppose it depends on how much you want to compromise your original data but I think it would work and remove the 2d intersects by straightening out the line shown in your original dataset in green.

You could do minimal generalisation on all data and then extreme generalisation on those that fail 2d intersection. Or only generalise the lines that fail?

This method is working for most of my gps lines. I ran the features that failed validation through a generalizer to remove self intersections and then a second generalizer with smoothing algorithm. The smoothing algorithm makes the line work a bit more cartographically pleasing as it is very jagged after the first generalizer. the last step is to run the features through another validator to check for any remaining self intersections, any features that fail the second validation are edited by hand. This process results in very few manual edits and the generalized line work is still with in the error of the original GPS line work.

 

 

Badge +9
This method is working for most of my gps lines. I ran the features that failed validation through a generalizer to remove self intersections and then a second generalizer with smoothing algorithm. The smoothing algorithm makes the line work a bit more cartographically pleasing as it is very jagged after the first generalizer. the last step is to run the features through another validator to check for any remaining self intersections, any features that fail the second validation are edited by hand. This process results in very few manual edits and the generalized line work is still with in the error of the original GPS line work.

 

 

Great ! Sounds like success

 

 

Badge +16
I just tried running it through 2 geometry validators. On the second iteration they all pass the validation check even though there is still an visually obvious self intersection in the line.

 

 

Any chance it is a 3D intersection?

 

 

You could run the centreline through a Deaggregator and then try to get rid of the dangles in some way. Maybe test their length and throw away features less than x in length. Reducing the buffer size would probably help in this scenario.

But still, I would like to clean up the original data, not create a new centreline from it. But I think we'd need the data to do that. if you need help related to the powerpoint go to the Ms powerpoint customer service

Userlevel 4
Badge +25

I wanted to add a new answer to this question. In 2019 the CentreLineReplacer has a new mode for creating the approximate centre line. With the data I tried it on, the difference looks like this:

So no more odd branching when replacing the centreline of a long, twisting polygon.

NB: it's in 2019, so needs the beta build of FME for now.

Userlevel 5

I wanted to add a new answer to this question. In 2019 the CentreLineReplacer has a new mode for creating the approximate centre line. With the data I tried it on, the difference looks like this:

So no more odd branching when replacing the centreline of a long, twisting polygon.

NB: it's in 2019, so needs the beta build of FME for now.

That's a significant improvement, bravo!
Userlevel 3
Badge +17

I wanted to add a new answer to this question. In 2019 the CentreLineReplacer has a new mode for creating the approximate centre line. With the data I tried it on, the difference looks like this:

So no more odd branching when replacing the centreline of a long, twisting polygon.

NB: it's in 2019, so needs the beta build of FME for now.

Amazing! Thanks for the enhancement.

 

 

Badge +3

@mapper

This works on simple selfintersections (if you intend to remove the offending bit)

Badge +3

@mapper

This works on simple selfintersections (if you intend to remove the offending bit)

 

her is a pic

 

Badge +3

I wanted to add a new answer to this question. In 2019 the CentreLineReplacer has a new mode for creating the approximate centre line. With the data I tried it on, the difference looks like this:

So no more odd branching when replacing the centreline of a long, twisting polygon.

NB: it's in 2019, so needs the beta build of FME for now.

hmm, got to try it. See if it performs on large and complex sets.

 

 

I made my own cl replacer, using only fme transformers. But it is big, has 4 levels of customs and takes a lot o process time and memory. (but at least does not crash and create those skelly lines)

 

 

Badge

I wanted to add a new answer to this question. In 2019 the CentreLineReplacer has a new mode for creating the approximate centre line. With the data I tried it on, the difference looks like this:

So no more odd branching when replacing the centreline of a long, twisting polygon.

NB: it's in 2019, so needs the beta build of FME for now.

Hi @Mark2AtSafe, that looks very promising. I know there's been a few comments that the beta should have been available at the end of July, is there any update as to when this will be released?

 

Userlevel 4
Badge +25
Hi @Mark2AtSafe, that looks very promising. I know there's been a few comments that the beta should have been available at the end of July, is there any update as to when this will be released?

 

We're trying for sometime this week (so by the end of 10th August). I can't guarantee, but it's almost certainly just a few days rather than weeks. We wanted it to come after 2018.1 released, and that got delayed, hence the delay in the 2019 beta.

 

Reply