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
Robert, kijk hier eens: http://webhelp.esri.com/arcgisserver/9.3/java/geodatabases/spatial_operations.htm. Let vooral op Buffering en Intersection.
Frank
Tuurlijk kan het wel. Als blijkt dat een object dicht bij 2 of meer straten ligt, bepaal je welke straat de kortste afstand heeft tot het object. En tja, als het object op een hoek staat en de afstand naar 2 straten is gelijk, dan boeit het sowieso niet of het bij straat X of Y hoort.
Je kunt veel meer oplossen met spatial queries dan je denkt 
En het zorgt ervoor dat je geen redundante informatie, zoals associated street relations, hoeft bij te houden, met risico op inconsistente / foutieve data. Puur de lokatie zegt al genoeg.
Als ik in mijn werk gedachtes van anderen niet begrijp en onlogisch en soms dom lijken, ga ik er van uit dat ik zelf misschien niet zo ver heb door gedacht. Jij gaat direct uit van het negatieve van de ander.
Er als je dan zo’n vreselijke held bent in het maken van extracties en volledig achter het artikel staat die je zo triomfantelijk hebt gepresenteerd, daag ik je uit om de volgende extractie te maken:
Geef mij een lijst van alle objecten die behoren tot de Postweg in Putten.
Wedje leggen dat je:
- of afhaakt en niet meer reageert
- Verder gaat met mij te bestrijden en de uitdaging niet aandurft
- Het toch gaat proberen en, omdat het niet lukt, het resultaat niet terugmeld.
Ik ben benieuwd.
En als het je wel lukt, zal ik de eerste zijn om jouw gelijk hier te bevestigen.
Frank,
Dank je voor je wijze antwoord, daar kunnen mensen een voorbeeld aan nemen. Ik snap je antwoord en ik heb zelfs getracht de stukken te lezen over buffering en intersecties. Wel moet ik toegeven dat ik het diepe er niet van begrepen heb. Wel begrijp ik je verhaal hierboven.
Toch zijn er een paar dingen die te weinig belicht zijn.
Als eerste is er bij mij nog niet bekend dat er een gebruikersvriendelijke en geschikt voor niet Goefreaks (en dat bedoel ik niet negatief) tool is waar ‘de wereld’ vragen zoals ik aan Cartinus heb gesteld kan beantwoorden. Dat betekend dat de waarde van OSM nooit verder zal kunnen gaan dragen dan de plaatjes makende hobbyisten of de Developers die wel weten hoe ze Spacialqueries moeten bouwen. Toch zijn er hele veel doelgroepen die niet zoveel kennis hebben en toch gebruik willen maken van de OSM kennis.
Als tweede is mij altijd verteld dat OSM vrij was om gegevens in op te slaan, ongeacht de wensen van de developer of de plaatjesmakers. Vanwaar dan deze toch bijna dwingende artikelen waarmee Cartinus komt. Lijkt tegenstrijdig.
@all: Mijn excuses voor de vervuiling van mijn replys aan Cartinus. Tijdens onze eerste ontmoeting in Utrecht jaren geleden is er kennelijk iets misgegaan, ergeren we ons aan elkaar en ben ik bang dat het nooit meer goed gaat komen. 
Dus vergeef mij.
Al deze problemen zouden er niet zijn als we straten als gebied zouden mappen in plaats van als lijnelement. Als vervolgens alle aanliggende percelen aan de straat worden gekoppeld heb je hetzelfde bereikt zonder gebruik te maken van extra relaties.
Hoe kan ik een discussie “winnen”? Laat ik de andere partij een opdracht geven die zoveel tijd kost, dat geen zinnig mens hem zal uitvoeren alleen om z’n gelijk in de discussie te halen.
Nodig om de taak uit te voeren:
- met behulp van luchtfoto’s, bestaande 3dShapes import en verkenningen te voet alle perceelsgrenzen en erftoegangen in kaart brengen. (Lijkt me meer een taak voor ZMWandelaar, aangezien hij daar in de buurt woont.)
- data downloaden
- extract importeren in een database
- queries schrijven
Dat laatste ga ik zoals je inderdaad al aangegeven had natuurlijk niet voor je doen, maar als je er echt in geïnteresseerd bent: Lees eens wat over ST_within (om bijgebouwen en percelen aan een gebouw met een adres te koppelen) en “nearest neighbor” (voor het straatmeubilair) op het internet.
En nu zijn we aangeland bij de crux van het probleem. Dat lezen. Ja, dat lezen. Dat is namelijk wat je meestal niet gedaan hebt, voordat je weer met een “nieuw” idee komt. En wat je meestal ook niet echt doet als anderen op je idee reageren. Dat doe je zelfs niet de enkele keer dat je om advies vraagt, dan lees je de reacties ook maar half. Dat lijkt inderdaad wel wat op die ontmoeting tijdens de mapping party in Utrecht. Veel praten, weinig luisteren was het toen. De irritatie is echter volledig te danken aan dat niet lezen.
V.w.b. gebruiksvriendelijke tools: Tom McWright en Alex Barth van MapBox gaan zich hierop richten. Zie http://mapbox.com/blog/kicking-off-knight-work/. Uiteindelijk zullen de zaken die jij noemt door mensen met een geo-achtergrond opgepakt worden. Niemand zal ontkennen dat het voor de argeloze gebruiker te zware kost is. Waar je wel mee moet uitkijken is om allerlei ideeën te verzinnen en keihard te verdedigen die op een andere manier beter op te lossen zijn. Daar maak je geen vrienden mee. Het is je vast opgevallen dat OSM een zeer sterke geo-component heeft, dus dan ligt het ook voor hand om voor bepaalde zaken oplossingen uit de geo-wereld aan te dragen. In die zin is “spatial” nog steeds “special”.