AssociatedStreet Relaties

Heren/Dames,

Is het gebruikelijk dat binnen 1 straat meer AssociatedStreet Relaties bestaan. Ik merkte op dat hij (de Plugin) bij het maken van de huisnummers voor iedere afzonderlijke straatsegment een relatie aanmaakt.

Kunnen jullie je ervaringen hierover delen?

Volgens de definitie “mag” er maar één “segment” in een associatedStreet relatie:
<http://wiki.openstreetmap.org/wiki/Relation:associatedStreet#Using_relations_to_associate_house_and_street_.28optional.29>

Er is een bijna identiek voorstel voor een street relatie waarbij wel meerdere “segmenten” in de relatie mogen:
<http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street>

Ik heb zelf zo mijn twijfels over de onderhoudbaarheid van de associatedStreet relatie. Als je toch met de plugin werkt, kost het geen extra moeite om de relatie aan te maken. Maar vooral de “eis” van maar één “segment” zorgt dat als wegen later gesplitst worden (voor routes, maxspeed, etc.) je een hoop extra werk hebt om van de ene relatie er meerdere te maken.

Mogen er echter meerdere “segmenten” in, zoals bij de street relatie, dan zie ik er het nut helemaal niet van in om dat in OSM te stoppen in Nederland. Dat kan een computer prima achteraf doen aan de hand van de straatnaam en de woonplaatsgrenzen. Waarom zouden we de menselijke editors daarmee lastigvallen?

Als ik lees waarom AssociatedStreet nodig is, is dat alleen om de straatnaam aan een huis te koppelen, dus in plaats van addr:street=* op elk huis te zetten. Ik snap dan niet waarom voor elk segment een aparte relatie nodig is. Ik zie juist voordelen om alle segmenten van dezelfde straat in een AssociatedStreet te stoppen, als de straatnaam aangepast wordt, hoef je minder te wijzigen. Tevens zou automatisch te detecteren zijn als je een segment vergeten bent aan te passen.

Ik stop gewoon meerdere straat-segmenten in een AssociatedStreet relatie. Dit doe ik vnl. met de Terracer-plugin in JOSM; zelf zou ik alleen een addr:street tag aan het huis(nummer) toevoegen… 1 segment per relatie is niet onderhoudbaar en in mijn ogen onzin. Wat als je een huizenblok hebt waar meerdere straatsegmenten voor langslopen, of een dubbele rijbaan? Ik vraag me af of er überhaupt applicaties zijn die hierover zeuren. Trouwens, door de AND-import hebben we in Nederland nog veel straten die uit verschillende segmenten bestaan.

Ja dat doe ik ook, maar als je twee huizenblokken behandeld en je selecteert voor ieder blok een apart srtaat segment, merk ik dan maakt de plugin een nieuwe relatie aan.

Is er een manier om te zorgen dat hij dat niet meer doet en gewoon een reeds bestaande relatie voor die straat gebruikt en het tweede blok dus toevoegt?

Dat doet de Terracer plugin inderdaad niet, maar maakt voor elke straat segment een nieuwe relatie aan (die wel dezelfde naam krijgt). Is dit ongewenst gedrag? Zo ja, zou de plugin zonder problemen gebouwen aan een relatie mogen toevoegen omdat die (misschien toevallig) dezelfde naam heeft?

Ja. Als je een AssociatedStreet relatie met de Terracer plugin hebt aangemaakt, kun je daarna zelf alle andere segmenten uit dezelfde straat aan de relatie toe te voegen (met de relatie-editor). Als je dan verder gaat met de Terracer plugin, zal hij alles aan dezelfde relatie toevoegen. Dat gaat gewoon goed :slight_smile:

Gaan we dat als gewenste omgang zien voor het aanmaken van AssociatedStreet Relaties?
Lijkt mij een uitstekend idee. En volgens mij is dan het splitsen van weggedeeltes in de toekomst ook direct ondervangen.

Heb hier geen JOSM maar kun je ook gewoon alle segmenten selecteren en het eerste huis om daarna de terracer plugin te starten? En voegt die dan alle segmenten in één relatie?

