Problemen met associatedStreet in JOSM

Die associatedStreet relaties kun je negeren. Die gebruiken we eigenlijk niet in Nederland. Deze lijken acht jaar geleden te zijn toegevoegd, maar ze zijn hier niet nodig. Het is een methode waarmee je huizen aan straten kan koppelen. Bij deze twee relaties in Wageningen zijn er geen huizen aan de straten gekoppeld trouwens. Ik heb ze weggegooid.

In JOSM gaat het meestal wel goed met relaties als je een weg opknipt (zeker sinds deze fix). Wel is het belangrijk dat je dan alle data in de omgeving gedownload hebt. Dus via Download in current view of Download data en dan een gebied selecteren (geen idee hoe dat in de Nederlandse vertaling heet). Als je wegen gedownload hebt via een Overpass API query, dan mis je soms de relaties die aan een weg hangen namelijk.

Je kan bij route-relaties zoals fiets- en wandelroutes, en buslijnen altijd even kijken of de relatie nog een doorlopende route vormt in JOSM’s relatie-editor na het splitsen.

Ik had die lege associateStreets op meerdere plekken aangetroffen. Zodra ze leeg zijn (en er dus alleen wegen in zitten en geen huizen) kan ik ze dus verwijderen als ik het goed begrijp.

De enige manier die ik ken om data te downloaden in JOSM is het volgende venster. Hoe zou je data dan via Overpass kunnen downloaden?

Hoe kan ik in de relatie editor zien of een route compleet is?

Heb je links onderaan in de Preferences de expert mode aangevinkt?

Er hoort namelijk een tweede tab te zijn naast Downloaden van OSM met Download from Overpass API

In de route editor zie je rechts een routelijntje Dat moet aansluitend zijn als de relatie heel is

Je kunt ook de plugin Continuous Download installeren. Dan wordt automatisch alles voor je gedownload.
Ik gebruik hem al jaren naar tevredenheid.
Wel eraan denken dat je je gebied niet te groot kiest, dan loop je uit je geheugen

Ja, zonder huizen zijn ze sowieso zinloos. Je kan eens kijken of ze altijd door dezelfde gebruiker zijn aangemaakt.

Binnen Nederland zijn adressen indirect aan straten gekoppeld via de naam. Dus addr:street komt bijna altijd op een of meerdere wegdelen in de buurt van het adres voor, in een van de name-tags. Meestal zal dat name zijn, maar soms ook short_name, official_name, of zelfs name:left of name:right. Wanneer een addr:street niet voorkomt als naam op een straat, dan heb je te maken met een niet gemapte straat, of met een naam die op een ander benoemd stuk openbare ruimte slaat, zoals een gehuchtsnaam (hoewel die meestal ook als pseudostraatnaam in gebruik zijn).

Buiten Nederland kunnen andere gebruiken gelden in hoe er gemapt wordt natuurlijk, dus wees daar terughoudender.

Zou je mss even kunnen uitleggen hoe ik die relation geschiedenis kan opzoeken? Ik heb in JOSM wel het geschiendisvenster gevonden maar daar zie ik alleen tag en point geschiedenis, geen relations.

Gevonden, bedankt voor de tip. Kan nog wel eens goed van pas komen die Overpass API

Op onderstaande screenshot zie je wel enkele pijltjes, bedoel je die?

Ja, die pijltjes vormen het routelijntje en die zijn aaneengesloten.
Als je nu links onderaan op dat half verborgen knopje klikt, worden de members, die nu op incomplete staan ook ingeladen

History relations:
In de relatielijst of het tabvenster de relatie selecteren.
Dan in het selectievenster op de knop History drukken

Yes, dat werkt. Bedankt

De relaties zijn inderdaad steeds door de zelfde (helicase) aangemaakt maar wel al in 2012.

Betekenen die rode elementen trouwens dat ze zijn verwijderd door de gene in die 2e versie die rechts geselecteerd staat?

Ja, dat klopt.
Dat is vermoedelijk bij een BAG import gedaan, gezien het account met _BAG

Begrepen, bedankt voor je hulp. Nu begrijp ik JOSM weer een stuk beter.

Momenteel bestaan er 91 associatedStreet relaties in Nederland: https://taginfo.geofabrik.de/europe/netherlands/tags/type=associatedStreet
Ik vond een antieke forumdiscussie uit 2010-2012 waarin deze relaties al besproken werden: https://forum.openstreetmap.org/viewtopic.php?id=8480
Als we er sinds die tijd maar 91 hebben, mag ik dan aannemen dat we deze informatie overbodig/onhandig vinden en mag ik deze dan ook uit Nederland verwijderen?

