Hi Gio,
Thank you for the workbench. I reproduce it, but did not succeed it to run successfully. However, in my case I start with polygon shape files, no lines. I dont understand your buffer transformer after the areabuilder. And in the neighborhoodfinder you use a offset *1.05 (if I read well, the picture is not very readable for me). Why you use here 1.05? In your example - pic 1 - the outer red lines are the extended parts of the new boundary border polygon. This lines should included in the final bordery bounder polygon. All mismatched, at the height of the geographical location of objects ( but outside the 60 cm zone) , the border polygon should be marked as redlining.
may be you can give me some remarks with the workbench below how to fix it...(I use in the example one object (terrein area) but I have to use all 7 objects. The Noord-Holland shape is the border polygon.
Marco.
... In my workbench I added the LineonAreaOverlay transformer, because I have objects that cover whole the Netherlands. The province of Noord-Holland is the work area. (I prefer to copy and past this workbench if it is correct to the other provinces and run the workbench 12 times due to performance problems).
The buffer is to create the testing distance, wich in your case is 60cm.
The stringsearcher after the first topology builder is to take apart the attribute "_polygons" that is created by this topologybuilder.
This attirubte indicates if a linepiece is on the border of a polygon (after topologybuikd) (1,0) on border and (>1,0) inside polygonarea (in my case the buffer.
So the stringsearcher get the first number in _polygon=(n,m) and test if it is 1 or larger.
The spatialrelators that follow test if the "borderlinepieces" fall within the objects of not. If not then they ar kept else discarded.
The spatialrealor on the bottom test wich piece of the object is in range (falls within the buffer) You were lookin for 60cm range (my value is because i made my testobjects randomly)
I added the bit with chopper to get all te vertices involved. THe neighbourfinder uses 1.05*offset (offset is a paramater and is the buffer amount, you would set it to 60cm).
It has to be a bit more then offset because else it will not find the points on the border of the buffer ( so it would not find objects at 60cm. I think this is eitehr rounding error or a bug in fme)
The cloner is just in there to keep the workspace tidy. No function it serves.
The bottom vertextcreator (set to Add) creates the lines indicating where the border would have to be altered by the "in range" pieces.
So in your workspace the string to search sould be
"_polygons" and not "_Noord_H_ID"
The reuglar expression must be
(\\d),.
(so including the comma and dot ...met de punt en de komma erbij)
You must add the buffer. Use as offset 60cm and in the neighbourfinder 60+ cm (61 might be sufficient) Or create a user parameter called offset as i did, you can then change the value as or when u wish.
Hi Gio,
I the OBG polyline (purple) (keep border) is at one side right. (is not visuable here, the purple line lies below the red one. It touches the original border polygon below (red). I want to preserve the purple line below the red line. This line (as part of the original border polygon, should be redlining). The other purple line, visuable in the picture, I dont need to keep. I guess to use the clipper for this, but I am not sure.
Hi Gio,
Unfortunately I dont get the results I want. I used your workbench, a little modified. I am only interested in the border polylines as output, not the testobjects. Also within the 60cm range, the red border polyline does not 'snap' to the outerline 'touched' 'overweg' polygon. See example.
I used the follow workbench:
here a picture of the wrong buffer used: The 'object gelijk aan de border' should be equal to the red line, but its not.
Here a picture of the wrong intersection_lines:
The yellow part is the terrain object. The intersected_lines should follow the red line over the terrein polygon object, not to folow the extend of the terrein polygon.
I definitely have to use the buffer at another place in the workbench.
Here is a dutch description of the task:
OPDRACHT
Klant: ProRail
Opdrachtgever: SVB-BGT
Onderwerp: De BGTV1] is het nieuwe topografische objectenbestand van NL. De BGT is een landsdekkend objecten bestand (alle vlakken samen bedekken de gehele aardbodem van NL) dat door 7 bronhouders wordt opgebouwd en beheerd. Iedere bronhouder is verantwoordelijk voor de opbouw en het beheer van de BGT objecten binnen haar bronhoudergrenzen. De BGT is een van de 12 Basisregistraties.
De bronhouders zijn (in volgorde van prioriteit):
Defensie
ProRail
Ministerie van Infrastructuur en Milieu (RWS Nat en RWS Droog)
Provincies
Waterschappen
Gemeenten
Ministerie van Economische Zaken (Rijksdienst voor Ondernemend Nederland gewaspercelen)
De bronhoudergrenzen zijn grenzen van reële objecten (topografische vlakken). Een bronhoudergrens is dus altijd een lijn van 2 objecten van 2 bronhouders. Echter maar 1 van deze 2 bronhouders is verantwoordelijk voor het beheer van deze lijn. Dit wordt bepaald door de prioriteit of een onderlinge afspraak.
ProRail: dient als strokenbronhouder (dit is een bronhouder die landelijk werkt en waarvan het bronhoudersgebied dwars door andere bronhoudersgebieden loopt) haar BGT objecten en daarmee haar bronhoudersgrens als eerst aan de landelijke BGT tot te voegen, zodat andere bronhouders daarop aan kunnen sluiten. Echter ProRail is nog niet zover om vooruitlopend op andere bronhouders alle BGT objecten aan te leveren.
Maar om het aansluiten voor andere bronhouders mogelijk te maken gaat ProRail wel de bronhoudersgrens aanleveren. Deze bronhoudersgrens is gebaseerd op de eigen Basis Beheer Kaart (BBK) die ook als basis zal dienen voor de transitie naar de BGT. Andere bronhouders moeten in de transitiefase zonder meer aansluiten aan deze bronhoudersgrens. Een en ander conform de assemblageregels van het SVB-BGTr2].
Bronhoudersgrens van ProRail: De voorlopig definitieve bronhoudersgrens wordt bepaald op basis van objectgrenzen van de volgende objecten afkomstig van de BBK en de reeds aanwezige voorlopige bronhoudersgrensd3]:
Vlakobjecten (opdelend)
Bebouwing
Kunstwerk
Overweg
Terrein
Transport
Water
Verharding
Lijnobjecten (inrichtend)h4]
Geluidsscherm
Hekwerk
Muur
Beslisboom: op basis van vooraf gestelde criteria wordt de voorlopig definitieve bronhoudergrens (VDB) als volgt opgebouwd.
De voorlopige bronhoudersgrens (VB) is het uitgangspunt.
De VB ligt precies (exact=verschil 0) op de grens van vlakobjecten. De VB is correct en wordt VDB.
De grens van het vlakobject ligt binnen 60 cm 5] van de VB. De VB is niet correct. De VB wordt aangepast aan de ligging van de grens van het vlakobject en als VDB opgenomen.
Indien de VB "wegloopt" (dus meer dan 60 cm gaat afwijken) wordt het gedeelte dat binnen 60 cm ligt opgenomen als VDB. Het gedeelte dat buiten de 60 cm buffer valt wordt opgenomen als "VB wijkt te veel af". Dit gedeelte valt op door redlining of een andere markering.
De VB valt buiten 60 cm van de grens van het vlakobject. De VB is niet correct en wordt niet opgenomen als VDB. Het gedeelte dat buiten de 60 cm buffer valt wordt opgenomen als "VB wijkt te veel af". Dit gedeelte valt op door redlining of een andere markering.
De situaties 2 en 3 gelden ook als het niet om een grensvlak gaat, maar om een lijnobject.
De VB wordt in alle gevallen vergeleken met de dichtsbijzijnde vlakgrens.
Het gaat in alle gevallen om de vlakken op niveau 0. De brugdelen en ander kunstwerkdelen op andere niveau's worden buiten beschouwing gelaten.
Methode: Om de VB wordt een buffer van 60 cm berekend. De dichtsbijzijnde vlakgrens of lijnobject die binnen deze buffer van de VB valt wordt gebruikt om de VB naar toe te rekenen (d.w.z. dat de VB exact op die grens wordt uitgerekend en als VDB wordt opgenomen).
Het gedeelte wat buiten die 60 cm buffer valt wordt opgenomen als "VB wijkt te veel af". Dit gedeelte valt op door redlining of een andere markering.
Oplossen afwijkingen: daar waar de VB niet op een vlakgrens of lijnobject valt en buiten de 60 cm buffer valt (dus "VB wijkt te veel af") wordt de situatie visueel beoordeeld (bijv. op basis van logica of m.b.v. luchtfotointerpretatie). Handmatig wordt dan de bronhoudergrens alsnog op de juiste vlakgrens of lijnobject berekend en als VDB opgenomen.
1] BGT=Basisregistratie Grootschalige Topografie
g2] SVB-BGT=Samenwerkingsverband van Bronhouders van de BGT
p3] De vorlopie bronhoudersgrens is momenteel beschikbaar in TMT voor andere bronhouders
o4] Een lijnobject kan ook vlakvormend zijn als deze precies op een vlakgrens valt
E5] De 60 cm grens is een vooraf gesteld criterium
May be the spatialrelator has some bugs and doesnt not work properly. Or may be these spatial questions I cannot perform in FME finally.
Marco
Hi Gio,
I noticed that I made a mistake in my lattest posted workbench above. I linked the objects OVERWEG and TERREIN straight to the areabuilder.... I run the workbench again now...
Please can you explain me what the regular expression "(\\d),. " does exactly?
Hi Gio,
Here a pic to explain better (hopefully) what I needed.
regexp "(\\d),." gets the first digit from "(n,m)" in the pylogons attribute form the topologybuilder. (\\d = any digit and "." = any charactrer)
"Red line has to snap here" :
I filtered thes out because i tought that was wht you wanted. These objects are in the inspector "border_discard" if you need them.
Hi again,
The spatial queries needed to do the "beslisboom" is possible.
In fact i do saptial testing/validating and research for the Gemeente Leiden. A lot.
you just need to try and understand what transformers are neede and how to use them, mostly incombination with some ID, GUID, Keys, trnasformer output attributes, Objectnames or combinations of these.
Hi Gio,
Thank you for the regexp explanation. However, I discover this in the 'HELP' function already. My workbench above didnt work. Please, can you explain the 'incomplete' output of the Areabuilder. I read in the FME documentation that the 'not closed lines' are going out here. I try to understand why you create a buffer with offset from these 'incompleted'lines. Why not a linecloser transformer to recorrect these lines and connect these lines again to the TopologyBuilder? Which offset amount your used in the buffer transformer?
Hi,
And why you use at the neigborhoodfinder, the border polygon line as candidate? The criteria is that 'find all objects within the 60cm distance of the red polygon border line' (bronhoudersgrens Noord-Holland)? Same for the buffer, the distance of 60cm should be calculated from the red polygon border line, not the objects.
Hi Gio,
The stringsearcher and the tester followed by the stringsearcher ( _matched{0}_parts = 1) doesnt not always given the right results. It selects also the interior lines of objects, the objects that falls inside the red border polygon. See pict below.
I need only the object lines that falls on the border ("criteria 2 beslissingsboom").
Hi Gio,
I tried a lot of workbench configurations last days, but no satisfied results. The In range objects and the discard objects are not correct in my workbench. In think the Areabuilder I dont need at all. I have three original polygons readers to start with, the Terrein and Overweg objects and Noord-Holland objects. When I select out the Terrein objects and Overweg objects in LineOnArea overlayer, followed by a Tester (_overlap > 1) I dont get one feature Overweg not selected outside the boundary border. So I have to use the Tester (_overlap <= 1 or _overlap > 1) to select all object features of all provinces again. Do you know a other alternative to select the whole object of the Netherlands out to only Noord Holland? The clipper?
Hi Gio,
I still working on your workbench. In stead of flag or redlining the objects > 60cm, I need to mark the red polygons (Bronhoudersgrens) > 60 from the objects. I extend you workbench with the follow:
But still I dont get the results I want. See also the pic below:
the red line I need to mark as an exception, because its located > 60 cm from the surrounded objects. Do you have any idea? MAVA
Hi Gio,
I forgot the reader in the above workbench...