Hallo wvdp,
In Openstreetmap volgen we de BAG-spelling van postcodes. Dit is zonder spatie, dus 2671JD i.p.v. 2671 JD.

Hello ndm,
Leeuwenstein (stylised as Leeuw&stein) isn't the name of a kitchen store, but the name of the entire shopping area. It was already in OSM: way/143470411.

I'll remove the incorrect node for the shop.

Sorry for starting in Dutch and thanks for adding stores from survey. This is always a good way to improve the map!

The problem with using the text from signs is that these are often logo's instead of names. So choices in font and design can be the reason for a stylised version of the name, e.g. without capitals or with strange letters. The actual name is with capitals.

Here is some extra information about abbrevation and capitalisation for names in OSM: osm.wiki/Names#Abbreviation_.28don.27t_do_it.29

It's better to remove them from the hospital area as there can be multiple addresses in one hospital area, e.g. for the hospital, for a doctors post, for a pharmacy, etc.

Hallo ndm,
Broos Keukens en Bo-Rent stonden al op de kaart.
node/1569643722
node/2596107024
Ik heb de dubbele winkels verwijderd.

Daarnaast schrijven we namen met hoofdletters.

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.