Hallo Ninjoh,
Dit is wel de correcte manier. We hebben in Nederland afgesproken om aparte adresnodes te gebruiken ipv adressen op gebouwen te taggen. Een winkel heeft een adres en dat werkt alleen goed samen als de winkel op het adres staat. Daarnaast gaan de tags op het gebouw over het gebouw en niet over wat erin zit. Bij een winkel gestart in 2013 in een gebouw uit 1982 krijgt het gebouw start_date=1982 en de winkel start_date=2013.

Ik heb het idee dat er vooral winkels/bedrijven op gebouwen zijn getagd uit onwetendheid over afspraken, omdat het makkelijker te taggen is of omdat het al voor de BAG-import getagd is op 3dShapes-polygonen toen er nog geen adresnodes waren.

Het is wel eens besproken op het forum dat POI's op adresnodes horen, niet op gebouwen. Dat omtaggen kan mijns inziens beter zo snel mogelijk gebeuren, want anders wordt er steeds meer bedrijfsinformatie op gebouwen getagd en is het meer werk om het correct te taggen.

footway=sidewalk geeft vooral aan dat het een vrijliggende stoep is die parallel aan een weg loopt, in tegenstelling tot een voetpad zonder naastgelegen weg.

Ik had de footway=sidewalk gezien, maar het gaat erom dat er een constante uitwisselingsmogelijkheid is (een stoeprand) en geen fysieke afscheiding. Ik dat geval mappen we het als een enkele way met sidewalk=left. Het is nu getekend als een vrijliggende stoep, zonder uitwisselingsmogelijkheid met het fietspad, wat niet overeen komt met de werkelijkheid.

Ik heb de weg omgezet naar highway=proposed:
way/703059858

Hallo SCNC,
Je voegt hier een vrijliggend voetpad toe naast het fietspad van de Noorderdreef.

Een stoep (gescheiden door stoeprand of markering) wordt aangegeven met de tag sidewalk=left/right/both op de way van de naastgelegen weg. Een vrijliggende stoep (gescheiden door bijv. een berm) wordt aangegeven met een aparte way met de tag highway=footway, footway=sidewalk.

In dit geval is de correcte manier dus sidewalk=left/right/both op het fietspad.

Je hebt hier een deel kanoroute verwijderd. Was dat de bedoeling?

Als de weg al in aanleg is, dan is het overigens highway=construction, construction=living_street i.p.v. proposed.

Bedankt voor het toevoegen van deze nieuwe weg.

Een toekomstige weg kun je intekenen met highway=proposed, proposed=living_street. Je hebt de weg nu ingetekend als een weg die al open is. Daarnaast is de name-tag niet bedoeld voor omschrijvingen, maar alleen voor de daadwerkelijke naam. In dit geval is dat dus name=Hendrikseiland, zonder 'toekomstig'.

Graag gedaan! En jij bedankt voor het wijzen op de opening van deze weg via een oude wijziging van mij.

Dit fietspad is trouwens tijdelijk. Er komt een grote boogbrug voor fietsers over de A2 net ten zuiden van de aansluiting.

Ik ben vandaag door Rijswijk-Buiten gefietst. De bordjes zijn daar al aangepast naar de nieuwe situatie. Bij knooppunt 82 wordt naar de nieuwe knooppunten verwezen en in Rijswijk-Buiten ben ik geen enkel bordje van de oude zuidelijke route 46-82 tegengekomen. Ik heb de lcn-route (dat was 46-82) daarom verwijderd.

Hallo Ladung,
In deze wijziging verwijder je informatie over de beveiliging van treinrails. Dit was correct getagd. Waarom heb je deze informatie verwijderd?

Bedankt voor de snelle verbetering!

Bedankt voor het toevoegen van de bedrijven!

Let wel op dat je bedrijven aan de adresnode toevoegt i.p.v. aan het gebouw. Op het gebouw zetten we dingen die met het gebouw zelf te maken hebben zoals bouwjaar, aantal verdiepingen, etc. Op het adres komt het bedrijf/winkel dat in het gebouw zit.

Ik heb hier Makita Nederland aangepast: node/2730020687

Bedankt voor je waardevolle toevoegingen in Delfgauw!

Je maakt hier wel een kleine fout. Je voegt namelijk adressen toe aan de gebouwen. In Nederland zetten we de adressen op aparte nodes (punten) i.p.v. op het gebouw, omdat een gebouw meerdere adressen kan bevatten. Dit is ook de manier hoe adressen zijn gedefinieerd in de officiële BAG-registratie.

- Een adresnode (bevat het adres en eventueel een POI zoals een winkel of bedrijf): node/2628406284

- Een gebouw (hoort zonder adres): way/257250590

Blijkbaar voegt iD automatisch layer=-1 toe als je een tunnel toevoegt. Ik heb die tag verwijderd omdat hij niet nodig is.

In principe is een tunnel ondergronds, dus er ligt grond boven de tunnel. Een tunnel is ook een ander soort constructie dan een viaduct. Het heeft niet per se te maken met de lengte-breedte-verhouding. Hier is al wel eens over gediscussieerd, want de grens is soms vaag.

Ik heb er covered=yes van gemaakt. Tunnel/covered lijkt er in ieder geval voor te zorgen dat het busperron boven de weg wordt gerenderd. man_made=bridge wordt overal onder gerenderd, maar dat is bekend.

covered=yes zou dus beter zijn dan tunnel=yes, omdat het geen tunnel is.

Ik zie dat je een tweede poging hebt gedaan. De correcte tag zou covered=yes zijn i.p.v. tunnel=yes. Het is namelijk geen tunnel maar een breed viaduct.

Verder is de layer=-1-tag ook niet nodig, omdat het default (layer=0) al onder de layer=1 van het viaduct ligt.

Het aquaduct bij de Vecht is als tunnel getagd. Dit is een breed viaduct, geen tunnel. Eventueel kun je een stukje snelweg met covered=yes taggen. Dan ziet dat er ook als tunnel uit.

Maar ook bij dat aquaduct zie je dat de weg met een lichtere kleur boven het water wordt gerenderd.

De snelweg is layer=0 (default, dus niet taggen). Het viaduct, de wegen op het viaduct en het busperron hebben layer=1. 1 is meer dan 0, dus het viaduct ligt boven de snelweg. layer=-1 is niet nodig. Deze tags zijn alleen bedoeld om de onderlinge hoogteligging aan te geven, niet ten opzichte van maaiveld.

De renderingsproblemen (ook bijv. op de standaardkaart) hebben niets met de layer-tags te maken, maar met hoe de volgorde van de rendering werkt. Daarbij worden wegen boven viaducten en perrons getekend, ongeacht de layer-tag. Het probleem ligt dus bij de renderer, niet bij de OSM-database.