The multipolyons are rendered the same. For more information, see:
http://area.jochentopf.com/

De way leek nog goed te liggen, waarschijnlijk waren alleen non-boundary objecten aan de boundaries geknoopt. Voor de zekerheid heb ik het segment geupdate m.b.v. de officiele geometrie.

De name tag voor de woonplaatsgrens relatie is gecorrigeerd.

Deze grenscorrectie wordt pas actief op 1 januari 2018, zie:

http://home.kpn.nl/pagklein/gemhis.html#g2018

Thanks for breaking the administrative boundaries on the Dutch side of the border with your premature change. The border correction between Vise and Eijsden becomes affective on January 1st 2017.

Bergen heet "Bergen L" in de BAG, dat is zodoende de officiele naam.

De gemeente moet de naam aanpassen in de BAG als ze van L af willen.

Afferden heet "Afferden L" in de BAG, dat is zodoende de officiele naam.

De gemeente moet de naam aanpassen in de BAG als ze van L af willen.

Het misbruiken van de addr: tags is geen acceptabele oplossing. Zeker omdat een onjuiste addr:city waarde gebruikt wordt.

Probeersels kan je beter eerst bespreken op het forum:

https://forum.openstreetmap.org/viewforum.php?id=12

De admin_level=10 relatie is voor de Woonplaats Wassenaar, de admin_level=8 relatie is voor Gemeente Wassenaar.

Gelieve van de administratieve grenzen af te blijven, zeker als je de betreffende documentatie niet gelezen hebt.

The Spanish consulate (not embassy) is at Federiksplein 34, at number 51 there is no mention of any diplomatic activity.

Any idea whose embassy it is?

De BAG krijgt zijn data van de bronhouder, die zich weer baseerd op de bouwtekeningen uit het vergunningsproces (ook bij verbouwingen).

De inners hebben een glazenplafond gekregen, maar zijn een open ruimte in de gebouw footprint.

M.i. is de BAG juist, en jij te overijverig met aanpassen. Zeker gezien het prominente karakter van deze panden.

Ik vind het bijzonder treurig dat een BAG overlay op OSM nu niet meer overeenkomt. Helaas is iedereen in staat OSM aan te passen hun eigen inzicht, juist of niet, dus laat ik het hierbij.

Heb je meer informatie over de niet meer bestaande inners?

Op de satellietbeelden zijn ze nog te zien waardoor ik twijfel aan de juistheid van deze edit.

Company is not a valid key for tags.

> Thank's for destroying the boundary DE/NL!

Thanks for your constructive feedback. Your passive aggressive stance is very motivating.

> Can you tell why you did this?

Because I maintain the administrative boundaries of the Netherlands using the official government open data.

Every month they release a new dataset of which I incorporate the administrative boundary changes into OpenStreetMap. If you'd have checked my contribution history you would see that.

But then you don't come over as someone who investigates an issue before shouting at others.

> The boundary was defined by the most precise informations, and you changed
> it without checking or asking into something. What source did you use?

I don't need permission of anyone to update the Dutch administrative boundaries. I'm very capable of doing that myself.

> If possible, revert the changes ASAP.

Why didn't you describe the problem that has arisen since I've updated the boundaries. What has exactly broken?

Did you connect non-boundary objects to the boundary perhaps, that are now mis-formed due to moved nodes?

I'm not going to revert my changes, and if someone else does I will revert those changes. If my boundary changes broke something I'll fix that, but so far I've not heard anything concrete, just some German shouting at his fellow mappers who clearly isn't aware of common courtesy to his peers, nor to common guidelines incorporated in the Code of Conduct draft.

Can you please change your attitude to a constructive approach so we can fix any issues that may have arisen?

Shouting at people will not make them want to help you.

This changeset is wrong, confusing settlement (woonplaats) and municipality (gemeente) Rotterdam.

admin_level=8 is only appropriate for the municipality Rotterdam for which relation/324431 already exists:

relation/324431

The wikipedia tag shouldn't have been removed either, it was correct for the city of Rotterdam.

This changeset has been reverted in changeset/30450412:

changeset/30450412

Met deze changeset zijn de woonplaatsgrenzen van Schiphol en Badhoevedorp gesloopt, gelieve beter op boundary=administrative ways & relations te letten in het vervolg. Deze dienen los te staan van andere objecten in OSM.

boundary_type=state is inappropriate for Dutch provinces. I've removed the tag from the Dutch boundaries in changeset/27595897.

border_type=province may be appropriate for Dutch provinces, but admin_level=4 already indicates that.

The boudary_type tag should never be used, use border_type instead if you must tag additional distinctions between boundaries with the same admin_level.

For now there is no use for the border_type tag in the Kingdom of the Netherlands.

The wikipedia tags for Amsterdam the settlement (admin_level 10) and Amsterdam the municipality (admin_level 8) were correct, so I've reverted back to the correct wikipedia tags.

You can verify the the two wikipedia articles via the wikidata links.

The wikipedia tags for Amsterdam the settlement (admin_level 10) and Amsterdam the municipality (admin_level 8) were correct, so I've reverted back to the correct wikipedia tags.

You can verify the the two wikipedia articles via the wikidata links.