Ik heb gemerkt dat de Terracer plugin voor elk huizenblok een relatie maakt als je niet de straat waar die huizen aan liggen selecteert bij het starten, maar ‘handmatig’ de naam toevoegd. Ik had die functie in het begin nog niet gezien, daarom ben ik nu weer alle relaties aan het combineren.
Je kunt dat zo doen in JOSM:

  • Zoek op role:house child associatedStreet straatnaam. Alle huizen worden geselecteerd.
  • Maak een nieuwe relatie aan met de tags type=associatedStreet en name=straatnaam. Zet de geselecteerde huizen in de relatie. Type ‘house’ bij Apply role: en druk op de vink om de role toe te voegen.
  • Selecteer alle straatdelen en voeg die ook toe. Hierbij is de role ‘street’.

Even een oud topic van stal halen, wat is het nut van de associatedStreet relatie in relatie tot de BAG data waarmee een aantal mappers bezig zijn die op een of andere manier in OSM proberen te krijgen.
Is dit wel noodzakelijk als op ieder pand/adres ook al een tag is met addr:street addr:housenumber en addr:postcode?
Zie bv http://www.openstreetmap.org/browse/relation/2470020

Het invoeren van die data en de relaties koppelen aan de OSM wegen is nl dermate arbeidsintensief dat me dat voor heel Nederland onbegonnen werk lijkt (tenzij dit mogelijk is mbv een script?).

Het aanpassen van de straat naam is eenvoudiger zonder scripts te hoeven gebruiken om dit op alle gebouwen en aanverwante geadresseerde objecten toe te passen. Met het ophalen van de relatie heb je meteen alle objecten die aan die straat liggen, zonder relatie moet je iets van een Overpass query gebruiken om alle objecten die een bepaalde addr:street waarde hebben op te halen en vervolgens individueel te bewerken.

Zelf ben ik ook geen fan van de associatedStreet relaties omdat ze niet handig zijn bij het invoeren, en bewerk ik de BAG extract om het volledige adres in addr:* tags te zetten (dus inclusief street, city & country). In mijn ogen zijn de addr:* tags ideaal voor mappers die data invoeren, en de associatedStreet relaties zijn ideaal voor data consumers. Ik denk dan ook aan het (semi-)automatisch genereren van associatedStreet relaties op basis van de addr:* tags nadat deze zijn ingevoerd, om het leven van mappers in eerste plaats, en van data consumers op de tweede plaats te vermakkelijken.

Code als die achter de address view van OSMI zou gebruikt kunnen worden voor het genereren van de associatedStreet relaties. En is het bewijs dat de associatedStreet relaties niet per se nodig zijn om vast te stellen welke way bij een adres hoort.

Ik ben bij invoeren BAG ook tegen dit probleem aangelopen. Als ik wijk voor wijk wil invoeren loop je tegen het probleem aan dat sommige straten in die wijk doorlopen naar de volgende. Als je dan die ass.street relatie mee neemt neem je ook meteen de huizen in de andere wijk mee. Dat houd het niet overzichtelijk.

Ik ga maar eens proberen de ass.street relatie achter wege te laten en te kijken hoeveel sneller de invoer gaat. Zou me niet verbazen als het dan 5x zo snel gaat.

Nadat ik een kopie - paste actie heb gedaan, geef ik die data in de ruwe BAG datalaag (dus niet op de te uploaden OSM data) nog een extra tag kenmerk mee, bv upload=ligfietser.
Dan kan ik die data die ik al gehad heb er meteen uitfilteren.

Dat gaat zeker sneller, want dan wordt het bijna knippen en plakken.

Mijn probleem is dat ik met JOSM geen grote stukken kan uploaden (boven de pakweg 5000 objecten loopt die vast en wordt de changeset niet afgesloten) en zou ik dus eigenlijk een andere upload tool moeten hebben.

Ik vind de associated street-relatie niet handig. Het heeft geen toegevoegde waarde, maar levert extra overhead op. Zie o.a. mijn opmerking hierboven m.b.t. het moeten toevoegen van meerdere segmenten. In OSM is een straat vaak opgeknipt. Dat kan door de brondata komen (bijv. AND), maar ook omdat delen van een straat verschillende attributen hebben of meerdere eenrichtingsbanen hebben. De werkelijkheid is gewoon diverser en weerbarstiger dan waar het simpele model (1 way/weg, meerdere huisnummers) rekening mee houdt.

