User-Namensungetüme

Communities Deutschland (Germany)
1

Es gibt OSM-Kollegen, die Namen haben, welche mehrere Kilobyte lang sind. Ein Beispiel: Man lade mit JOSM den Knoten id=1031159092. Der Name seines Autors ist 25 kB lang. Es ist davon auszugehen, dass der Kollege sich einen Namen üblicher Länge gegeben hat und dass es ein Bug in OSMs Verwaltung war, der den Namen durch gewisse Verdopplungen auf diese erstaunliche Länge gebracht hat. Dafür spricht, dass der Name eine mehrhundertfache Wiederholung von 2 Namensbausteinen ist, die jeweils durch den Schrägstrich “/” miteinander verkettet sind.

Dieses Phänomen ist mir schon mehrfach begegnet. Ich dachte, es werde schon von jemand anderem wahrgenommen werden, der vertrauter mit OSMs Interna ist und sicherer urteilen kann, ob ein Fehlerbericht an zuständige Stellen sinnvoll ist. Jetzt weise ich halt einmal darauf hin.

Gruß
Heinrich

2

Kann ich nicht nachvollziehen. gerosm = 6 Zeichen.

3

Das sind die längsten in meiner DB:


osm=# select id,length(name) len,name
from users
order by length(name) desc
limit 20;
   id    | len |                       name                       
---------+-----+--------------------------------------------------
 1038961 |  48 | Ycarus-import-cadastre-villieu-loyes-mollon-2012
  713542 |  47 | Johanniter Unfall Hilfe Regionalverband Harburg
 1030799 |  46 | Ycarus-import-cadastre-chatillon-la-palud-2012
 1029791 |  45 | Keller Williams Colorado Mountain Real Estate
  372152 |  44 | Langhofer Quality Hosting and Solutions GmbH
   64979 |  44 | vanny in Deutschland Sachsen-Anhalt Bernburg
 1029537 |  41 | Ycarus-import-cadastre-la_trancliere-2012
 1092361 |  39 | Докшицкая центральная районная больница
   83714 |  39 | plan_at_Upload_by_Wolfgang_Wasserburger
 1031178 |  39 | Ycarus-import-cadastre-versailleux-2012
  120251 |  39 | Traditional Taekwon-Do Center Schwabach
  179968 |  38 | Ich_hasse_doitsche_OSM-Korinthenkacker
 1041795 |  38 | Ycarus-import-cadastre-seillonnaz-2012
 1032171 |  38 | Ycarus-import-cadastre-le_plantay-2012
 1043666 |  38 | Ycarus-import-cadastre-saint-remy-2012
 1048574 |  38 | The Burrow Host Family Bed & Breakfast
  334298 |  37 | Panorama Apartment Berlin City Centre
   43790 |  36 | TFH Wildau - Telematik Master (TM07)
  532390 |  36 | assista VB Integrative Beschäftigung
 1042001 |  36 | Ycarus-import-cadastre-peronnas-2012

es mag noch andere geben, falls die längere Zeit nicht gemappt haben.

Gruss
walter

4

Tut mir leid, dass mein Hinweis, so wie gegeben, nicht geeignet war, den Fehler zu reproduzieren.

Die Ursache des Schlamassels scheint zu sein, dass JOSM nicht gut mit User-Namensänderungen zurechtkommt. Ich habe eine OSM-Datei aufbewahrt, in der ein Knoten seinerzeit von Kollege “gerzap” zuletzt bearbeitet wurde. “gerzap” hat sich irgendwann zwischen dem 24.3.2010 und heute in “gerosm” umbenannt. Wenn man folgende Mini-osm-Datei (ist ein Ausschnitt einer osm-Datei, die ich vor etwa einem Monat erstellt habe)


<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' upload='true' generator='JOSM'>
  <node id='315308827' timestamp='2010-03-24T16:06:12Z' uid='51230' user='gerzap' visible='true' version='2' changeset='4222252' lat='49.8831275' lon='11.5528015'>
    <tag k='power' v='tower' />
  </node>
</osm>

von JOSM lädt und das Versionsprotokoll des Knotens aufruft, sieht man schon die erste Namensverlängerung in Zeile 2: Nutzer=gerosm/gerzap. Speichert man die osm-Datei, dann wird darin für besagten Knoten der Name “gerosm/gerzap” abgelegt. Lädt man die osm-Datei erneut und schaut sich wieder das Versionsprotokoll an, dann heißt der Nutzer des Knotens schon “gerosm/gerzap/gerosm/gerzap”. Mit jedem Abspeichern und Neuladen verdoppelt sich die Namenslänge.

Ich pflege gewisse osm-Dateien, um Veränderungen von Objekten, die mich interessieren, auf einfache Weise verfolgen zu können. Daher kommt es, dass diese osm-Dateien wiederholt Zyklen des Ladens und Speicherns durchlaufen.

Heinrich

5

Hallo Heinrich

Da das sehr wahrscheinlich ein Fehler in JOSM ist, wäre ein Ticket mit der Problembeschreibung sinnvoll.
Es kann sehr gut sein, dass a) dieser Fehler selten ist und b) bisher niemand die Ursache ergründen konnte.

Edbert (EvanE)

6

version 1: 28.11.08 user_34262
version 2: 24.03.10 gerosm
version 3: 02.12.12 aliponte

alles sauber, null problemo - josm 5608

Gruss
walter

7

Ich konnte den Fehler rekonstruieren - ebenfalls mit Version 5608.

mfg~ray

8

@Edbert

Danke für die Ermutigung einen Bericht zu schreiben. Ich habe meine Beobachtung als ticket #8251 eingebracht. BastiK hat den entscheidenden Teil von JOSMs Verhalten in dieser Sache als Programmfehler bestätigt.

Heinrich