Maps.Me macht Probleme

Ich hab grad keine osm2pgsql-Datenbank.

Kannst du mal

 select *
from [ ... nodes ...]
where "name" is not null
  and tags->"name:zh" is not null
  and strpos("name", "tags->"name:zh") != -1
  and (innerhalb DE)

in korrektes SQL umwandeln :wink: und rennen lassen? Darüber könnte man einige finden…

Danke für die Chinesisch-Beispiele. Ich habe sie im Wiki ergänzt, habe jedoch zwei Bitten:

  1. Behebt das Problem, nachdem ihr es gefunden habt. Es bleibt ja weiterhin in der Versionsgeschichte der Objekte sichtbar.
  2. Tragt es im Wiki ein. Dort ist es auf Englisch dokumentiert.

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.

oder auch der (noch experimentelle changeset-Filter unter
http://osmcha-django-staging.tilestream.net/

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.

komisch:


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)


liefert keinen Treffer.

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.

Simon

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?!

Danke fürs Prüfen. Hmm, dann gibt es das Problem nicht, oder nicht großflächig? Oder nur nicht dauerhaft?

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.

Simon

Oder was auch immer. Tatsache ist, dass wir viele Changesets mit Hinweis hatten, dass nichts oder was falsches angezeigt wird, zB.: http://www.openstreetmap.org/node/26864921/history

Da müsste man also eher prüfen, ob im name=* Unicode-Zeichen oberhalb Hex3000 vorkommen.

Hallo,

es gibt erste Antworten von Maps.Me-Mitarbeiter Zverik. https://wiki.openstreetmap.org/wiki/Maps.Me/Questionable_OSM_Edits

Viele Grüße

Michael

Wieso ab x3000?

Ich hab mal x4e00-x9fff geprüft. Das ist der Unicode-Block für CJK (China/Japan/Korea) http://unicode-table.com/en/blocks/cjk-unified-ideographs/

Danach gab es für die POI (Nodes mit Tags) in DE folgende Treffer:


select osm_id,wno_asosmlink('N',osm_id),name
  from planet_osm_point
 where way && (select way from boundaries where id=51477)
   and st_contains((select way from boundaries where id=51477),way)
   and tags ? 'name'
   and wno_testCJK(name)
 order by osm_id
;

   osm_id   |                    wno_asosmlink                    |                name                
------------+-----------------------------------------------------+------------------------------------
   34916062 | http://www.openstreetmap.org/browse/node/34916062   | Westin法兰克福
  247748202 | http://www.openstreetmap.org/browse/node/247748202  | Norma超市(机场旁饮食街)
  278969649 | http://www.openstreetmap.org/browse/node/278969649  | Sushihaus 寿司家
  771332600 | http://www.openstreetmap.org/browse/node/771332600  | Vinh-Loi Asien-Supermarkt 榮利市場
 1040998800 | http://www.openstreetmap.org/browse/node/1040998800 | 亚洲餐厅 China Restaurant Asia
 1097197479 | http://www.openstreetmap.org/browse/node/1097197479 | 新上海?New Shanghai
 1597769078 | http://www.openstreetmap.org/browse/node/1597769078 | 吴家菜 Mr. Wu
 1827870186 | http://www.openstreetmap.org/browse/node/1827870186 | Vinh-Loi Asien-Supermarkt 榮利市場
 1853002791 | http://www.openstreetmap.org/browse/node/1853002791 | Friedrich Ebert 保尔广场
 1970262280 | http://www.openstreetmap.org/browse/node/1970262280 | Vinh-Loi Asien-Supermarkt 榮利市場
 2018810774 | http://www.openstreetmap.org/browse/node/2018810774 | 牛稼莊 Beef House
 2748206479 | http://www.openstreetmap.org/browse/node/2748206479 | Vinh-Loi Asien-Supermarkt 榮利市場
 2748240260 | http://www.openstreetmap.org/browse/node/2748240260 | Vinh-Loi Asien-Supermarkt 榮利市場
 3045678795 | http://www.openstreetmap.org/browse/node/3045678795 | Daimler Stadium奔驰体育中心
 4231229416 | http://www.openstreetmap.org/browse/node/4231229416 | 德雷瑪德羅斯雷登酒店
 4237233991 | http://www.openstreetmap.org/browse/node/4237233991 | 韩国免税店
 4237274590 | http://www.openstreetmap.org/browse/node/4237274590 | 大学生之吻
 4240763089 | http://www.openstreetmap.org/browse/node/4240763089 | 買Rimowa Hetzenecker
 4241056029 | http://www.openstreetmap.org/browse/node/4241056029 | 保时捷博物馆 P
 4242559901 | http://www.openstreetmap.org/browse/node/4242559901 | 喷漆工厂
(20 Zeilen)

Ich kann das aber jederzeit für einen erweiterten Bereich erneut laufen lassen.

Gruss
walter

ps: wer die beiden SQL-Funktionen haben möchte, möge sich melden.

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.

Die Ways:


  osm_id   |                   wno_asosmlink                   |                   name                   
-----------+---------------------------------------------------+------------------------------------------
  27426213 | http://www.openstreetmap.org/browse/way/27426213  | 吴家菜 P von BAUHAUS
 129305953 | http://www.openstreetmap.org/browse/way/129305953 | 滑雪场
 259653374 | http://www.openstreetmap.org/browse/way/259653374 | Jehovas Zeugen Königreichsaal 王国聚会所
 292417576 | http://www.openstreetmap.org/browse/way/292417576 | Museum für Stadtgeschichte 修道院
(4 Zeilen)

Passende Rels gibt es nicht.

Gruss
walter

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.

Das hört sich ja fast nach einer neuen “Irrenjagd” an.

Nicht ganz - aber so 1x im Monat könnte ich die schon laufen lassen.

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).