Met de BAG import is dit uitvoerig aan de orde geweest, of het nut van de toen bestaande associatedStreet relaties nog te laten bestaan.
Tijdens de BAG import werden namelijk (bijna) alle adressen geïmporteerd, en leek het nut te verwaarlozen.
Er is destijds overeengekomen dat de associated street relaties verwijderd worden.

Daarom zijn er (vermoedelijk) nu nog maar 91 over in Nederland, die misschien vergeten zijn.

https://wiki.openstreetmap.org/wiki/BAGimport

The associated street relation will not be used because it is too difficult for newbies.

In dat geval:

https://www.openstreetmap.org/changeset/113905812

Sorry voor de grote bbox.

Dat er weinig van die relaties zijn kan verschillende redenen hebben, bijvoorbeeld omdat door niet altijd even doordachte opruimwoede in OSM weleens data vrij ongemerkt verdwijnt.

En daarnaast betekent dat een tags / relaties weinig wordt gebruikt op zich nog niet dat deze verwijdert moet/mag worden. In een samenwerkingsproject is respectvol omgaan met elkaars bijdragen een belangrijke randvoorwaarde.

Zie ook: https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_remove_tags_that_you_don.27t_understand

In dit geval is er misschien vanuit BAG-perspectief weinig behoefte om de adressen op deze manier te koppelen, maar er zijn ook andere invalshoeken waarom wegdelen in een relatie worden gekoppeld, zie bijvoorbeeld de waterway-relaties.

Bij de verwijdering zijn zo te zien niet alle relaties apart bekeken: er zijn ook recente relaties verwijderd die een ander doel hebben (zoals het groeperen van wegdelen bij een pad waar er verwarring was over de naam van een pad zelf en een gelijknamige routerelatie die ook paden met een andere naam als lid heeft).

Ik heb de verwijdering daarom teruggedraaid (hoewel ik denk dat voor dat laatste voorbeeld een gewone street-relatie beter past dan de associatedStreet). Groet.

Hoi multimodaal,

Sorry dat ik jouw associatedStreet relaties verwijderd had, in mijn opruimwoede had ik er geen rekening mee gehouden dat die nog in gebruik waren.

Ik heb nog niet helemaal begrepen hoe je die relatie gebruikt. Heb je een link naar een voorbeeld?

Hoi, dank voor je reactie. Die is een concreet voorbeeld waar ik naar verwees in mijn vorige post: https://www.openstreetmap.org/relation/11741204 (zie de note)
Dat leverde in de praktijk verwarring op met de gelijknamige routerelatie in het veld: https://www.openstreetmap.org/relation/11734685

Mappers gingen daar ways die zelf helemaal niet “Let de Stigterpad” heten toch zo noemen omdat ze tot die route-relatie behoren (is ook wel bijzonder, zo’n straat met onderbrekeningen, achtergrond is dat dit pad specifieke is gemaakt om aantal missende schakels in te vullen voor fietstocht over de lengte van de zuidelijke Utrechtse Heuvelrug). De waarde in [name] is dus niet altijd een goede koppelsleutel. Met deze relaties kan je in 1 blik het verschil expliciet maken tussen de wegdelen die Let de Stigterpad heten en de bredere groep wegdelen die behoren tot de route “Let de Stigterpad”

Er zijn ook nog andere toepassingen van zo’n street-relatie buiten het koppelen van woningen, in lijn met https://wiki.openstreetmap.org/wiki/Relation:waterway

Zo zijn er bijvoorbeeld boerenlandpaden die je doorgaans als “1 pad” zal zien (van de ene kant van het weiland naar de andere kant van het weiland), maar die in OSM uit 20 ways bestaan vanwege een groot aantal bruggetjes. In een street-relatie kan je die koppelen.

Dat geeft (a) makkelijk inzicht in de vraag wat precies tot dat pad behoort (b) mogelijkheden voor checks op tagging: hebben alle wegdelen die dezelfde access-tags zouden moeten hebben die ook (ben vaak genoeg een kort bruggetje vergeten te selecteren met inconsistente tags tot gevolg) en (c) een makkelijke mogelijkheid voor renderers om gelijke namen maar 1x weer te geven ipv elke keer opnieuw op elk kort wegdeel (dat is te verkeizen boven het verwijderen van namen dat ook gebeurt vanwege ongewenste rendering…)

En in een nieuwe voorgestelde uitbreiding van de street-relatie wordt naast koppelen *in de lengte van de weg * ook aandacht gegeven aan koppelen *in de breedte *van de weg:
https://wiki.openstreetmap.org/wiki/Proposed_features/Relation:street

Zo kan je rijbanen (en gescheiden rijbanen) en bijbehorende fietspaden, voetpaden en ruiterpaden aan elkaar relateren. Die relaties zijn relevant, bijvoorbeeld als validatie voor de tagging van zaken als oneway en toegang voor fietsers / voetgangers / ruiters op de rijbaan. En ook dat geeft kansen om renderers te helpen bij omgang met dubbele namen (naam van weg zowel op beide rijbanen, parallel fietspaden en voetpaden…)

Zonder meer weggooien van (associated)Street-relaties lijtk me dus niet goed, maar aan de andere kant waardeer ik de pogingen tot unificatie van verschillende tags die hetzelfde weergeven in je andere activiteiten en snap ik ook dat in gevallen waar er een goed lopend proces is waar veel mensen aan meewerken (de BAG-import) dat het ook fijn is als daar gemaakt afspraken worden nageleefd en niet elke keer opnieuw ter discussie komen.

Misschien is het een optie om (per stuk ; -) te kijken of de huidige associatedStreet-relaties kunnen worden omgezet naar street-relaties? Dan zijn we van die eerste af in lijn met de eerdere wensen uit het BAG-proces, maar wordt de informatie niet weggegooid en blijft er ruimte voor andere toepassingen?

Groet!

Ik vind de claim dat alle wegdelen genaamd Let de Stigterpad samen één straat zouden vormen dubieus. Het zijn minstens twee verschillende straten in twee verschillende gemeenten die bovendien meer dan 2 kilometer uit elkaar liggen. Het enige verband is dat ze dezelfde straatnaam hebben. Behalve deze gemeenschappelijke straatnaam staan er ook geen enkele tags op de street-relatie (behalve een note).

Het probleem met verwarde mappers is beter op te lossen door op de route-relatie een duidelijke note over de straatnamen te plaatsen, daar is geen tweede relatie voor nodig.

Betreffende de andere redenen. (a) Wat tot een pad behoort, kun je prima met een query op straatnaam binnen de woonplaats doen - kun je in je query ook zelf kiezen wat je als één straat ziet en wat als verschillende straten. (b) Check op tagging kan ook met een dergelijke query en/of door opeenvolgende ways automatisch te selecteren (Shift+W in JOSM). (c) Als een renderer wil programmeren dat de naam van gelijknamige ways bij elkaar in de buurt niet telkens herhaald wordt, dan kan de renderer uitstekend zelf zoeken wat de gelijknamige ways bij elkaar in de buurt zijn. Dit is taggen voor een hypothetische toekomstige renderer terwijl de hypothetische toekomstige renderer de tagging helemaal niet nodig heeft.

Street-relaties lijken mij een leuke theoretische exercitie maar zeer onpraktisch om toe te passen en met zeer veel onnodig dubbel invoerwerk tot gevolg. Waterway-relaties lijken meer op route-relaties dan op street-relaties, in die zin dat ze een abstractieniveau hoger liggen dan het lokale stukje water en bijvoorbeeld ook een andere naam kunnen hebben, vergelijkbaar met de route-relatie Let de Stigterpad.

Is er naast het Let de Stigterpad (wat nu een type=street relatie is) nog een andere associatedStreet-relatie die nog een doel dient? Als dat niet zo is heb ik namelijk opnieuw een sterke neiging om op de grote verwijder-knop te drukken voor deze in onbruik geraakte relaties.

Ik zou wel even nakijken of er tags op de street-relaties staan, en of die tags in plaats daarvan op de ways kunnen worden geplaatst.

Dat het Let de Stigterpad een bijzonder gebakje is waar je op verschillende manieren naar kunt kijken en een verschillende oordeel over kunt hebben is wel duidelijk.
Maar er is wel een zekere ruimtelijke relatie tussen de wegdelen.
Dat wegdelen in twee gemeenten liggen is -even los van de bijzonderheden van dit specifieke geval- nog geen reden om ze niet in een street-relatie te verbinden, integendeel: het op voorhand afbakenen op gemeente/woonplaats-niveau werkt misschien goed voor BAG-objecten maar niet voor paden die woonplaats- of gemeentegrenzen kruisen

