piebro/osm-data huggingface dataset:
aseerel4c26 (2016-11-17 20:33:29+00:00): Let me cite the code of conduct: "use of find-and-replace functionality using a standard editor such as JOSM or finding using services such as Overpass API and changing without reviewing cases individually;"

Precision: I doubt that. That would not explain several objects having a loss of precision. One more http://osm.mapki.com/history/node.php?id=284249395  Yes, that loss may be acceptable, but this should be discussed and the cause found.

I would have many more questions (input list of objects, verifying that you found the right wikidata object, what about other osm objects which have been tagged with the same wikidata ID) about your algorithm. But that discussion should happen before your edit...

Please do not do further edits and start the required discussion now. E.g. in a mailing list or forum. Please mention the link here.

Of course, I appreciate your effort for improving OSM, but it should be done a bit differently.
LogicalViolinist (2016-11-17 20:35:59+00:00): But i'm not using an API, nor find and replace so what's your point?
LogicalViolinist (2016-11-17 20:36:52+00:00): also what algorithm please see the steps above.
LogicalViolinist (2016-11-17 20:39:32+00:00): Why does a offline edit have to be discussed? Do you have to email a mailing list when you edit a road, a building, a tree?
aseerel4c26 (2016-11-17 20:39:50+00:00): yes, if you would add them manually (e.g. while editing that place node anyway) no one would ask. The thing is: errors happen with automated edits. More eyes spot possible errors better than one person only.   You may not have thought of all possible cases which are existing in the data. Automated edits touch many objects, which were hand-edited before - we want to do the best possible to not accidentally destroy other people's work, don't we?
aseerel4c26 (2016-11-17 20:46:06+00:00): algorithm: okay, you mentioned "offline". So you did extract all nodes with a place tag from "mapbox QA-tiles" and then look up manually (pressing ctrl+C and so one) each name? Then you looked at the wikidata result and verified that it is the correct city (and not a equally named county or other city) and added the tag to the object? And now you are doing a batch upload of all that?
LogicalViolinist (2016-11-17 20:46:17+00:00): Do you understand English? These. Are. Not. Automated. Edits.
LogicalViolinist (2016-11-17 20:51:20+00:00): Qa tiles was to obtain node ids thats it. Everything else in josm
LogicalViolinist (2016-11-17 20:53:11+00:00): If you are scared of poor data, kindly point out a wikidata tag that is wrong
aseerel4c26 (2016-11-17 21:42:11+00:00): No, I will not look through the wikidata tags. Too hard to verify them one by one. 

If those are not automated edits ... wow!  I would automate that! :-)

I have asked for comments at https://forum.openstreetmap.org/viewforum.php?id=10
aseerel4c26 (2016-11-17 21:42:39+00:00): oops, this deeper URL: https://forum.openstreetmap.org/viewtopic.php?id=56436
LogicalViolinist (2016-11-17 21:44:09+00:00): Well I am aware that the German populous dislikes imports
woodpeck (2016-11-18 21:08:04+00:00): I am appalled that after thoroughly botching an import in your home town, and having a proven history of quite a few under-the-radar imports, you (LogicalViolinist) are still at it, far from home, at full throttle. May I suggest you simply stick to the primitive kind of mapping that other people do, at least for a while?
Nakaner-repair (2016-12-03 22:16:01+00:00): This changeset has been reverted fully or in part by changeset 44147307 where the changeset comment is: Revert undiscussed import of motorcycle parking locations from Bundesverband der Motorradfahrer. See discussion of changeset 44071123 for details.
5m4u9 (2016-11-19 07:03:23+00:00): revert, because there are another building between current building and highway
Baconcrisp (2016-11-17 23:34:36+00:00): Edits in Kuwait. KG 2016
Tyanna Eaton (2016-11-28 17:19:21+00:00): Edits in Kuwait. KG Ground Survey 2016.
Baconcrisp (2016-11-17 23:30:50+00:00): Edits in Kuwait. KG 2016
Baconcrisp (2016-11-17 23:30:34+00:00): Edits in Kuwait. KG 2016
Baconcrisp (2016-11-17 23:30:18+00:00): Edits in Kuwait. KG 2016
Nakaner-repair (2016-11-17 22:43:09+00:00): Hallo Aalen1,

bitte unterlasse weitere Nutzungen des Bayernatlas. Der Rechteinhaber hat die kommerzielle Nutzung (OSM gilt als kommerziell, da OSM kommerzielle Nutzung erlaubt) ausdrücklich untersagt (siehe http://geoportal.bayern.de/geoportalbayern/seiten/nutzungsbedingungen.html). Du darfst zwar einige amtlichen Datenquellen aus Bayern verwenden, diese sind aber alle auf http://www.ldbv.bayern.de/produkte/weitere/opendata.html aufgelistet. (Die CC-BY ist eigentlich nicht OSM-kompatibel, aber das  Landesamt für Digitalisierung, Breitband und Vermessung hat uns eine Ausnahme von der Namensnennungspflicht erteilt.

Dieser und weitere Änderungssätze werde ich daher in Kürze zurücksetzen.

Viele Grüße

Michael
Nakaner-repair (2016-11-17 22:45:01+00:00): Korrektur: Obiger Kommentar gilt zwar nicht für diesen Änderungssatz, da die bayrischen Daten Baden-Württemberg nicht abdecken, aber für die Änderungssätze in Bayern findet er Anwendung.
Aalen1 (2016-11-18 17:31:37+00:00): Hallo Michael
Ich werde es mir merken und mich bessern!
Wie ist es mit dem https://www.gisserver.de/aalen/stdmap?themes=STADTPLAN
Bei den Adressen kann man auf zwar auf den von OSM zur Verfügung gestellten  BW-Karte die Adressen entnehmen.
In einigen Fällen ist aber die Zuortung von einem Gebäude zu einer Straße nicht eindeutig. Ich werde dann in Zukunft die Münze werfen...
Grüße Aalen1
Nakaner (2016-11-18 19:50:12+00:00): Hallo Aalen1,

wenn die Zuordnung zur Straße nicht eindeutig ist, dann schau bitte vor Ort nach. Das Ziel von OSM ist es nicht, eine manuelle Kopie amtlicher Datenbestände zu sein. Amtlich heißt nicht, dass es fehlerfrei ist (ein Beispiel für eine falsche Hausnummer aus Maps4BW kenne ich, weitere kannst du sicherlich im OSM-Forum erfragen).

Oft kann man das Gebäude anhand etwas Logik zur Straße zuordnen, auch wenn im jeweiligen Kartenwerk die Hausnummern nicht passend zur Straße ausgerichtet sind.

Viele Grüße

Michael
Aalen1 (2016-11-19 11:27:05+00:00): Hallo 
Nakaner
Das mach ich  doch schon!
Aalen1
Baconcrisp (2016-11-17 23:29:46+00:00): Edits in Kuwait. KG 2016
gormo (2016-11-18 13:38:14+00:00): Bitte achte doch drauf, korrekte source=-Angaben zu machen. Ich glaub nicht, das Bing tatsächlich irgendwie eine Quelle für dieses CS war ;-)
woodpeck_repair (2016-11-23 15:41:50+00:00): This changeset has been reverted fully or in part by changeset 43898784 where the changeset comment is: revert undiscussed mass edit for shop=fishmonger
d1g (2016-11-18 05:37:40+00:00): Здраствуйте!

Я не считаю что такие правки https://www.openstreetmap.org/way/454081249 улучшают точность landuse объектов https://www.openstreetmap.org/way/242007491/history

На территории двух детских садов и школы - живут люди по вашим knowledge?

http://nrenner.github.io/achavi/?changeset=43745081
d1g (2016-11-18 05:38:50+00:00): Поправьте пожалуйста здание, после этой правки угол уехал: 

https://www.openstreetmap.org/node/3424523811/history
https://www.openstreetmap.org/way/335331624
d1g (2016-11-18 05:46:43+00:00): Контур жилого квартала был грубый, но хотя бы в парке никто не жил
https://www.openstreetmap.org/node/2495850089/history

После этого пакета:
https://www.openstreetmap.org/way/242005669

Стало только хуже: кто живет в парке?
d1g (2016-11-18 06:35:21+00:00): Очевидно что Саратов отмечался минимальной площадью landuse, достаточно посмотреть только на https://www.openstreetmap.org/#map=15/51.5111/45.9378

Южнее Агроцентра никто не начинал даже, а вот Октябрьский посёлок умеренно детализирован в landuse.
d1g (2016-11-18 07:34:06+00:00): Даже не местные видят закономерность и учитывают её в правках: http://www.openstreetmap.org/way/410216592 сам Завокзальный ещё детализировать, зато два квартала уже точно отмечено и детализировать у них  не нужно будет landuse.
Baconcrisp (2016-11-17 23:29:31+00:00): Edits in Kuwait. KG 2016
Baconcrisp (2016-11-17 23:29:17+00:00): Edits in Kuwait. KG 2016
Meillo (2016-11-21 08:10:45+00:00): Hoi,

statt den Parkplatz zu loeschen, weil er privat ist, haettest du ihn besser um das Tag access=private ergaenzt. 
Es ist ja ein Parkplatz, das ist ein Fakt. Er ist aber privat, und das ist (laut deiner Aussage) ebenso ein Fakt. Geo-Fakten sollte in der OSM enthalten sein.
Ich faende es folglich schoen, wenn du den Parkplatz, mit Privat-Markierung wiederherstellst. (Wenn du Hilfe brauchst, melde dich.)


meillo
ewaldh (2016-11-21 17:12:53+00:00): zur Info, das wahr mal eine Kirche ist jetzt privat und wird kpl. umgebaut. Der "Parkplatz" ist jetzt Baustelle und wenn du meinst daß sowas als Parkplatz deklariert werden soll, bitte.
Meillo (2016-11-21 21:55:16+00:00): Nein, wenn das so ist, dann nicht. Das war nur aus deinem 
Changeset-Kommentar nicht ersichtlich. Darum habe ich dich 
angeschrieben. Jetzt hat sich das ja geklaert. Danke.
Tyanna Eaton (2016-11-28 17:19:08+00:00): Edits in Kuwait. KG Ground Survey 2016.
user_5359 (2016-11-18 08:20:20+00:00): Willkommen bei OSM!. Bitte beachte, dass in OSM die Objekte vorrangig beschrieben werden und erst dann benannt werden. Also statt name="Wasserstofftankstelle" sondern ein Beschreiben der Tankstoffart fuel:LH2=yes (siehe http://wiki.openstreetmap.org/wiki/DE:Key:fuel). Und bitte die vorhandenen Einträge ergänzen und nicht zusätzlich Objekte schreiben (Dubletten Vermeidung)
Baconcrisp (2016-11-17 23:29:01+00:00): Edits in Kuwait. KG 2016
SomeoneElse (2016-11-18 02:18:01+00:00): Hi,
Thanks for tidying, but any reason you deleted this rather than moving it back to its previous location in Italy?
Cheers,
Andy
py_berrard (2016-11-18 07:48:34+00:00): Sorry, I didn't see there was a previous location.
SomeoneElse (2016-11-19 00:32:58+00:00): No problem - I've moved it back by reverting the original "move to null island" changeset. It's now back in Italy: http://www.openstreetmap.org/node/4505868690/history
Baconcrisp (2016-11-17 23:28:46+00:00): Edits in Kuwait. KG 2016
muralito (2016-11-18 03:04:52+00:00): Por favor, revisen la calidad de su fuente, o si fue otro tipo de error involuntario. Por ejemplo, Francisco Simon, es "concrete", no "asphalt"
Stereo (2016-11-17 23:29:35+00:00): Source = very_local_knowledge
woodpeck_repair (2016-11-23 15:47:19+00:00): This changeset has been reverted fully or in part by changeset 43898766 where the changeset comment is: revert un-discussed mechanical edit for emergency=phone
Baconcrisp (2016-11-17 23:28:31+00:00): Edits in Kuwait. KG 2016
maraf24 (2016-11-18 19:28:03+00:00): Niewłaściwy tag.
Baconcrisp (2016-11-17 23:27:41+00:00): Edits in Kuwait. KG 2016
flightsimmer (2017-08-24 13:14:01+00:00): You deleted information needed by X-Plane scenerydesigners. These keys need to be in place. Thanks.
jan_olieslagers (2017-08-24 16:12:43+00:00): I am afraid we cannot be bothered by the needs of one or other private club. Will seek advise before reverting, though. If you can find another way to avoid double information, you are very welcome. Regards,
SomeoneElse (2016-11-18 02:10:50+00:00): Hello,
I think that something has gone wrong here.  You've set the wikidata ID of both http://www.openstreetmap.org/relation/195384 and http://www.openstreetmap.org/relation/88077 to https://www.wikidata.org/wiki/Q23098 .
They're different entities on the ground.  Can you explain how you actually did the matching, and what you're actually trying to do here?
Best Regards,
Andy
SomeoneElse (2016-11-18 02:13:05+00:00): Likewise http://www.openstreetmap.org/relation/957520 and http://www.openstreetmap.org/relation/957519 have been assigned the same wikidata ID.  In this case should they perhaps share one relation that has the same wikidata ID?
nyuriks (2016-11-18 03:06:28+00:00): SomeoneElse, thanks, good catch. I'm trying to get the Wikipedia and Wikidata tags in sync. Seems that the Wikipedia tag have been set to an identical value on both. I will investigate - maybe only one of them should have it?
nyuriks (2016-11-18 03:15:11+00:00): SomeoneElse, I fixed the first one - it should have had a different Wikidata ID, as well as a different (more prescise) Wikipedia link. http://www.openstreetmap.org/relation/195384  I cannot figure out why the second pair have identical WP and WD links, without being identical. The WP article doesn't give any details either.
SomeoneElse (2016-11-18 14:08:27+00:00): Thanks - the Administrative Derbyshire's wikidata link looks OK (the sv:wikipedia page looks a bit rubbish, but we'll gloss over that - a wikipedia problem, not an OSM issue).
As things currently stand I don't think http://www.openstreetmap.org/relation/957520 and http://www.openstreetmap.org/relation/957519 have a wikidata entry at all - arguably they should be one relation in OSM.  The wikidata entry https://www.wikidata.org/wiki/Q2876117 actually claims to be for a village (not a civil parish), even though it was created from a wikipedia page that was for both "a village and civil parish ".  Most of the civil parish ones in this changeset look similarly wrong; for example https://www.openstreetmap.org/relation/957808 is Dunham on Trent civil parish, the wikipedia link is for "a village and civil parish" and the wikidata entry is for a "village in United Kingdom".  To be clear, the village https://www.openstreetmap.org/node/1782116865 and civil parish https://www.openstreetmap.org/relation/957808 are different entities in OSM; I'd expect them to have different entities in wikidata too, and I'd expect you to need to create the relevant entities in wikidata before linking to them.
nyuriks (2016-11-18 19:14:01+00:00): Hi, thanks for looking into it!
The first issue is really about Wikipedia vs Wikidata linking -- sometimes WP article covers both the village and civil parish, while WD item claims it is both, but it is really about just one meaning. Do we really want to link to both is an open question - IMO only WD link is needed, as it is more precise, and WP can be extrapolated from WD. On top of it, there are already tens of thousands of incorrect WP links in OSM, while WD is much more stable, making WD much more desirable.
In a way, having multiple rels with the same WD ID is not really wrong - because there is always 1:1 between WP and WD, so if there was a WP link, it implicitly had a WD link as well.  Specifying a more exact WD is, of course, an improvement of the data quality that is clearly a goal. 
Is there a way to query for multiple relations that share the same WD id? This would be useful to sort them out.
SomeoneElse (2016-11-18 21:45:31+00:00): Re "Do we really want to link to both is an open question" it would probably make sense not to link to either if the thing that you're linking from in OSM is something else entirely.  To be honest, I'm still struggling understand what I asked at the top - "what you're actually trying to do here".  Can you explain why (in the case of Dunham-on-Trent) you've linked the civil parish relation to the village entry in wikidata but not the village node to anything?
To answer the question of how to query for multiple relations with the same wikidata entry, it might be worth starting with taginfo http://taginfo.openstreetmap.org/keys/wikidata#values .  The first 857 pages have more that one item with a value.  To see duplication in an area, select a value and click the overpass link to see the things that have that value.
nyuriks (2016-11-18 23:15:23+00:00): I posted a long reply to https://forum.openstreetmap.org/viewtopic.php?id=56436 but it is pending moderator approval. I tried to explain both my method and reasoning. I simply locked the volatile Wikipedia link as a Wikidata ID - I have not touched the objects that did not have a Wikipedia tag already. Having a wikidata id on the object would allow it to be inserted into wikipedia article - https://www.mediawiki.org/wiki/Help:Extension:Kartographer#GeoShapes_external_data
SomeoneElse (2016-11-19 00:29:34+00:00): Thanks - I'm sure that the post will be approved shortly.
nyuriks (2016-11-19 01:00:36+00:00): SomeoneElse - https://forum.openstreetmap.org/viewtopic.php?pid=618646#p618646
nyuriks (2016-11-20 07:03:06+00:00): fixed two more dups - https://www.openstreetmap.org/changeset/43815558 - the rest (957519,957520 - Barnby Moor CP, and 1976182,4077796,1976184 European walking route E2 - seems legit. We don't need to have a perfect 1:1 between wikidata and osm - just like WP links, multiple objects in OSM can point to a single object in WD.
SomeoneElse (2016-12-12 00:24:29+00:00): It's been over 3 weeks now - are you going to fix the errors in this changeset?  Some examples noted above, but there are many others.
nyuriks (2016-12-12 10:02:07+00:00): SomeoneElse, yes, I am working on it. You can always reach me on IRC - "yurik".
SomeoneElse (2017-05-19 09:37:22+00:00): Well, It's been over 5 months now - are you going to fix the errors in this changeset? The Dunham-on-Trent example is still wrong, but there are many others.
SomeoneElse (2017-09-16 09:06:28+00:00): Actually, looks like someone's changed something in wikidata back in April - wikidata now says "village and civil parish".  Barnby Moor still in 2 pieces though (wigh pre-exists this changeset).
nyuriks (2017-09-16 19:49:17+00:00): @SomeoneElse,  I think it should be fixed differently - we should remove all tags except name, note, source, and type, and create a relation that has all the original tags with those two ways.
rab (2017-10-14 12:50:38+00:00): noch aktuell?
Polarbear (2017-10-15 20:50:56+00:00): Geh hin und schau nach?
Eine Fahrtrichtung war vor zwei Monaten wieder befahrbar, wie ich in http://www.openstreetmap.org/way/27116300 schon aktualisiert hatte. Welchen Fortschritt die andere gemacht hat, muss vor Ort überprüft werden.
Polarbear (2017-10-15 21:26:02+00:00): Laut VIZ Berlin gibt es dort noch Sperrungen bis 11/2017.
RoterEmil (2017-10-18 21:02:46+00:00): Im Moment besteht Bauphase 3, siehe: https://www.berlin.de/senuvk/bauen/strassenbau/tunnel-adenauerplatz/index.shtml (unter "Verkehrsführung während der Bauzeit" und rechts bei den Downloads). Und wie dort beschrieben, ist es auch vor Ort, allerdings ggf. bis in den November hinein. Bleibt die altbekannte Frage, ob man für einige wenige Wochen bei OSM derartige Baustellen(änderungen) eintragen sollte, schon allein, da nicht alle Router etc. ständig die Daten aktualisieren. Also entweder jetzt die Tunnelsperrung umdrehen (wo bei genaugenommen ja auch die linke Tunnelröhre nach Norden befahren werden kann, die rechte gesperrt ist) oder einfach alles wieder auf den "normalen" Status setzen, weil's sowieso nur noch eine Sache von kurzer Dauer ist und OSM m.W. auch ein Baustellenliveticker ist ;)
Polarbear (2017-10-20 07:45:32+00:00): Zum Zeitpunkt meiner Sperreintragung waren beide Richtungen für mehrere Monate gesperrt, das hielt ich für lohnenswert. 
Wenn jetzt tageweise mal die eine mal die andere Richtung offen ist, wird es kompliziert. 
Ich würde einfach warten bis alles wieder befahrbar ist, nachschauen, und dann alles aufmachen.
Polarbear (2017-10-23 08:49:43+00:00): Bei einer InAugenScheinNahme der fast fertigen Renovierung musste ich verblüfft feststellen, dass es hier keine physisch getrennten Fahrbahnen gibt, und auch nie gab, und die Spurzahl falsch war. 
Hat zehn Jahre keiner gemerkt :-)
http://www.openstreetmap.org/changeset/53171548
Sperrung habe ich weggelassen, die Aufräumung ist in den letzten Zügen, und die Umleitung geht ja oberirdisch parallel.
gormo (2016-11-18 13:35:26+00:00): Was there discussion and consensus on this mechanical edit? Could you please link to it and provide a better edit source than "Bing", because Bing is clearly not the source of this large scale edit!
PT-53 (2016-11-23 08:58:58+00:00): Bei der Schwaben-Therme in Aulendorf (Baden-Württemberg) wurde leisure=water_park durch leisure=sauna ersetzt (https://www.openstreetmap.org/way/142243312/history). Die Schwaben-Therme ist aber mehr als eine Sauna !
woodpeck_repair (2016-11-23 15:43:25+00:00): This changeset has been reverted fully or in part by changeset 43898808 where the changeset comment is: revert un-discussed mass edit of amenity=sauna after complaints
Alecs01 (2016-11-19 14:24:57+00:00): Già mappato, direi che non è proprio lì https://www.openstreetmap.org/way/140415840
Scooter_DE (2016-11-18 02:00:38+00:00): Those bridges and street do not exist as I could see (better not see) while paddling the area over recent days.
Scooter_DE (2016-11-18 02:01:03+00:00): s/street/streets/g
David Cuza (2017-04-09 16:49:16+00:00): Por que ha sido eliminado este nodo??
aharvey (2017-01-15 00:05:18+00:00): are you sure there is a bus stop here?
aharvey (2017-01-15 00:03:00+00:00): I've reverted this changeset, there is no bus stop here in the middle of central station.
jc86035 (2016-11-18 06:48:00+00:00): Hi Xavier, removed some of the tags for now because I don't think they should be displayed as stations until the line is actually open.
Xavier Fung (2016-11-18 07:16:26+00:00): Hi JC,

Nevermind. Feel free to remove at meanwhile.

Cheers,
Xavier
Supaplex (2016-11-18 06:07:03+00:00): https://www.openstreetmap.org/way/453994885
重覆了
user_5359 (2016-11-18 10:26:25+00:00): Welcome to OSM! Please check your website.
maraf24 (2016-11-18 19:30:06+00:00): A kiedy zrobiono tu przejście?
Mateusz210 (2016-11-18 19:33:53+00:00): tam zawsze było takie "dzikie" przejście dla pieszych i w tym samym miejscu powstało mniej więcej pod koniec wakacji przejście  z wyspą pomiędzy pasami ruchu
tyr_asd (2016-11-19 10:13:38+00:00): Ciao Tomi. Questa vietta mi sembra un po strana: https://www.openstreetmap.org/way/454177665: Non si vede su mapillary (foto di 2015: https://www.mapillary.com/app/?pKey=fCbO9vyoveD3dgbl7VQy6Q). È una nuova via d'accesso dell' "Enzian Office"?
Tomi (2016-11-20 20:34:39+00:00): Ciao tyr_asd, è una "cosa" strana, che non si capisce a cosa serva. o per lo meno non l'ho compresa io. Forse serve per entrare all'Enzian Office, dopo che hanno aperto via Ressel e messo i sensi unici e una corsia in più verso il semaforo dell'IDM (ex-BIC).

Prossima volta che ci passo, se non sono dentro un ingorgo, guarderò meglio a cosa serve.

Comunque è una situazione nuova. Via Ressel l'hanno aperta 2-3 mesi fa (a fine estate 2016 o forse era estate? boh! il tempo passa in fretta) e per questo non troverai queste novità se le foto sono del 2015.

Io non riesco a fare foto per Mapillary in quella zona perché in bici è un suicidio e guidando un omicidio :-)
user_5359 (2016-11-18 10:28:57+00:00): Welcome to OSM! For better description, please read http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dplace_of_worship, following the link für religion and denomination.

If you need help: You are welcome!
maxolasersquad (2016-11-18 18:13:05+00:00): I updated the metadata on the church.
user_5359 (2016-11-18 10:30:41+00:00): Hi, your map edit is similar to ones from a coordinated group of editors that we have found to be using a copyrighted source. But, I wanted to check with you to see whether that was the case or not--that way we don't potentially lose valuable data from a real user. So do you mind confirming whether this data was collected by you or if it was from another database/copyrighted geocoder? Thanks! user_5359
user_5359 (2016-12-04 12:10:24+00:00): I'm deleting this node that was created using presumed unacceptable data sources.
Carnildo (2016-11-18 08:43:55+00:00): Thanks for adding speed limits -- it's nice to know I'm not the only one who cares about them.
user_5359 (2016-11-18 10:39:17+00:00): Welcome to OSM!your modification exists before under name:zh, the tag name ist for the main country language (in this case english).
species (2016-11-18 21:18:31+00:00): Hi!
what is the source of your postal code boundaries?
afaik there are no official boundaries...
AlexK|M (2016-11-19 09:44:13+00:00): Hey! I just reverse engineer them from publicly available data like company addresses, restaurants, etc. It's a slow process but I have not found any free postal area code data so that's the only way to do it. I've started a thread here: https://forum.openstreetmap.org/viewtopic.php?id=56421