De overhead geldt ook voor consumers. Deze moeten nl. rekening houden met deze tag. Verder is er niets dat garandeert dat alle members in de buurt liggen. Mocht je alle gebouwen in een straat willen hebben, dan begin je sowieso met een dump van een bepaald gebied. Dan is het ook makkelijk om te querien op naam van de straat, in combinatie met een buffer of ruimtelijke intersectie met een administratief gebied, om zeker te zijn dat je alleen de gebouwen van woonplaats X te pakken hebt.

Toch wil ik pleiten voor het nut van de Associated street relatie.
Een straat is niet per definitie afhankelijk van een administratief gebied. Zie bijvoorbeeld de Putterweg tussen Putten en Ermelo (of andersom zoals je wilt).
Nu worden alleen de wegsecties en gebouwen in de relatie opgenomen. En je kunt je dan afvragen wat het nut is voor deze relatie.
Als we echter in deze “Mega relatie” nu ook eens alle andere objecten voegen die bij deze straat horen, dan gaat opeens een heel andere dementie spelen.
Ik denk bijvoorbeeld aan

  • Gebouwen met bijgebouwen waarvan het adres bij die straat hoort.
  • Vuilnisbakken
  • Rustbankjes
  • Parkeerplaatsen
  • Aparte nodes voor winkels en andere gebruikstoepassingen.

Wat je hiermee wint is dat je verzamelingen krijgt waarbij vrijwel ieder object zal moeten gaan horen.
En voortbordurend daaraan kun je ook Associated_Forest relaties krijgen.

Waar ik naartoe wil is dat Geo freaks als jullie extracties maken met een noodzakelijk hoog niveau van Geo technische kennis. Lees bijvoorbeeld de uitleg van Frank:

Dit had ook gekunt door in een tooltje de relatie van Putten en de relatie van de Putterweg te proppen en te vragen “Wat zijn de overeenkomstige objecten?”

Misschien haal ik hiermee de lol uit jullie werk als Geo-freaks, maar we zullen moeten streven naar een toegankelijker manier van opslaan van gegevens.

http://wiki.openstreetmap.org/wiki/Relations_are_not_categories

M.a.w. “Straatmeubilair langs de Putterweg” is geen goed idee voor een relatie.

Cartinus,

Het is mij al vaker opgevallen dat jij bijdragen aan dit forum altijd letterlijk neemt, weinig doordenkt over de betekenis van gedachten van anders denkenden en te snel je conclusies trekt. Hierna vliegens vlug de Wiki in duikt en iemand ongelijk naar boven haalt.
Sorry dat ik je dit zeg, het zit me al een tijdje dwars, ga daarom steeds minder in op discussies waar jij aan deel neemt.

Omdat ik sprak van “Ik denk bijvoorbeeld aan” zijn het dus niet alleen meubilair waar ik aan dacht, maar aan alle objecten die bij een straat horen.
he lijkt mij spacial technisch namelijk absoluut onmogelijk om alle objecten die bij een willekeurige straat horen via queries naar boven te halen, behalve als we dit verband via een speciale tag op die manier markeren. Dit werd in het genoemde artikel voorgesteld.

Ik wens je verder veel succes met je discussies.

Als jij met je zoveelste niet doordachte idee komt, waarvoor iemand anders al lang de tegenargumenten heeft bedacht, moet ik dan werkelijk iedere keer alle details uitlichten waarom het een ondoordacht idee is, i.p.v. gewoon te linken naar de bestaande argumentatie?

Tuurlijk is het handiger om bijbehorende objecten via een relatie op te vragen. Dat zal ik niet ontkennen. Waar het mij om gaat is dat het aanmaken en bijhouden van die relaties teveel werk is. Dit geldt zelfs als je dit geautomatiseerd voor de BAG-import wilt doen, omdat het een veel voorkomend issue dat straatnamen anders worden geschreven in verschillende systemen. Het heeft niets te maken met “de lol uit ons werk als Geo-freaks” te halen. Je moet gewoon de juiste afweging maken. Wellicht heb ik als “Geo-freak” daar een andere kijk op dan jij, maar ik wil het graag uitleggen.

Frank