Als je bekend bent met de achtergrond en situatie ter plekke dan zal je weten dat dat niet klopt.
Het verband tussen deze wegen volgt niet zozeer uit de gedeelde naam, de gedeelde naam volgt uit het verband dat deze wegen met elkaar hebben. Een weg met dezelfde naam in een andere gemeente dan deze twee heeft dit verband niet.

Relaties gaan niet alleen over tags maar -de naam zegt het al- over een bepaalde samenhang tussen objecten dei in de relatie wordt vastgelegd en eventueel gespecificeerd in de role

Ik weet niet zo goed wat dat zou oplossen. In de praktijk zie je dat namen worden helemaal verdwijnen of worden gewijzigd ook als er een note of iets als een source:name staat op het element zelf (en dan blijft die note over de bron van de naam vaak wel staan.) Het lijkt me erg sterk dat een note op een van de relaties waar een way lid van is daar iets voor gaat oplossen, als verwarde mappers al niet de notes op het way lezen dat ze zelf wijzigen, waarom zouden we verwachten dat ze de notes lezen op alle *relaties *waar een way lid van is?

Samenhangende objecten kunnen woonplaatsen kruisen en omgekeerd kan een straatnaam ook niet uniek zijn binnen een woonplaats (zien op twee verschillende objecten binnen de plaats, niet zozeer bij straatnamen in de BAG, maar wel bij bijvoorbeeld onverharde paden in het buitengebied die -anders dan het Let de Stigterpad- niets geen samenhang met elkaar delen behalve hun naam.

Bij een ruimtelijke query moet je vooraf al weten hoe het element samenhangende element begrensd is in de ruimte (door bijvoorbeeld een woonplaats of gemeente te specifiëren of een bounding box, een relatie geeft een mapper gelegenheid om juist zijn interpretatie van de situatie vast te leggen.

Daarnaast is name ook regelmatig vaak een instabiele koppelsleutel. Als je naar de ontwikkeling van tags op elementen en de consistentie tussen elementen kijkt, dan zie je dat namen -zeker bij wegen waar geen / nauwelijks woningen aan verbonden zijn- kunnen verschillen over de lengte van een weg en over de tijd. Dat heeft meerdere achtergronden.
-Dat begint al bij verschillen in spelling door (a) fouten en (b) afwijkende regels voor spelling van straatnamen in OSM vergeleken met plaatselijke aanduidingen / andere bronnen.
-Daarnaast is er lang niet altijd één eenduidige naam, er kunnen verschillen zijn tussen de naam van een pad op het geplaatste bord, de BAG/BRT , BGT, NWB, de wegenlegger
-En daarbovenop verdwijnen namen soms ook omdat sommige mappers de naam niet vinden passen binnen de name-key en kan in OSM de lokaal bekende naam zelfs boven de aangegeven naam gaan

Shift-W is leuk maar gaat maar tot de volgende fork. Naast zijwegen kan een weg ook verspringen bij een kruising. En belangrijker: JOSM weet niet welke onderdelen wel en niet tot het object horen (waar begint en eindigt het), een mapper kan dat in een relatie vastleggen op basis van zijn interpretatie van de situatie.

De praktijk is dat er renderers zijn die gebruik maken van street-relaties (niet alleen hypothetisch dus) en dat onze grootste renderer identieke namen dubbel weergeeft en dat mappers om die reden name-tags verwijderen van korte ways of parallele ways. En ook al zouden er geen renderers zijn die nu street-relaties gebruiken dan is dat ook geen argument: je moet ergens beginnen want als een bepaalde datasoort niet of nauwelijks in OSM staat, gaan renderers die ook iet snel gebruiken (kip-ei).

Als je jezelf hebt overtuigd dat street-relaties onnodig zijn, dan is al het werk dat met die relaties is dat natuurlijk ook, dat is een beetje een cirkelredenering. Maar het is eerder omgekeerd: met maken van een street-relatie kost inderdaad iets meer moeite dan het simpelweg verwijderen van gegevens, maar als het een beetje moeite kost, dan is het ook aannemelijk dan de mapper die dat doet er wel een bepaald nut in ziet.

In een samenwerkingsproject is het vruchtbaarder om nieuwsgierigheid te tonen naar de wereld om je heen en het werk van medemappers -en de mogelijkheid open te laten dat je misschien niet alles weet- dan om het werk van anderen op voorhand als nutteloos te bestempelen.

Ook bij wegen kunnen namen op meerdere niveau’s bestaan en net zo goed als bij waterways kunnen street-relaties worden gebruikt om er voor te zorgen dat we 1 OSM-element (de relatie) voor 1 feature hebben.