Hello Verdizulo,
Esperanto is not an official language of the European Union. Besides it's spoken by only a select group of people. Hence the name-tag and wikipedia-tag should be kept in either English (most understood language and largest wikipedia articles) or French (second language for diplomatic traffic).

It seems that the wikipedia-tags of at least some continents also have been changed from English (largest articles) to Esperanto. However these were not reverted in this changeset.

Hello Lessig,
In the Netherlands we tag addresses on nodes, as they are defined this way in the buildings and addresses database (BAG) of the government.

So the node node/4763555244 shouldn't be removed.

Bedankt! Ik had het al op lcn gezet, omdat er geen omleiding mogelijk is die geen fouten in Knooppuntnet oplevert. Maar ik had het inderdaad ook uit het netwerk moeten verwijderen.

De informatie staat nogal verspreid op de wiki. Bijvoorbeeld bij place=neighbourhood, type=boundary, landuse=residential en key:place.

Ik kan wel een relatie aanmaken op de echte grenzen. Het probleem was vooral dat de naam op een landuse=residential stond i.p.v. op een place=quarter/neighbourhood, terwijl het wel de naam van een wijk/buurt was.

Hallo emvee,
Op de zoomniveau's waar de landuse=residential niet meer te zien is, maar slechts de witte achtergrond, is de schuingedrukte naam verdwenen. Dus de schuingedrukte naam komt inderdaad van de landuse.

Hier zie je trouwens ook het nadeel van de landuse=residential als buurtgrens gebruiken. Delen die geen onderdeel van het woongebied, maar wel van de buurt, worden nu gezien als geen onderdeel van de buurt. Dit is bijvoorbeeld te zien bij de Reyerdijk en groengebieden rondom de buurt.

De place-tag mag wel op een area staan, maar dan moet het daarnaast dubbelgetagd worden op een node, omdat de meeste datagebruikers place-area's niet ondersteunen.

Een betere manier is dus om de grenzen als grens in te tekenen. Je geeft een gemeentegrens ook niet met een vlak aan.

Schuingedrukte namen komen van landuse=*, niet van place=*. De issue is afgewezen omdat beide pull requests om het op te lossen zijn afgewezen, dus het is niet opgelost. Het probleem was hoe dubbeltagging te voorkomen.

Nu is de beste manier om wijkgrenzen aan te geven door deze gewoon als grenzen te taggen. De label-rol wordt dan toegekend aan de place-node. Uiteindelijk maken de grenzen voor de rendering op OSM-carto niets uit, maar kan ze wel zien op osm.org:
relation/8617154

Deze issue (https://github.com/gravitystorm/openstreetmap-carto/issues/103) is afgewezen. OSM-carto rendert dus geen place-tags op vlakken.

Plaatsen worden in ieder geval op een node getagd. Dit wordt al vanaf van begin van OSM gedaan, omdat plaatsen vaak niet duidelijk gedefinieerd zijn. Daarom renderen veel kaarten het ook niet op een vlak.

Door het te taggen met een place-node als label van een place-relatie maak je het mogelijk dat de renderer kan kiezen.

In het geval van Hordijkerveld is de rechtopstaande naam de juiste. Dit is namelijk Hordijkerveld als buurt. De schuingedrukte is fout. Dat is Hordijkerveld als gebied waar huizen staan. Een vlak met landuse=residential hoort in principe geen naam te hebben.

Een voorbeeld van een place-relatie: relation/8617154

De plaatsnaam moet in ieder geval op een place-node worden getagd om gerenderd te worden op kaart als wijk of buurt. Dit wordt soms omzeild (zoals hier was gedaan en ik nog nu steeds zie) er dan ook maar een landuse=residential van te maken. Echter wordt het dan niet als wijk maar als naam van het woongebied gerenderd. Daarnaast kan een wijk ook bijv. uit parken en winkelgebieden bestaan. De grens van de landuse=residential is dus niet gelijk aan de grens van de wijk.

Eventueel kun je een relatie aanmaken met de grenzen en de place-node met de rol 'label' toevoegen aan die relatie.

Thanks!

Multiple concerns about the iD-editor are voiced. The main concern is that they ignore the community when they have another opinion.

You shouldn't remove tags that are still used for compatibility. You don't have to add them to new embassies, but the removal is against OSM good practices. You can add both the old and the new scheme on the same node, as these tags don't use the same key.

Hello,
Thanks for adding extra information to this embassy.
However you deleted the tag amenity=embassy which is still used by maps like OSM-carto. So please keep that tag for compatibility.
Besides you changed phone to contact:phone. Even contact=* tells that the 'simple' tags should be used for common tags like website, email and phone.

Ik heb de route omgelegd. 15 december rijdt deze weer door de Zonweg en Melkwegstraat.

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.