Hi,

Are you saying that the self-intersecting is not crossing over like, but touching at a particular point (Say if your line looked like a "P"). If so, the Intersector will tell you the number of "_overlaps". You should also "group by" a unique id, so that it doesn't intersect with all other features. Also since you are looking at individual features, set "Input is order by Groups" to Yes (That just means that as each feature comes in to the intersector it will be processed straight away rather than waiting for the whole dataset to be loaded before performing the function).

Hi Todd,

In my case, the definition of self intersecting is both crossing over and touching at a particular point. GeometryValidator only flags the ones where crossing over occurs. I am only feeding in one feature class to the filter. Do I still need to select a "group by" id? I tried setting "Input is order by Groups" to Yes but that does not change the result.

Hi Todd,

Say I use group by its id, what should I check against? Inputting the class as both "filter" and "candidate" in SpatialFilter just yields a 100% of the lines being intersected. Same with SpatialRelator. GeometryValidator doesn't work either. It Note that it is a network we are talking about where one segment touches the next. I want to just find any errors where one segment intersects with itself and creates a loop.

Any other transformers come to mind?

First you do need a identifier for the features, if you don't have one use a counter as suggested.

Spatial relating a object with itself will not yield this information. You need to dismantle it.

One of many methods:

1. Exctract vertex order (wich is last and wich is first)

2. snip last piece of both lines , then snip last vertex of each snipped endpiece.

3 use point online overlayer between remnant lines and snipped ends (spatialrelator won't work due to accuracy failure and PoL has a tolerance setting) PoL with ID as GroupBy attribute.

4 Merge original line using ID as mergeattribute

See pic

I did not test for self-intersection, as you got that tackled already.

To be honest, I just created a "P" shaped geometry and the GeometryValidator did pick it up as being a self-intersection. The coordinates I used are these:

So point 7 lands on the line between point 0 and point 1 and that counts as self-intersecting, even though it's only touching and not crossing over.

Can you upload a single geometry that doesn't give the result you expect? That way we can look and see what the exact reason is. Just divert a single feature into an FFS format writer and post it here.

If you need to process everything separately in a group-based transformer like Todd suggests, then use a Counter transformer to give an ID number and use that ID as the group by attribute.

Regards

Mark

Hi Mark, @Mark2AtSafe

That is (the "P") exactly the kind of geometry that none of the transformers are picking up. I am able to pick up the ones that self-cross and the ones that closes back on the first point and creates a loop (Using ClosedCurveFilter). The ones that are left over are the P shaped ones and the ones that interact with other lines in the network. You can take a look at the file attached. primaryoverheadtest.zip

It is a shapefile. I'm sorry I can't seem to convert it to FSS format.

I have attached the shapefile of an electric conductor network that is made up of many different line segments. The picture attached shows the few loops I added myself in order to test network integrity using FME. All 4 of those loops needs to be detected. Unable to find anything in FME that would detect the P.

The 3rd picture shows the workflow I have (Note, I only sent you one of the input files. They are both the same type only the network is different)

I appreciate your help Mark. Thanks!

@fariyafarhad

Hi,

What it does is get both ends of the polylines, wich consist of the 2 begin and 2 end vertices.

So snipper1 for begin piece 0 to 1 and

snipper2 for end piece -1 to -2. (the order is important for the direction)

The 3th snipper now gets the 1st vertex of each of the linepieces.

This point is then compared to the remnats of the polylines (the pieces minus the begin and end parts)

If a end point is on the remant line, then it is "selftouching"

Therefore tester test for overlaps >0.

Merger to retrieve the original line ( you could also pass the original line by using geometryextractor and geometryreplacer)

I use a PointOnLine overlayer as you can enter a tolerance. This is needed due to rounding errors.

If u use a spatialrelator you woul need to buffer the point first. (buffer would fill the tolerance function)

In addition to the LineOnLineOverlayer and the Intersector, consider the SpatialRelator or SpatialFilter testing for "Intersects". That way you don't end up with clipped geometries that you'll have to merge back later.

Spatialrelator and Spatialfilter have no tolerance settings.

You would have to create buffers first.

Overlayers don't require latter and safe some processing time.

The bad features are caused by calculatory inaccuracy.

Yu can easily test it.

Create a random square ( so don't pick integer coordinates please.)

Then extract the vertices, then try if you can get them to relate using a spatialrelator.

Often it is wiser to relate spatialy by extracting coordinates and compare them whilst round the operands. ( not actualy rounding coordinates that is)

(round (a_X*1000)/1000 - (round(b_X*1000)/1000 for instance.