piebro/osm-data huggingface dataset:
mstock (2015-09-04 13:51:28+00:00): Hallo butl,
in diesem Changeset [1] sowie dem vorhergehenden [2] und einem spaeteren [3] Changeset hast du ein paar Wege geloescht. Mag sein, dass ich es dort mit dem Detailgrad etwas uebertrieben hatte, allerdings waren sie einerseits zusammen mit den Trottoirs und den Fussgaengerstreifen so gemacht, dass man Fussgaenger meiner Meinung nach korrekt routen kann, und andererseits waren sie zumindest teilweise Teil der Country-Skate-Relation [4], welche jetzt an drei Stellen kaputt ist, d.h. Luecken aufweist. Wenn moeglich waere ich daher froh, wenn du die Wege wiederherstellen und/oder zumindest die Relation korrekt reparieren koenntest.
Wie ich dem Changeset entnehme, hast du dafuer iD als Editor benuetzt - das ist ok, allerdings hat(te?) iD in Bezug auf Relationen gewisse Defizite - JOSM (ein anderer Editor) warnt jedenfalls, wenn man ein Mitglied einer Relation loeschen will, spaetestens dann sollte man es sich also nochmals ueberlegen, ob man das Objekt wirklich entfernen moechte ;) - ich weiss aber nicht, ob iD das auch macht, falls nicht, ist es sicher sinnvoll, dort sehr vorsichtig zu sein, wenn man etwas loescht.
Ganz abgesehen davon sind auch Changeset-Kommentare beim Abspeichern von Aenderungen noch gern gesehen, dort koennte man dann z.B. auch begruenden, wieso man etwas geloescht hat. 

Gruss
mstock

[1] #33439503, http://overpass-api.de/achavi/?changeset=33439503
[2] #33430646, http://overpass-api.de/achavi/?changeset=33430646
[3] #33481709, http://overpass-api.de/achavi/?changeset=33481709
[4] https://www.openstreetmap.org/relation/4084314
butl (2015-09-07 05:44:17+00:00): Hi mstock,

Danke für den Hinweis. Ich habe die Wege gelöscht, da sie vom Detaillierungsgrad meiner Meinung nach zu hoch waren. Wir können (und sollen) nicht jedes Trottoir auf der Karte einzeichnen, weshalb ich deine Wege rund um die Kreisel gelöscht habe. Dass diese Relation dabei kaputt geht, wollte ich nicht - Entschuldigung dafür. Wäre es für Dich ok, wenn wir die Trottoirs weglassen, die Skate-Route aber auf die neuen Begebenheiten anpassen (flicken)?

Das mit den Kommentaren werde ich mir zu Herzen nehmen.

Beste Grüsse
butl
mstock (2015-09-07 19:45:13+00:00): Hallo butl,

ja, das waere fuer mich grundsaetzlich durchaus ok, da die Relation momentan wirklich Luecken hat, was ich stoerender finde als die fehlenden Details an diesen drei "Kreuzungen". Reparierst du das, oder soll ich mich drum kuemmern? Dabei waere es sicher sinnvoll, wenigstens noch die 'sidewalk'-Tags [1] an den betroffenen Wegstuecken anzubringen, da diese sonst ebenfalls Luecken aufweisen, weil die angrenzenden Strassen mind. der Inline-Strecke entlang welche haben.
Trotzdem noch ein paar Worte zum Thema Detaillierungsgrad und die Gruende, wieso ich das so erfasst hatte:
* Auf [2] hat es Infos zur Erfassung von Inline-Routen in der Schweiz, und da steht sinngemaess, dass es noetig sein kann, dass man fuer die korrekte Modellierung Trottoirs zur Relation hinzufuegt. Daher habe ich das hier mal begonnen.
* Je mehr Details bei Strassen und Wegen erfasst sind, desto bessere/genauere Routen lassen sich errechnen. Fuer Autos und durchschnittliche Fussgaenger sind unsere Daten sicher meist schon recht gut, wobei man bei Fussgaengern das Routing meiner Meinung nach schon noch spuerbar verbessern kann, wenn auch Trottoirs, Fussgaengerstreifen, etc. erfasst sind - so koennte man z.B. vermeiden, dass man sie einer Hauptstrasse ohne Trottoir entlang schickt, nur weil sie der kuerzeste Weg ist. Abgesehen davon koennen die Daten natuerlich auch fuer das Routing von sehbehinderten oder blinden Fussgaengern oder von Rollstuhlfahrern verwendet werden - beide duerften durchaus von vielen Details profitieren, erstere z.B. von Informationen zum Vorhandensein taktiler Belaege [3], letztere z.B. auch von Informationen zur Beschaffenheit der Bordsteinkante [4]. 
* Ueber den richtigen Detaillierungsgrad herrscht sicher noch keine Einigkeit ;). Ich (und auch andere [5]) finde Trottoirs und so z.B. durchaus sinnvoll, und zwar fuer's Routing. Gerendert werden muessen sie deswegen nicht, das bringt dann wirklich nicht soo viel (meiner Meinung nach ;)). Bei den (momentan) ~474'002 Baeumen, die in der Schweiz erfasst sind, sehe ich den Nutzen auch nicht so, kann jetzt aber nicht behaupten, noch nie einen erfasst zu haben, und loeschen wuerde ich sie deswegen auch nicht ;). Beim Loeschen halte ich es grundsaetzlich so, dass ich nur Objekte loesche, die falsch oder ueberholt sind, d.h. die in der Realitaet nicht oder nicht mehr existieren. Falls ich auf etwas stossen sollte, das ich wirklich komisch oder problematisch finde, wuerde ich zuerst den Erfasser kontaktieren, und je nachdem auf der Mailingliste oder am Stammtisch das Thema mal ansprechen, um zu sehen, was andere davon halten.

Gruss
mstock

[1] http://wiki.openstreetmap.org/wiki/DE:Key:sidewalk
[2] http://wiki.openstreetmap.org/wiki/Switzerland/InlineNetwork#Inline_Skating_in_Switzerland
[3] http://wiki.openstreetmap.org/wiki/Key:tactile_paving
[4] http://wiki.openstreetmap.org/wiki/Key:kerb
[5] http://wiki.openstreetmap.org/wiki/Sidewalks
butl (2015-09-08 08:15:23+00:00): Hi

Alles klar. Ich würde mich sehr freuen, wenn Du die Relation reparieren könntest, da ich ehrlich gesagt nicht genau weiss, wie man das macht - Danke! Deine Meinung und Dein Vorgehen mit dem Löschen von Dingen finde ich sehr löblich und ich werde versuchen das in Zukunft auch so zu machen.

Gruss
mstock (2015-09-08 19:17:18+00:00): Hallo butl,

ok :). Ich hab's jetzt in Changeset #33890961 repariert. Damit sind die Luecken weg, und der Relation Analyzer [1] ist auch wieder zufrieden. Die Trottoirs habe ich jetzt einfach mittels 'sidewalk'-Tags an den Strassen erfasst, das ist nicht ganz so genau, aber wahrscheinlich auch nicht  falsch. Vielleicht frage ich am Stammtisch mal ein paar andere Mapper, wie sie solche Situationen erfassen (wuerden).
Bei iD wuesste ich uebrigens auch nicht, wie man Relationen bearbeitet, allerdings verwende ich den auch fast nie. Bei JOSM hat's aber auch recht lange gedauert, bis ich die erste Relation bewusst angefasst habe ;). 

Gruss
mstock

[1] http://ra.osmsurround.org/analyzeRelation?relationId=4084314&noCache=true&_noCache=on
andrewsh (2015-11-11 13:28:46+00:00): Hello wonchs91,

I'm not able to find anything in this area on any satellite images or on any other maps. Could you please explain where do the data come from?

Cheers,
Andrew
chillly (2015-08-21 21:12:46+00:00): You really need to take a look at how the change you have made is affecting stations. Please read http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element 
Then take a look at http://wiki.openstreetmap.org/wiki/Tag:railway=station
5m4u9 (2015-09-03 06:39:24+00:00): no perder el tiempo en dibujar las obras de arte. Por ahora sólo hacerlo si es un edificio, el resto es un punto.

A esto le llamamos... mapear para el render y no es la idea. Si se desea recrear en 3D hacerlo en 3D... diseccionando la figura cada 10cm y modelando por capas.
Yorvik Prestigitator (2015-08-21 16:11:38+00:00): Why does the Acomb Police Station need marking on the map a second time?
It is already adequately marked on the map by way 130352231
Locator (2015-08-21 22:25:56+00:00): In my mind from the Wiki I had it to tag the building outline and the node for the entrance. Tagging for the renderer is a cardinal sin, but maybe I got it wrong.
john86 (2015-08-24 13:05:04+00:00): Hi paul muster,
Du koenntest das Tagging hier noch verbessern, z.B. tourism=hotel hinzufuegen.
So allgmeine name="irgendwas"-Tags an allen moeglichen Objekten sind nicht so gut. MfG john86
Hjart (2015-08-19 18:02:45+00:00): According to danish convention all of these roads are actually considered residential, so I'll probably allow myself to revert this changeset
Hjart (2015-08-19 21:31:27+00:00): After conferring with the danish community I have decided to revert this.
geozeisig (2015-08-21 05:21:31+00:00): Sorry that I have not followed danish convention for all of these roads. In international comparison, they would certainly different values evaluated. 
But you were too fast with the revert, so I could not respond. Some new changes are lost.
Hjart (2015-08-21 05:50:20+00:00): I agree that maybe I should have given you more time to respond, but so many of my colleagues said "just revert", so I decided to do just that, rather than wait for your response. There were a few other changes which you may want to recreate.
I have mapped a bit for http://wiki.openstreetmap.org/wiki/Hot in various countries in which roads like these most certainly would be considered residential. So what you may be usually doing in your part of the world, isn't necessarily better or more correct than what we're doing in Denmark.
From now on please confer with the local community before reclassifying large numbers of roads like you did here.
Hjart (2015-08-21 05:55:18+00:00): The revert btw is https://www.openstreetmap.org/changeset/33450935
Hjart (2015-08-21 06:22:11+00:00): It seems that the landuse=residential polygon around Øster Lyng/Rørvig  somehow disappeared. Can't quite figure out how and when that happened though.
canfe (2023-05-08 06:31:04+00:00): Hai passato la SP 23 a SP723
Sui cartelli però si trova SP23
Ha davvero cambiato numerazione?
Gigillo83 (2023-05-08 06:49:13+00:00): Ciao. Sì, tutte le strade provinciali con numerazione che si sovrappone con la numerazione delle strade statali acquisite dalla regione, che poi le ha "devolute" alla CMTo, sono state rinumerate con un 7 davanti (nelle centinaia). Le strade in questione sono la 710, 711, 720, 720c1, 723, 724, 728, 729, 729dir1. Trovi comunque la numerazione ufficiale anche sullo stradario ufficiale della CMTo, nella sezione viabilità, stradario interattivo. Ciau!!
canfe (2023-05-09 14:30:34+00:00): Mi sa che allora bisognerebbe cambiare il ref per tutta la lunghezza della provinciale ed anche rivedere la relazione che la raggruppa.
Te la sentiresti dato che sei così informato?
Gigillo83 (2023-05-09 15:45:06+00:00): Se non sbaglio sono già indicati tutti i tratti della della strada come SP723 di Rivara...però magari mi sbaglio...
Ci sarebbe altro da fare?
canfe (2023-05-11 08:24:36+00:00): Mi pare che questo pezzo manchi
https://www.openstreetmap.org/way/327965879#map=16/45.2618/7.5815
Gigillo83 (2023-05-11 08:57:33+00:00): Sì, manca correttametne perchè quel pezzo, in comunione tra tra la SP22 e la SP723, è ufficialmente classificato solo come SP22...la chilometrica della SP723 si interrompe a Ponte Masino e riprende (seppure considerando anche i km della SP22)  al bivio in corrispondenza della Green Farm...
albjorgui (2016-11-08 16:42:17+00:00): Me pregunto si las plazas de aparcamiento dibujadas en las esquinas de los edificios deberian eliminarse. No se podrian considerar como informacion de aparcamiento que ya existe para cada una de las calles? Por esa misma norma, todas las calles deberian tener los aparcamientos senyalizados y no los tienen.
Alecs01 (2016-11-10 19:28:19+00:00): Hola albjorgui, entiendo lo que dices, es un "unicum" en la ciudad. Si quieres puedes borrarlas y remplazarlas con ese tag en los trazos de calles que corresponden http://wiki.openstreetmap.org/wiki/ES:Key:parking:lane , no tengo nada en contra. Saludos
chillly (2015-08-21 16:49:47+00:00): Adding the second track is OK, but you have duplicated the stations. There is only one Ferriby station (for example), yet there are two station nodes. We only add each real-world object once into OSM.
mweper (2015-08-19 20:52:45+00:00): Hola pollux_ar. Te corregí las etiquetas de ciclovías como cycleway=lane para evitar duplicar vías en la misma posición.

Más info: http://wiki.openstreetmap.org/wiki/Key:cycleway
gileri (2015-08-19 17:46:20+00:00): Bravo pour la réactivité !
cquest (2015-08-20 07:46:53+00:00): Bonjour,

Ce mini import est intéressant mais a besoin de quelques améliorations:
- les heures d'ouverture en tag opening_hours ne sont pas conformes au format attendu.
- le tag name devrait plutôt se limiter à "Copy-Top" et mettre le nom complet en official_name... vous aurez ainsi plus de chance que le nom apparaissent sur les fond de carte car si il est trop nom il a plus de chance de ne pas être affiché.
- les tags addr:* sont à remplacer par contact:* car lorsque l'adresse existe déjà (cas sur Paris par exemple) on se retrouve avec un doublons. addr:* doit être utilisé pour mapper la position officielle de l'adresse, contact:* sert à indiquer à quelle adresse un point d'intérêt est lié.

Vous pouvez venir en discuter sur http://forum.openstreetmap.fr/
gileri (2015-08-20 09:03:07+00:00): @cquest : Il me semble que les horaires ont toutes été corrigées dans ce changeset, c'est pas le cas ?

Pourquoi limiter le nom à la chaîne ? Le nom du magasin est le nom déjà taggué à priori. 
L'affichage sur la carte principale ne devrait pas pousser à mettre un nom incomplet juste pour que le POI soit affiché !

Pour ces problématiques de longueur de nom et d'appartenance à une chaîne, il y a les tags dédiés short_name et brand=*.
cquest (2015-08-20 15:15:45+00:00): J'ai effectivement corrigé les horaires.

Pour le nom, c'est une question d'usage.
Les noms composés reprenant la localisation sont une pratique interne de chaînes (l'import a été fait semble-t-il par quelqu'un de copytop), mais pas l'habitude pour la majorité des usagers. D'ailleurs, sur l'enseigne on n'a bien que "Copytop" et pas "Copytop Flandres Europe", tout comme sur les agences bancaires on met habituellement "Crédit Lyonnais" et pas le nom complet de l'agence.
COPY-TOP (2015-08-20 16:10:20+00:00): Bonjour, Merci pour votre aide à tous.
J'ai effectivement revu les horaires cf. les conseils reçus. J'espère que c'est ok... Pour le nom des agences, la chaîne a plusieurs agences parfois très proches l'une de l'autre (par ex. 4 dans le même arrondissement de Paris ou 2 dans la même ville de province). Pour le client, c'est important de pouvoir les différencier surtout qu'en général, il n'en fréquente pas qu'une seule (beaucoup de clients multi-boutiques).
gileri (2015-08-21 10:43:48+00:00): Totalement d'accord avec COPY-TOP pour les noms.

En reprenant l'exemple du Crédit Lyonnais, les noms des agences sont bien présentés aux clients : http://agence.lcl.fr/98498-lcl-cormeilles-en-parisis

C'est également le cas pour McDonald's par exemple : https://www.restaurants.mcdonalds.fr/mcdonalds-paris-hotel-de-ville

Ikea : http://www.ikea.com/fr/fr/store/evry/

La plupart des chaines appellent leur magasin de cette manière, et ces noms sont présentés au public.
Commodoortje (2017-03-10 11:00:14+00:00): Hallo Ad,

Mijn oog viel op je toevoegingen 
natural=peak in deze omgeving.
Sommige zijn als 1m boven NAP getagd.
Kun je uitleggen wat aan deze hoogtes belangrijk is?
Ik zie dat je ze als monumentaal hebt aangemerkt, dit zou de reden kunnen zijn, maar om nu van een "bergtop" te spreken in deze vorm in Nederland vind ik (persoonlijk) wat overdreven.
Alvast dank voor je reactie.
AdVerburg (2017-03-10 11:24:04+00:00): Het gaat hier over een als historisch object. Om die historische data op te hangen heb je "ding" nodig.  Omdat het een opvallend object in het landschap is (veel voorkomend in Zeeland, en vergelijkbaar met terp in Friesland) heb ik voor "peak" gekozen.
Een andere aanpak zou gedaan kunnen worden met man_made=embankment.
Met vriendelijke groeten, Ad
Commodoortje (2017-03-10 11:50:43+00:00): Dank je voor je uitleg.
Persoonlijk vind ik dat man_made=embankment een betere tagging zou zijn. Bij bergtoppen denk ik meer aan Zwitserland of de Posbank en Vaals als het Nederlandse toppen zijn.
Van mij hoef je het niet aan te passen, dit was niet de insteek van deze reactie.
Grillo (2015-08-20 12:00:10+00:00): Hoppsan, mappade byggnader här med...
zors1843 (2015-08-20 06:10:27+00:00): Heeft dat stukje weg zeker een naam ?
Faecon (2015-08-20 06:30:57+00:00): Aangepast. Heeft geen naam denk ik
zors1843 (2015-08-20 06:47:02+00:00): Hartelijk dank
emacsen (2015-08-23 10:59:49+00:00): What is the source of the name of this object?
Gazer75 (2015-08-21 10:39:30+00:00): Why did you change this? This road is an E route road and thus should be trunk. All E routes and national highways in Norway will always be trunk or higher class.
MKnight (2015-09-04 11:40:20+00:00): kannst Du die Öffnungszeit für Sa bitte noch korrigieren?
uryevich (2015-10-05 09:32:51+00:00): Вадим, Вы перепутали пешеходную улицу с пешеходной дорожкой (тротуаром). Пешеходные улицы предназначены исключительно для пешеходов - например Арбат. 
Я исправил
uryevich (2015-10-05 09:41:50+00:00): Прошу прощения, highway=pedestrian поставили не Вы.
yamada-as (2015-08-21 21:09:27+00:00): Hi, Could I ask you why removed bi-lang name?

May you didn't know about discussion running here http://forum.openstreetmap.org/viewtopic.php?pid=525130
numide (2015-08-22 01:48:26+00:00): You guys from jijel are obsessed with arabic, wake up,m you are not arabs ands stop fighjting, i use tag:ar, tag:fr, ang name for latin names....u better write names in algerian arabic....the re is no bilingual names,
Gazer75 (2015-08-21 11:07:34+00:00): Please revert the road class changes. They are wrong. E route and national highways in Norway are trunk class.
literan (2015-08-20 13:09:02+00:00): да, вот кстати: адрес на магазинах и т.п. указывать необязательно (это лишняя работа) - все программы умеют брать адреску из полигона дома, на котором эти точки находятся.
marcioaguiar (2015-08-20 15:00:59+00:00): Boa, abacate! Só recomendo colocar o nome na formatação adequada, sem ser tudo maiúsculo!

Valeu!
changchun_1 (2015-09-01 13:21:38+00:00): Hallo Volle221, bei der Adresseingabe Daten bitte vollständig eingeben. z.B addr:city=Mundelsheim
addr:country=DE
addr:housenumber=2
addr:postcode=74395
addr:street=Lange Straße

Danke Gruß Matthias
changchun_1 (2015-09-01 13:13:30+00:00): Hallo Volle221, bitte beim Ändern der Karte in das Kommentarfeld eintragen was du gemacht hast.
Gruß Matthias
user_599436 (2015-08-19 21:26:18+00:00): Comment should have been "add missing name tag to Kennebec River".
Syl (2022-05-27 14:04:19+00:00): Bonjour, cela maintenant près de 7 ans, est-ce qu'on peut nettoyer ?
Hjart (2015-08-19 22:28:13+00:00): Denne revertering er sket efter konferering med folk dels på IRC og dels på den danske postliste
Hjart (2015-08-21 14:35:28+00:00): Polygoner må ikke overlappe eller krydse sig selv, så i tilfælde som her hvor der er en lille ø i en lidt sø, bruges en såkaldt multipolygon: http://wiki.openstreetmap.org/wiki/Multipolygon
Viajero Perdido (2016-03-10 05:23:59+00:00): When you delete 1600+ ways in a single changeset, how can you possibly know some of those ways haven't been HAND-EDITED, and would be of higher accuracy than the decades-old government data you're replacing them with.

It looks like you've deleted a number by user Menne71, and a sampling of his changesets would be in order.  Of the few I glanced at, they're unattributed, but could well have been the product of hard volunteer labour.

And I'm missing some river changesets of my own, Fiddle River / Sulphur Creek in this area.

Please stop!
trapicki (2022-09-24 11:38:01+00:00): Dieser Pfad ist im Bachbett eingezeichnet. Als Wanderweg (highway=path) scheint er mir nicht aktiv zu sein. Wir dieser Trail noch aktiv befahren?
GRUBERND (2022-09-25 19:25:22+00:00): Ja. Das Bachbett führt nur bei starkem Regen Wasser, sonst ist es (oberirdisch) ausgetrocknet.
SomeoneElse (2020-11-14 18:12:24+00:00): Hello Sunfishtommy

I hope you don't mind me asking about something added to OpenStreetMap 5 years ago(!).  https://www.openstreetmap.org/node/3705799856/history was added with a "source=Google Maps" tag on it. We can't actually use that as a source in OSM because the Google's licence doesn't allow it to be used here. If it's somewhere that you've actually been and are familiar with then "local_knowledge" is a perfectly good source for OSM.

If not, then we'll have to remove Google-sourced things that you've added to OSM.

Best Regards,

Andy Townsend, from OSM's Data Working Group.
SomeoneElse (2020-11-14 18:12:53+00:00): 590 / 5000
Translation results
Hola Sunfishtommy

Espero que no le importe que le pregunte sobre algo que se agregó a OpenStreetMap hace 5 años (!). https://www.openstreetmap.org/node/3705799856/history se agregó con una etiqueta "source = Google Maps". En realidad, no podemos usar eso como fuente en OSM porque la licencia de Google no permite que se use aquí. Si se encuentra en algún lugar con el que ha estado y está familiarizado, entonces "local_knowledge" es una fuente perfectamente buena para OSM.

De lo contrario, tendremos que eliminar los elementos de Google que haya agregado a OSM.

Atentamente,

Andy Townsend, del Grupo de trabajo de datos de OSM.
Sunfishtommy (2020-11-14 21:13:57+00:00): Hello Andy, a little blast from the past. 😅 
Yea this was back when I was brand new and didn't know better. 

There is good and bad news, but luckily mostly good.

So the good news is the only “google” stuff is the town names, the rest was from bing aerial imagery in JOSM. So the only things that will need to be removed are town names. 

The second good news is
The names of the towns in Mexico are from http://gaia.inegi.org.mx/mdm6/
Which is open source and should meet the OSM License requirements. 

The bad news though is the Guatemala town names i added back then are from google though and will probably need to be removed unless another source can be found. 

The last piece of good news is there should only be a couple dozen towns like this and they are all contained to this area in the south eastern corner of Chiapas and just across the border in Guatemala luckily somebody noticed and informed me of my mistake pretty early on so I stopped early and I did my best to correct it.

What would be the best way to move forward?  If you would like I can go through and delete the names on the Guatemala Side of the border that I added.

I do want to emphasize that the only questionable things in these change sets are the town names, everything else I 100% stand behind as being correctly added in accordance with the OSM's rules. (ie. tracing off of aerial imagery in JOSM)
Sunfishtommy (2020-11-14 21:20:54+00:00): I think I found the change-set with most if not all of the problem names.

https://www.openstreetmap.org/changeset/33561867#map=10/16.0239/-90.7693
Sunfishtommy (2020-11-14 21:28:12+00:00): Here are the terms of use for the Mexican town names data.

http://en.www.inegi.org.mx/inegi/terminos.html
Sunfishtommy (2020-11-15 00:43:23+00:00): I went ahead and reverted the change set

https://www.openstreetmap.org/changeset/33561867#map=10/16.0239/-90.7693
SomeoneElse (2020-11-15 01:56:21+00:00): Hello,
Thanks for that - I'll pick up the redaction later.
Best Regards,
Andy
Sunfishtommy (2020-11-15 04:18:20+00:00): Here is my revert change set i completed a few hours ago where i got rid of the town names just so you have it.

https://www.openstreetmap.org/changeset/94126317
5m4u9 (2015-08-20 05:55:21+00:00): en los cambios de la semana hay un error recurrente... layer=X. Layer se utiliza para indica que algo esta en el aire, al nivel del suelo o debajo del suelo.

Si quieres indicar que una construcción tiene 2,3,4,5 pisos debes añadir building:levels=XX..
gorogoro (2015-08-21 02:34:45+00:00): Era por tratar de subsanar los muchos mensajes de advertencia de JOSM; como por ejemplo edificio sobre edificio. Es verdad que no corresponde layer, empezare a corregir con levels.
5m4u9 (2015-08-21 04:27:36+00:00): No hagas mucho caso a JOSM y sus validaciones. Esta bien tenerlo para que controle equivocaciones por cansancio del que edita.... pero siempre usa el sentido común y la wiki en la duda. por último consulta... puedes hacerlo en irc en el canal #osm-latam desde https://webchat.oftc.net/ en cualquier momento.
5m4u9 (2015-08-21 04:30:00+00:00): Ah y me olvidaba... layer=1 si es posible usar cuando se trata de techo, en nuestro caso serían los tingaldos... building=roof + layer=1.
5m4u9 (2015-09-03 06:44:30+00:00): diferenciar fuentes de estanques. Las fuentes son nodos, los estanques un área.

Las aceras de los parques también son aceras normales de calle. highway=footway + surface=concrete o material específico.