Skip to main content
Solved

Clippee lines


Forum|alt.badge.img

Hello! I used Clipper to divide the lines with the areas. In some places as a result of "outside" I got lines consisting of two elements.

How can I remove parts of lines that do not get red line? I used Chopper to separate the lines and then I wanted to filter the data through Spatial Filter (by "filter intersects candidate" where Filter is a red line) but it doesn't take into account Chopper's separation..

Thanks for your help

 

Best answer by gio

forum-tramm.fmwt

Hi @tramm

 

Your input data seem topologically not healthy.

Clipper totally fails. as does the spatialfilter. Indeed objects mysteriously disappear.

1 LineOnAreaOverlayer.Tester for overlaps>0

2 Create a area (drop hole) with 22344 and 22345.

3 Geometrycoerce those 2, because they are lines but have fme_type polygon.

4 Use these as anchor in a AnchoSnapper with the lines from step 1 as candidates. I uses 0.1 as tolerance (0.2 is too much)

5 Output from anchorsnapper to Spatialrelator (anchors as suppliers)

6 listelementcount on SpatialRelator output.

Test _element_count > 1

result:

I uploaded the workbench.

View original
Did this help you find an answer to your question?

11 replies

redgeographics
Celebrity
Forum|alt.badge.img+50

So if I read you correctly you want to remove the circled lines and they're aggregated with their corresponding parts on the other side of the clipper feature. Deaggregating them (with a Deaggregator) and then your SpatialFilter should do the trick.


redgeographics
Celebrity
Forum|alt.badge.img+50
redgeographics wrote:

So if I read you correctly you want to remove the circled lines and they're aggregated with their corresponding parts on the other side of the clipper feature. Deaggregating them (with a Deaggregator) and then your SpatialFilter should do the trick.

Or... you could set the Create Aggregates parameter in the Clipper to No, that has the same effect as deaggregating them.

 

 


Forum|alt.badge.img
  • Author
  • October 25, 2018
redgeographics wrote:

So if I read you correctly you want to remove the circled lines and they're aggregated with their corresponding parts on the other side of the clipper feature. Deaggregating them (with a Deaggregator) and then your SpatialFilter should do the trick.

Thanks for your answer @redgeographics. it generally works, but I think that SpatialFilter is not quite a good solution for my data ..some of the lines are incorrectly filtered.

 

 

by the way: short lines were created using 2DVectorCalculator

redgeographics
Celebrity
Forum|alt.badge.img+50
tramm wrote:
Thanks for your answer @redgeographics. it generally works, but I think that SpatialFilter is not quite a good solution for my data ..some of the lines are incorrectly filtered.

 

 

by the way: short lines were created using 2DVectorCalculator
What kind of result were you expecting to see? Have you tried "Filter Touches Candidate" as well?

 

 

Can you share a small sample dataset? Clipper, Clippee and Filter features.

 

 


gio
Contributor
Forum|alt.badge.img+15
  • Contributor
  • October 25, 2018

@tramm

When you use the filter predicate "intersects", touching lines will be selected as well.

A way to filter those out is to use a spatialrelator instead of a spatialfilter.

Activate the option "calculate cardinality" (spatial filter does not offer this option)

List concatenate, without a separator, the attribute "relationships{}.card_line". If the result is 0, then there is just a touching relationship. You can filter those out using a tester.

"relationships_card_line" is created by the spatialrelator.

(Also you could consider using a LineOnAreaOverlayer instead of a clipper. Then testing for overlaps >0 would possibly suffice)


Forum|alt.badge.img
  • Author
  • October 25, 2018

@redgeographics i tried "Filter Touches Candidate" and it doesn't work too. Some of Clipee have been "eaten" by SpatialFilter translator...I would like to receive only this part of Clippee lines that begin on the Filter(becouse Filter-lines were created by 2DVectorCalculator with Filter)

Outside Clippee:

and I expect:

that's my data:

clippee.dgn

 

clipper.dgn

filter.dgn

I used GeometryCoercer to turn areas into lines


Forum|alt.badge.img
  • Author
  • October 25, 2018
gio wrote:

@tramm

When you use the filter predicate "intersects", touching lines will be selected as well.

A way to filter those out is to use a spatialrelator instead of a spatialfilter.

Activate the option "calculate cardinality" (spatial filter does not offer this option)

List concatenate, without a separator, the attribute "relationships{}.card_line". If the result is 0, then there is just a touching relationship. You can filter those out using a tester.

"relationships_card_line" is created by the spatialrelator.

(Also you could consider using a LineOnAreaOverlayer instead of a clipper. Then testing for overlaps >0 would possibly suffice)

thank's @gio it's a good clue but some of Filter data disappears after translation so i'm not sure the relation between lines :/

 


gio
Contributor
Forum|alt.badge.img+15
  • Contributor
  • Best Answer
  • October 26, 2018

forum-tramm.fmwt

Hi @tramm

 

Your input data seem topologically not healthy.

Clipper totally fails. as does the spatialfilter. Indeed objects mysteriously disappear.

1 LineOnAreaOverlayer.Tester for overlaps>0

2 Create a area (drop hole) with 22344 and 22345.

3 Geometrycoerce those 2, because they are lines but have fme_type polygon.

4 Use these as anchor in a AnchoSnapper with the lines from step 1 as candidates. I uses 0.1 as tolerance (0.2 is too much)

5 Output from anchorsnapper to Spatialrelator (anchors as suppliers)

6 listelementcount on SpatialRelator output.

Test _element_count > 1

result:

I uploaded the workbench.


gio
Contributor
Forum|alt.badge.img+15
  • Contributor
  • October 26, 2018
gio wrote:

forum-tramm.fmwt

Hi @tramm

 

Your input data seem topologically not healthy.

Clipper totally fails. as does the spatialfilter. Indeed objects mysteriously disappear.

1 LineOnAreaOverlayer.Tester for overlaps>0

2 Create a area (drop hole) with 22344 and 22345.

3 Geometrycoerce those 2, because they are lines but have fme_type polygon.

4 Use these as anchor in a AnchoSnapper with the lines from step 1 as candidates. I uses 0.1 as tolerance (0.2 is too much)

5 Output from anchorsnapper to Spatialrelator (anchors as suppliers)

6 listelementcount on SpatialRelator output.

Test _element_count > 1

result:

I uploaded the workbench.

@tramm

 

 

btw, using cardinality on the spatialrelator yields the same result in this case. But only after snapping.

 

Without snapping almost all interior lines fail.

 


Forum|alt.badge.img
  • Author
  • October 28, 2018
gio wrote:
@tramm

 

 

btw, using cardinality on the spatialrelator yields the same result in this case. But only after snapping.

 

Without snapping almost all interior lines fail.

 

Thanks a lot @gio It looks much better! i can see that some of Clippee data are incorrectly filtered (but only a few lines)

 

Clippee should be placed at regular intervals on each section between vertexes of Filter area.

 


gio
Contributor
Forum|alt.badge.img+15
  • Contributor
  • October 29, 2018

@tramm

It is not die to filtering that incorrect ones are filtered or not.

It is due to the prior process that creates the lines. Most do not intersect with the border of the polygon (that is why is snapped at 0.1).

The ones that are unwantedly filtered only (segment) snap at 0.2 or higher. Segmentnapping at 0.2 creates new problems.

You need to do something about your previous process (which I don't know).


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings