In einem anderen Thread hatte ich ja schon geschrieben:
In der Tat birgt die Möglichkeit der POI-Hinzufügens / Änderns über Apps wie Maps.me oder Osmand ein gewisses Gefahrenpotential für Datendoppelungen etc je älter deren Kartendateien sind, zu welchen wirklich ein eigener Thread hier gefüllt werden kann.
Für eine erste gezielte Suche nach Änderungssätzen dieser “Editor-Apps” hat ja seit kurzem der Dienst WhoDidIt von Simon eine Möglichkeit, gezielt nach bestimmten Editor-Namen (NICHT user) zu filtern: http://simon04.dev.openstreetmap.org/whodidit/ … dort mal maps.me oder osmand oder was auch immer eintragen.
Dort kann man auch einen Editor-Namen eingeben u d danach filtern, aber leider nicht regional filtern wie z.B. "alles nur in Europa oder einem bestimmten Staat.
Ich werd mal probieren, beides in der Wikiseite von Beitrag #1 einzutragen.
select osm_id,tags
from planet_osm_point
where tags->'name' != ''
and tags ? 'name:zh'
and position(tags->'name:zh' in name) > 0
and st_contains((select way from planet_osm_polygon where osm_id=-51477),way)
;
osm_id | tags
--------+------
(0 Zeilen)
Noch ein Hinweis, im Wiki scheinst du zu implizieren, dass die Chinesischen Touristen die das Problem verursachen, dass absichtlich machen. Das dürfte wohl eher ein Problem der Benutzerführung von maps.me sein, sprich name:zh tag wird nicht angeboten und möglicherweise auch ein RTL Problem.
RTL im Sinne von “Gegenteil von Sat.1” oder RTL im Sinne von rechts-nach-links.
Es wäre mir neu, dass irgendwelche Apps Chinesisch vertikal schreiben, nur dann gäbe es auch nur irgendwie ein Problem mit der Schreibrichtung. Horizontal schreiben sich chinesische Schriftzeichen wie unsere von links nach rechts.
Stimmt, RTL ist das richtige Software-Entwickler-Stichwort für Sprachen wie Hebräisch, Arabisch etc., trifft hier also nicht zu ;-). Vielleicht passt CTL – “Complex Text Layout” – oder CJK – “Chinese/Japanese/Korean” --; beides gängige Abkürzungen in Software-Projekten für die besonderen Anforderungen des Schreibens in ostasiatischen Sprachen?!
Ich glaube nicht, dass die Query das macht was du willst, speziell haben die Objekte mit kaputten Namen im Schnitt kein name:zh Tag und ob, wenn name:zh vorhanden, die maps.me Nutzer das gleiche in name eingetragen haben ist eher unwahrscheinlich. In meiner Erfahrung und google translate sind es eher selten wirkliche Chinesische Namen für die Objekte.
Sind leider auch areas betroffen, z.B. hier: http://www.openstreetmap.org/way/27426213
Der Mapper wollte wohl ein Restaurant ändern und hat dann nebenbei den Name vom BAUHAUS geändert.
Das sind die Standard-Ideographen. Die ersten CJK-Codes gibt es sogar schon ab x2E80 http://www.utf8-zeichentabelle.de/. In der Praxis dürfte das aber keinen Unterschied machen, da jeder chinesische Text Standard-Zeichen enthalten müsste.
Genau genommen sind aber selbst etliche der ASCII-Zeichen (~, @, { …) verdächtig, die Codes ab x0100 für Namen in DACH sowieso.
Den Ansatz hatte ich vorher mit einem regexp. Ist aber voll in die Hose gegangen. Du ahnst es nicht, welcher Schrott aber auch “richtige” ASCII-Zeichen in den Namen drin sind.
360°, T€DI, O² , diverse Anführungszeichen, Sonderzeichen, …
nach
name not similar to e'[A-Za-z0-9ÄÖÜäöüß ÁÉÍÓÚŹáéíóúźàèòùśŁłîăčěğŠšžÇ窺ñūâêÎÔøİ()\\-,.:;\/_–\'|\\[\\]´`+!&@®#?€„“”»«°№\"’]*'
hab ich dann aufgegeben und das Vorgehen gewechselt.
Gruss
walter
ps: die nächste Auswertung mach ich mal für DACH. Wird aber einige Tage dauern, da die mehrere Stunden schleicht und ich meine DB nicht zu sehr quälen will.
Ich finde man die wieder korrigiert sollte man die chinesischen Namen nicht einfach wegwerfen, wie es in http://osmlab.github.io/osm-deep-history/#/node/1853002791 passiert ist, sondern nach name:zh übertragen, nachdem man geprüft hat, ob das stimmt (z.B. mit Wikipedia).