Hi MAVA,
I would try using:
- ChangeDetector to detect geometries that exactly match with any of sources,
- SpatialFilter to determine whether a geometry overlaps with any of sources,
- NeighborFinder to filter geometries based on proximity to sources,
rather than the AncheredSnapper.
Takashi
Hi Takashi,
Thank you for your information. I forgot to mention that the objects are geometrically accurate and correct. The border boundery (province Noord-Holland) has to undergo modifications and changes. So the BB layer has to snap to the objects layers if the condition within 60cm is true.
The problem is that the vertexes of each objects are too inaccurate, so I the snapping tolerance in the AnchoredSnapper (vertex snapping) is also too inaccurate (See picture). The red lins is the original border boundery and the purple the new one. I try now to use the chopper and /or the snipper to add vertexes to the object layers and run the anchoredsnapper again. I did before also the segment snapping option. This give better results, but toke more than 12 hours to finish. And I have more slivers and under- overshoots, thus I tried a disolve but gave no proper reuslts.
Please let me know if I am on the right track.
As you mentioned, the AnchoredSnapper (Segment Snapping) may be a better solution. The problem is that it took too long time. Whether you can resolve the problem / how to resolve it, depends on the actual data condition.
In my experiences, it may take long time to complete the processing if the geometries were not so clean. Naturally, when there are so many features that should be processed simultaneously, it also takes long time.
The tips I can now suggest are:
1) Try using GeometryValidator and/or SpikeRemover to repair the geometries beforehand, especially for repairing self-intersections and spikes.
2) If there is an attribute which can be used to group an original feature and the associated candidate feature, try using the "Group By" parameter of the AnchoredSnapper.
In addition, if there is such a grouping attribute and the geometries are polygon, there might be other approaches - AreOnAreaOverlayer or Clipper etc., other than the AnchoredSnapper.
I have a script somewhere that does something like this:
Making a 60cm bufffer and coerce it to a polyline.
Then use an intersector.
Separate the points on its border from points that fall within the 60 cm band.
Points wihtin u need to chopp to 2 vertice-pieces.
Have the points on the 60cm line find closest neighbours on the border itself.
Use the border and the found points on this border in a topologycreator, this can sort these points.
Now u should have 3 sets of points each internaly sorted.
U can combine these sets.
To sort these you could raise the counter/nr of each by the total count of the other, working from the border to the center section to the outer border.
A pointconnector would be able to create the polyline running trough these points.
U would need to have at least 2 groouping ID, one for the objects, one for the band they recide in (border, burfferrange, outline of buffer).
Hi Gio,
Thanks for your information. Do you have an example workbench (screenshot) for me? I try your suggestions but I fail to construct the workbench.
MAVA
Takashi & Gio,
I tried the clipper and buffer (>60cm), but runs out of memory. I add also vertexes with the densify transformer because the original input features have to less vertexes to snap accurate.(anchorsnapper option snapping vertex). I am satisfied by this result if I dont have to embedded the condition "find the closest feature within 60cm band'' . Of course I can use the neigborhoodfinder for this condition, but the output 'matched' I cannot use for the input 'anchored' in the AnchoredSnapper. I tried to drop the Cllpper between them, but I am not sure of the correct results.
MAVA
Hi,
the algorithm from my first post (see above) is a little changed. Now the client want first that all objects are geometrically equal to the boundary border and where one of the 7 objects touches the boundary border than preserve that part of the boundary border and leave it unchanged. First I changeDetector and after I convert the object polygons to a fme_line (geometrycoerser) and add a topologybuilder. Same I did for the boundary polygon. Then I use the spatialrelator (The boundary border = requester, the objects = supplier). I use test perform TOUCH but how can I extracted all features that mismatched in a easy way? I try with a tester with the condition _related_candidates != @Evaluate( =true) to retrieve the mismatch. Is this the right option?
related candidates is a counter.
related_candidates>0 will get the touching ones.
Also lines touching at a point get passed.
This u can check by using cardinality. (relationships_card_line=0 and .._card_point>0). This is a hidden attribute btw.
Hi Gio,
I tried your suggestions, but no result. 0 results passed the Tester. However in the original data I definetely is shown touches lines between the objects and border boundary polygons. I set the geometrycoerser of the boundary polygon to 'line' and the objects one to 'points. I run the Tester with test criteria 'One Test(OR)'. I place the topologybuilder between the spatialRelator and the geometrycoerser 'line' (boundary border) and and 'points' (objects). In the original file objects polygon I discover very less vertexes compared to the boundary polygon. Thats why I add the densify too. Now the proccess is still running..
Hi,
I run but insufficient memory available, error code was 2 - please read the FME Help section 'Adjusting Memory Resources' for workarounds.
I will try a run without topologybuilder....
Hi Gio,
several times crasht..I work with a trail version. Without running topologybuider, no changes appeared in the tester, all test conditions failed. I tried geometrycoerser point, line and polygon for both the objects file en boundary border file, but same results: all test conditions failed. Does the topologybuilder fixed topology based on vertexes in the original data?
Hi MAVA,
After u coerce to line you can use a Spatialrelator. U must set calculate cardinality ot "yes".
If u test for related canidates >0 u get all the related of course. See pic
But if you set the tester to related canidates >0 AND _relationships{0}.card_line > 0
u get only the ones related by line-touching. See pic
This is a hidden attribute. It appears in the feature information window, see pic6
Here is an example:
pic1: i want the borders touching the puprple polygon.
Coerce the brown polys to lines. Then build topology using topology builder, use input line only.
Then use spatialrelator
set calculate cardinality to "yes"
pic6
Look at feature information window.
List with cardinalities is produced.
This is result if u test for related candidates>0:
Now when u test for: related canidates >0 AND _relationships{0}.card_line > 0
this is the result; only border matches:
If a line touches more then one border the list wil have more then one entry. This means u may have to test ffor more
related canidates >0 AND _relationships{0}.card_line > 0 AND _relationships{1}.card_line > 0 etc.
Hi Gio,
Thanks for your clear explanation. However, in my case the polygons are not equally touching each other. One of the objects (terrain) purple above, is at one part touching the boundary border (red) and the other side is not equally touching. (See picture). I labbel the objects to clearify that each label represent 1 terrain polygon.
I follow your instruction but the I get the blauw lines of Rejection polygon feature 'polygon feature must have at least 4 coordinates...rejectiong.: Thats why I put a chopper between geometry coerce and topologybuilder.
Hi Mava,
The error is because u have (poly)lines entering a port that requires polygons.
Do not chopp the lines before u do topology builder. That messes it up a bit because chopped bits dont get a relation, and the one that do get smaller with topolgybuilding. You get more and more objects wich slows down the process.
What i do is create a topolgy of the coerced polygon (polygons to lines).
Then use a lineonareaoverlayer. This separates the lines base on the polygons.
After that u can use a spatialrealtor and test for lin only related candidates.
You need to create a topology between the polygons and the red borders (polylines) as wel.
That way the bit that cross the polgons get a seperate relationship wich u can query.
Maybe u can post a sample dataset, i could build a workbench as an eample for you.
I understood from your previous post that u need to keep the match borders and keep the border of the purple objects where they do not, is this correct?
hi Gio,
I want to post the sample workbench, how can I do this here? Where the borders of the purple objects do not touch the border boundary objects, the red polygon (boundary border polygon) has to adjusted to the objects boundary if the condition - objects are within 60cm of the red line polygon - is true. The latter is phase 2 workbench. Now I want to add only the workbench phase 1 (touch polygons).
Hi Gio,
I finally succeed in processing the notouch polygons! The LineonAreaOverlayer was the missing transformer! Many thanks! However some no touch polygons (62) are in reality touched.
See below a feature which pass the tester ( failed) but is still touching the boundary border (red line).
Now without de red polygon and NoTouch polygon border.
So, the right polygon fails...
Aah...I forgot the composite test (AND & AND & AND).... I will run now the workpace again...
Hi MAVA,
First of all i see Noord_Holland....i live in Zuid-Holland...Leiden.. groetjes!
The workspace begins to look good.
To create the Topology you do not need the densifier. Using it will just create more porcessing time because of more veritces.
btw:
this
related canidates >0 AND _relationships{0}.card_line > 0 AND _relationships{1}.card_line > 0
should be
related canidates >0 AND (_relationships{0}.card_line > 0 OR _relationships{1}.card_line > 0)
If u have lots of objects and are not sure how many elements related_candidate_list has you can do it like this:
Tester:
1 related canidates >0
2 _relationships{0}.card_line > 0
3 _relationships{1}.card_line Exists
4 _relationships{1}.card_line > 0
5 _relationships{2}.card_line Exists A
6 _relationships{2}.card_line > 0
.
.
.
n _relationships{m}.card_line Exists
n+1 _relationships{m}.card_line > 0
Passcriteria COMPOSITE
1 AND (2 OR (3 AND 4) OR ( 5 AND 6)....OR (n AND n+1))
Or use listfunctions and build a loop, also possible.
Also if your inputobjects are validgeometries, you do not need to validate them that often.
Maybe only the areas after the LineOnArea overlayer on the area-objects. (i would try without alltogether, this saves processtime)
I never had line objects collapse to invalid objects.
In my experience this risk is ussualy when using the intersector on areas.
Groetjes/Greets
Hi, hallo Gio,
I have run some tests without the densifier..but it crashst..That is, I guess, because the object file (terreinobjecten) have far to less vertexes compared to the border boundary polygon (bronhoudersgrens Prorail, Noord-Holland). Any way, the processing time is considerably reduced since I embedded the LineonAreaOverlayer. Still a point of concern is the number of touch line segments. Some parts (line segments) of the boundary border polygon still touches the object polygon, aldo these features contain in the failed tester output writer (No touch writer). I just added an additional cardinality line relationship, up to 10. May be now I get improved results. However, the failed tester output features are the input of the neigborhood analysis in the 2e phase (see the workbench below). the condition is 60cm from the border boundary (=base). All the object outside the 60cm radius, I have to mark for more detail research. I want to use a different colorsetting for these objects, but I do not succeed in that yet.
Because the objects (terrein in this test workbench) are geometrically accurate and correct, I use the Anchoredsnapper (objects as anchor) with a tolerance of 0.01
Groet, MAVA
Hi Gio,
The test results with the 10 relationship.card lines made no difference: remain with 5 test passed (touch condition). I used 'match regex'; the operator EXISTS is not available in the pickup list wihtin the tester.
Hi Takashi & Gio,
I maded some runs and still 5 features are written to Brongrens_result and 542 to No_Touch result. However, I discover that 2 features of Brongrens_result still contain not the desired result. See example below.
The total number of a relatonship.cardlines is 12 in the Tester. The previoues runs at 11th of october last I used 10 relationship.card lines with also 5 features passed to Brongrens_result. My wish and hope was within FME it was possible that the two line elements in the example where written to the NoTouch_Result written (fail Tester results). (These two line segments does not the object Terrein - black dash line. Do you think I have to adjust this manual or is there still alternative within FME to a complete automazed solution?
Marco
"operator" "does not exist" was till fem2013.
In fme2014 it is "attribute is missing" or "missing"
Hi again,
About the "no touch" picture..
They do touch, they touch by points and nrather than lines.
This means that
card_point>0 and card_line=0
You should test for that NOT(card_point>0 AND card_line=0).
They should be removed by this test.
