Zover ik weet lieten we de verplichte volgorde vallen, wanneer deze onlogisch is. Bijvoorbeeld bij routes die maar in één richting lopen (van hoog naar laag). Ook kunnen de ways in de verkeerde volgorde komen, doordat een weg wordt gesplitst in een relatie met maar 1 weg.

Het willekeurig kiezen van de volgorde, lijkt me een slecht idee, want:
1) Het opzoeken van relaties in een relatielijst wordt lastiger. Bijvoorbeeld wanneer je een groot gebied in JOSM hebt gedownload en in het relatievenster kijkt. Dit doe ik wel vaak.
2) We hebben net voor elkaar gekregen om ref-tags te gebruiken zodat er mooie lijsten in Waymarkedtrails komen. Ook hier moet je nu twee keer zoeken naar een route, in mijn voorbeeld bij de 9 en de 63.
3) Het ziet er slordig uit om twee systemen (laag-hoog en hoog-laag) willekeurig door elkaar te gebruiken.

Ik kan de busroute eventueel omleggen via de omleidingsroute.

Dat stukje weg was door iemand anders op construction gezet, omdat het afgesloten is tot december.

Hallo Peter,

Zou je in de ref/note-tags nog wel de knooppunten van laag naar hoog kunnen zetten, dus 09-63 i.p.v. 63-09. Zo zijn routes sneller in een lijst te vinden. Je hoeft dan niet bij zowel 9 als 63 te zoeken.

Volgens de gemeente hebben deze wijken wel namen, naast nummers:
- Bomenwijk-Groenswaard
- Vondelwijk-Oranjewijk
- Zuid-Oost
- Zuidplas-Triangel
Zie: https://wijkplatformwaddinxveen.nl/

Het nadeel van alleen deze vier als wijk taggen en de rest als buurt, is dat bijvoorbeeld Park Triangel een buurt wordt. De onderverdelingen van die buurt (Parkzoom, De Rietkraag, etc.) zijn dan ook buurt, waardoor de hiërarchie verdwijnt. Juist die hiërarchie is de reden voor verschillende tags place=quarter en place=neighbourhood.

Er zijn dus twee mogelijkheden:
- Alles wat nu als place=quarter is getagd zo houden.
- Vier nieuwe place-nodes aanmaken voor de wijken met place=quarter en dan de niet-wijken aanpassen naar place=neighbourhood. Hiermee neem je het verlies van hiërarchie in Park Triangel voor lief.

Als je quarter naar neighbourhood wil veranderen, moet je overigens zowel de grensrelatie (relation/10301481) als de place-node (node/6615189316), zodat de data consistent blijft.

Misschien dat er onduidelijk is, door de slechte en inconsistente vertalingen op osm.org (Nominatim) en de editors iD en JOSM. Voor Nederland geldt:
- place=suburb: stadsdeel
- place=quarter: wijk
- place=neighbourhood: buurt

In Waddinxveen wordt buurt (dus place=neighbourhood) gebruikt voor onderdelen van wijken, zoals Groenswaard II en De Rietkraag in Park Triangel.

Bedankt! Misschien wordt de naam verder in de toekomst nog wel een keer aangepast.

Hallo TekkoTaks,

De wijken van Waddinxveen zijn getagd als wijk (place=quarter). Waarom zet je deze om naar buurt (place=neighbourhood)?

Hallo Dave009,

Volgens de gemeente Hoekse Waard heet de sporthal nog steeds Sporthal Cromstrijen, ook al bestaat Cromstrijen niet meer als gemeente.

https://www.gemeentehw.nl/inwoner-bezoeker/sporthallen-en-zalen_47771/

The admin_level is correct. Level 2 is used for the entire sovereign country (Kingdom of the Netherlands), level 3 is used for the constituent countries (Netherlands, Aruba, Curaçao, Sint Maarten). So this is the relation of a constituent country and therefore level 3.

boundary=administrative#11_admin_level_values_for_specific_countries

Dat maakt niet uit. Openstreetmap is nogal ingewikkeld in het begin.

Ik heb het grotendeels hersteld. Op verschillende plekken waren zijpaden niet meer op de weg aangesloten, waardoor op OSM gebaseerde navigatie niet meer de weg op kon steken.

Hallo DenvemMaps,

Je voegt hier enkele stoepen, toe als aparte ways, zoals deze:(way/743579789. Als er geen fysieke scheiding is, maar slechts een stoeprand, dan geven we een stoep aan met de tag sidewalk=left/right/both op de naastgelegen weg, bijvoorbeeld zo: way/27823840. Alleen daadwerkelijk fysiek gescheiden stoepen, zoals bij de Laan van Tolkien, mappen we als aparte ways.

Hallo leonard461341,

Goed dat je de hotelgegevens naar de BAG-node verplaatst! Je had echter ook het bouwjaar van het gebouw (start_date=1994) verplaatst. Die heb ik teruggezet, omdat dat informatie is over het gebouw.

Als het hotel ook in 1994 is gestart, dan kan die tag natuurlijk ook aan het hotel (de node) worden toegevoegd.

Als iets in de praktijk dubbel staat aangegeven, hoeven wij dat niet te doen. Een afslagbeperking is niet gelijk aan een verkeersbord. Er kan bijvoorbeeld ook een afslagbeperking zijn bij een dubbele streep of juist geen afslagbeperking bij een eenrichtingsweg, busbaan, etc.

Het keerverbod wordt in principe alleen gebruikt door navigatiesystemen als er meerdere ways zijn, bijvoorbeeld bij een middenberm. Je zou namelijk ook midden op een wegvak kunnen keren, waar nooit een afslagbeperking zou worden toegevoegd.

Je kan natuurlijk altijd informatie dubbel toevoegen, maar andere mappers zullen het dan misschien later weer verwijderen, omdat het de kaart nodeloos ingewikkeld maakt.

Hallo Gekke Henkie,

Afslagbeperkingen hoeven alleen toegevoegd te worden, als deze beperking niet uit de bestaande data af te leiden is.

In dit geval is de busbaan getagd als verboden voor ander verkeer dan bussen. OSM geeft dus al aan dat ander verkeer niet af mag slaan en de afslagbeperking is overbodig.

Hallo Dirk,

Nog een tip om het correct te krijgen. De buitenste weg (met de rol 'outer' in de multipolygon) heeft nog de tag building=yes. Als je die verwijderd, klopt het.

Bij deze wijziging wordt het Fietsroutenetwerk Leiestreek West-Vlaanderen omgezet in een gebouw. Ik heb dit hersteld.

Hier wordt een weg aangepast van tertiary naar primary. Het is echter geen primaire weg (grofweg provinciale wegen onder de N400). We taggen wegen aan de hand van de ligging in het netwerk, niet de uitbouwstatus, behalve bij autowegen en autosnelwegen. Dat dit een 80-km-weg is kun je aangeven met maxspeed=80.