OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2016-01-05 23:22:41

Hakuch
Member
Registered: 2014-03-16
Posts: 638

alt_name und name_1 - Voting

kann mir jemand den Unterschied zwischen diesen Tags (alt_name / name_1) erklären? Aus dem Wiki konnte ich nicht wirklich was herauslesen, auch schon verwendetes Tagging erschien mir nicht schlüssig.

Last edited by Hakuch (2016-01-25 01:23:00)

Offline

#2 2016-01-05 23:37:58

Prince Kassad
Member
Registered: 2013-10-18
Posts: 2,391

Re: alt_name und name_1 - Voting

name_1 ist falsch und muss entfernt werden, wenn es irgendwo vorkommt. Gilt für alle Tags, die auf _1, _2 usw. enden.

Offline

#3 2016-01-05 23:42:10

Hakuch
Member
Registered: 2014-03-16
Posts: 638

Re: alt_name und name_1 - Voting

na und warum stehts dann im Wiki? im Grunde fänd ich das ja auch richtig, aber was macht man dann wenn es mehr als einen alternativen Namen gibt?

Last edited by Hakuch (2016-01-05 23:43:15)

Offline

#4 2016-01-06 00:18:01

reneman
Member
From: Mainz
Registered: 2012-10-13
Posts: 1,106
Website

Re: alt_name und name_1 - Voting

Prince Kassad wrote:

name_1 ist falsch und muss entfernt werden, wenn es irgendwo vorkommt. Gilt für alle Tags, die auf _1, _2 usw. enden.

So ein schmarn. Wie kommst du zu der Aussage, dass einfach etwas zu löschen ist??
Sofern möglich, ist ein alternatives Tag dafür zu verwenden, aber sonst nix.
Dafür wäre dann ein Beispiel auch mal ganz hilfreich... wink


» Check the Monuments! «
Viele der als historic=monument erfassten Objekte sind in Wirklichkeit kein Monument. Sie wurden mangels passender Tags oder aus Unkenntnis als Monument erfaßt. Diese Karte CheckTheMonuments will bei der Korrektur unterstützen.

Offline

#5 2016-01-06 00:18:17

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,362
Website

Re: alt_name und name_1 - Voting

Prince Kassad wrote:

name_1 ist falsch und muss entfernt werden, wenn es irgendwo vorkommt. Gilt für alle Tags, die auf _1, _2 usw. enden.

Nun mal langsam. Davon gibt es derzeit 1343 Nodes (Poi) in OSM. Ways und Rels kämen noch dazu.
Ein pauschales "das ist Mist und kann weg" ist hier nicht angebracht.

Klar, ich wäre das Zeug auch gerne los, aber nicht so.

Gruss
walter

Offline

#6 2016-01-06 00:29:08

Hakuch
Member
Registered: 2014-03-16
Posts: 638

Re: alt_name und name_1 - Voting

naja, man könnte es ja zumindest als "deprecated" markieren damit es nicht weiter verwendet wird? Offensichtlich gibt es da anscheinend eine Konkurrenz zwischen den beiden Tags

Offline

#7 2016-01-06 00:41:18

R0bst3r
Member
Registered: 2015-04-23
Posts: 533

Re: alt_name und name_1 - Voting

alt_name bedeutet nicht "alter name" sondern "alternativer name". Ist also vergleichbar mit name_1 und bestimmt nicht "deprecated".
Das name_1 stammt von iD Editor, wenn man mehrere gleiche keys verwendet und ist daher "gebräuchlich", wenn auch nicht richtig.
Ich selbst kann mit dem Tag gut leben und seh ihn einfach nur als Ergänzung. Bei Auswertungen kann er ignoriert werden.

Offline

#8 2016-01-06 01:11:29

Hakuch
Member
Registered: 2014-03-16
Posts: 638

Re: alt_name und name_1 - Voting

R0bst3r wrote:

alt_name bedeutet nicht "alter name" sondern "alternativer name". Ist also vergleichbar mit name_1 und bestimmt nicht "deprecated".

ehm, naja is ja klar, genau darum geht es ja hier. Die Frage ist ja, wozu man name_1 neben alt_name überhaupt braucht

Das name_1 stammt von iD Editor, wenn man mehrere gleiche keys verwendet und ist daher "gebräuchlich", wenn auch nicht richtig.
Ich selbst kann mit dem Tag gut leben und seh ihn einfach nur als Ergänzung. Bei Auswertungen kann er ignoriert werden.

Aha, das ist ja interessant, also verbockt der Editor das? Dann sollte das trotzdem nicht im Wiki stehen und Leute dazu animieren den anzuwenden. Wenn name_1 keinen Mehrwert gegnüber alt_name bieten kann sollte er nicht mehr zum taggen vorgeschlagen werden. Im WIki stehen sogar noch solche Sachen wie alt_name_1...

Allerdings kann es wirklich auch vorkommen, dass es mehr als einen alt_name gibt, das ist aber keine Rechtfertigung für name_1

Offline

#9 2016-01-06 01:16:59

Prince Kassad
Member
Registered: 2013-10-18
Posts: 2,391

Re: alt_name und name_1 - Voting

Es gibt ja auch z. B. brand_1 und brand_2 usw. Ich hab das schon bei allen möglichen Tags gesehen, ich meine einmal sogar shop_1 gesehen zu haben.

Offline

#10 2016-01-06 01:49:10

Hakuch
Member
Registered: 2014-03-16
Posts: 638

Re: alt_name und name_1 - Voting

mh ja und garnicht so wenige

https://taginfo.openstreetmap.org/search?q=shop_1

Bei amenity gibts da auch nochmal einige, wenn man sich fragt woher das kommt, vielleicht wirklich aus dem ID der das einfach so macht? Ist natürlich der leichte Weg wenn man ein Geschäft nicht richtig einordnen kann. Ausgewertet werden kann das dann wahrscheinlich nicht richtig.

Mh schön find ich das nicht, vor allem gibt es bei alt_name ja schon eine Variante, aber ich kann nun auch verstehen wenn man das verwendet wenn sich ein Geschäft beispielsweise nicht so einfach einordnen lässt. Aber es birgt auch die Gefahr, dass man es sich dann zu einfach macht.

Last edited by Hakuch (2016-01-06 01:50:19)

Offline

#11 2016-01-06 06:58:46

kreuzschnabel
Member
Registered: 2015-07-03
Posts: 5,997

Re: alt_name und name_1 - Voting

Prince Kassad wrote:

Es gibt ja auch z. B. brand_1 und brand_2 usw. Ich hab das schon bei allen möglichen Tags gesehen, ich meine einmal sogar shop_1 gesehen zu haben.

Das macht iD automatisch, wenn ein schon vorhandener key nochmals gesetzt wird. Probier’s aus, öffne eine Wohngegend, selektiere einen highway=residential und setz unten unter „Alle Eigenschaften“ von Hand ein highway=motorway dazu.

Sei in einem Haus ein Schuh- und ein Klamottengeschäft. User 1 hat das shop=shoes an den building-way gehängt, User 2 taggt mit iD das Klamottengeschäft ebenfalls an den building-way, dann setzt sein Editor automatisch shop_1=clothes. (JOSM würde fragen, ob das shop=shoes überschrieben werden soll.)

Mich stört daran sehr, daß damit ein Value erstmal „geparkt“ wird, sich aber einer automatischen Auswertung möglicherweise entzieht, sofern man bei der Abfrage diese „_n“-Keys nicht gezielt mit berücksichtigt. Wer bei Overpass nur nach „shop=clothes“ sucht, findet einen mit „shop_1=clothes“ getaggten Klamottenladen wahrscheinlich nicht (außer Overpass berücksichtigt das automatisch).

--ks

Edit: taginfo findet für shop_1 597 Treffer.

Last edited by kreuzschnabel (2016-01-06 07:12:49)

Offline

#12 2016-01-06 08:33:55

Chrysopras
Member
From: Baden-Württemberg
Registered: 2015-04-01
Posts: 1,406

Re: alt_name und name_1 - Voting

Um noch mal auf die ursprüngliche Frage zurückzukommen:

Hakuch wrote:

kann mir jemand den Unterschied zwischen diesen Tags (alt_name / name_1) erklären? Aus dem Wiki konnte ich nicht wirklich was herauslesen, auch schon verwendetes Tagging erschien mir nicht schlüssig.

Früher stand name_1 gar nicht im Wiki, das hat jemand eingefügt, um mit der iD-verpesteten Realität Schritt zu halten. wink

Für das name-Tag gibt es eine ganze Reihe mehr oder minder wohldefinierter Alternativtags, die den großen Vorteil haben, semantisch reicher zu sein als alt_name oder name_1:

official_name=*: offizieller Name, nützlich z.B. für amtliche, aber ansonsten ungebräuchliche Namensformen
loc_name=*: lokaler Name, nützlich z.B. für vor Ort häufig gebrauchte Namensformen
old_name=*: frühere Namensformen, z.B. vor Umbenennung einer Straße bei Gemeindereform
short_name=*: für gebräuchliche kurze Namensformen (sollte irgendwann auch mal von einem intelligenteren Renderer verwendet werden, wenn der Platz nicht für name=* reicht!)
long_name=*: für 'lange' Namensform
abbr_name=*: für gebräuchliche abgekürzte Formen
name:(languagecode)=*: für Namensform in einer bestimmten Sprache
... und einiges mehr.

Dies alles findet sich ja auch auf der Wiki-Seite (http://wiki.openstreetmap.org/wiki/Key:name). Alle diese Alternativtags haben den Vorteil, nicht nur zu sagen: 'das ist irgendwie ein alternativer Name', sondern anzugeben, um was für eine Namensform es sich handelt.

Daher sollte man für alternative Namensformen mMn immer (1), wenn möglich, eines der angeführten semantisch reicheren Tags verwenden. Nur wenn (2) von diesen keines passt, sollte man alt_name=* verwenden. Und für name_1=* ... bleibt dann eigentlich kein Bedarf mehr.

Last edited by Chrysopras (2016-01-06 08:46:51)

Offline

#13 2016-01-06 08:36:20

Chrysopras
Member
From: Baden-Württemberg
Registered: 2015-04-01
Posts: 1,406

Re: alt_name und name_1 - Voting

kreuzschnabel wrote:

Das macht iD automatisch, wenn ein schon vorhandener key nochmals gesetzt wird. Probier’s aus, öffne eine Wohngegend, selektiere einen highway=residential und setz unten unter „Alle Eigenschaften“ von Hand ein highway=motorway dazu.

Sei in einem Haus ein Schuh- und ein Klamottengeschäft. User 1 hat das shop=shoes an den building-way gehängt, User 2 taggt mit iD das Klamottengeschäft ebenfalls an den building-way, dann setzt sein Editor automatisch shop_1=clothes. (JOSM würde fragen, ob das shop=shoes überschrieben werden soll.)

Mich stört daran sehr, daß damit ein Value erstmal „geparkt“ wird, sich aber einer automatischen Auswertung möglicherweise entzieht, sofern man bei der Abfrage diese „_n“-Keys nicht gezielt mit berücksichtigt.

Es gibt mMn ein noch größeres Problem bei diesem Verhalten von iD: Da iD solche key_n-Tags automatisch erzeugt, "wenn ein vorhandener key nochmals gesetzt wird", weiß man nie genau, welche(r) Wert(e) nun vom Mapper intendiert ist/sind und welche nicht.

Begründung: Es kommt vor, dass ein Mapper z.B. name_1=* absichtlich setzt, um einen Alternativnamen anzugeben; oder amenity_1=*, weil der Mapper mehrere Amenities auf ein Objekt packen will. Es kommt aber auch vor, dass das key_n-Tag von iD erzeugt wird, ohne dass der Mapper das überhaupt bemerkt; in diesem Fall enthält dann manchmal key_n=* den Wert, den der Mapper intendiert hat, weil er eigentlich key=* korrigieren wollte, es scheint (*) aber auch vorzukommen, dass der Mapper danach nochmals den Wert von key=* bearbeitet und deshalb key_n=* veraltet ist ...

Ergebnis: die Syntax key_n=* ist nicht nur (1) schwer auszuwerten, sondern (2) auch semantisch unklar: es ist nicht eindeutig, ob ein Tag key_n=* nun den Wert von key_=* ergänzen oder ersetzen soll. Daher sind die key_n-Tags mMn 'verbrannt' und sollten vermieden werden. Falls wir wirklich mehrfache Werte brauchen, können wir, wenn es nicht spezielle Tags gibt wie bei name=*, auf die gute alte umstrittene ;-Syntax zurückgreifen (die immerhin den Vorteil hat, klar als 'mehrere alternative Werte' definiert zu sein, und auf jeden Fall leichter auszuwerten sein sollte).


(*) Ich habe mal alle damals vorkommenden key_n=* in Baden-Württemberg untersucht und das war mein Ergebnis.

Last edited by Chrysopras (2016-01-06 09:27:36)

Offline

#14 2016-01-06 09:15:05

gormo
Member
Registered: 2013-08-01
Posts: 2,030
Website

Re: alt_name und name_1 - Voting

Mit dieser Overpass-Abfrage müsste man eigentlich viele der _n-Tags finden: http://overpass-turbo.eu/s/dzY .

[out:json][timeout:25];
// gather results
(
  (
  // Unterstrich-Tags
    (
    node[~".*_[123456789]$"~"."]({{bbox}});
    way[~".*_[123456789]$"~"."]({{bbox}});
    relation[~".*_[123456789]$"~"."]({{bbox}});
    )
   -
  // aber nicht TMC
    (
    node[~"^TMC*"~"."]({{bbox}});
    way[~"^TMC*"~"."]({{bbox}});
    relation[~"^TMC*"~"."]({{bbox}});
    )
  )
  -
  // und nicht fuel
  (
    node[~"^fuel*"~"."]({{bbox}});
  way[~"^fuel*"~"."]({{bbox}});
  relation[~"^fuel*"~"."]({{bbox}});
  )
  ;
);
// print results
out body;
>;
out skel qt;

OSM hat nicht das Ziel bis Ende des Monats einen vollständigen Datensatz der Welt zu enthalten.
(nach S.W.) - Aber weil die Welt vielfältig ist, weil sie auch im Detail interessant ist, mag ich genaue Karten (nach C.)

Offline

#15 2016-01-06 09:24:31

Chrysopras
Member
From: Baden-Württemberg
Registered: 2015-04-01
Posts: 1,406

Re: alt_name und name_1 - Voting

Wir hatten das Thema der ..._1 ..._2 ..._n-Tags übrigens mindestens schon einmal, nur etwas genereller:

http://forum.openstreetmap.org/viewtopic.php?id=30806

mit allerhand interessanten Beobachtungen und Statements.

Last edited by Chrysopras (2016-01-06 09:25:52)

Offline

#16 2016-01-06 09:35:13

gormo
Member
Registered: 2013-08-01
Posts: 2,030
Website

Re: alt_name und name_1 - Voting

Chrysopras wrote:

Wir hatten das Thema der ..._1 ..._2 ..._n-Tags übrigens mindestens schon einmal, nur etwas genereller:

http://forum.openstreetmap.org/viewtopic.php?id=30806

mit allerhand interessanten Beobachtungen und Statements.

Oh danke, da finde ich auch meine beiden Links wieder, die ich eben schon gesucht habe:

gormo wrote:

Hier ist die Diskussion (es gab keine inhaltliche) zur Einführung der _n-Suffixe: https://github.com/openstreetmap/iD/issues/2043, https://github.com/openstreetmap/iD/pull/2228


OSM hat nicht das Ziel bis Ende des Monats einen vollständigen Datensatz der Welt zu enthalten.
(nach S.W.) - Aber weil die Welt vielfältig ist, weil sie auch im Detail interessant ist, mag ich genaue Karten (nach C.)

Offline

#17 2016-01-06 13:23:31

Hakuch
Member
Registered: 2014-03-16
Posts: 638

Re: alt_name und name_1 - Voting

Ich hab mir die Diskussionen unter euren Links (danke!) nochmal angeschaut und hab versucht nachzuvollziehen wie das ganze in die OSM-Welt kam.

In diesem Talk wird ein Problem bei einem HOT Projekt beschrieben, in dem sie Daten manuell importierten und dabei allerdings mal die Variante alt_name:2 und mal alt_name_2 verwendet haben. Die Person wollte das nun mit einem vollmechanischen Edit alles auf alt_name_2 ändern, aber nicht nur im Gebiet des Hot Projekts sondern am liebsten auch weltweit.

Das wurde wohl auch extra mit Twain vom Nominatim Team abgesprochen, der dafür einen Patch geschrieben hat damit diese alternativen (alt_name_n) auch berücksichtigt werden. Allerdings war das sonst wohl nicht weiter abgesprochen und dementsprechend entstand eine etwas hitzige Diskussion weil die Variante mit dem Semikolon schon existierte und vorgezogen werden sollte. (wie genau die Diskussion verlief könnt ihr ja nachlesen bei Interesse).
Auf jeden Fall gibt es diese alt_name_n Variante nun knapp 4000 mal in einem Gebiet in Westafrika (http://overpass-turbo.eu/s/4ZL) und eher selten ausserhalb dieses Gebietes.

Allerdings hat Twain (von Nominatim) diese Variante dann im November 2014 ins Wiki geschrieben und damit dokumentiert

http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:name&oldid=1112625 wrote:

Document the alt_name_1 tagging currently supported by nominatim to avoid ';' separated lists

mit extra Hinweis darauf, dass ';'-Listen vermieden werden sollen, ist ihm das also ein Anliegen?

Im April 2015 wurde dann nochmal präzisiert, dass das dann verwendet werden soll wenn die Zeichenanzahl für die Kommata-Listen nicht mehr ausreichen (so sol man den Satz wohl verstehen, die deutsche Übersetzung war dann noch schlimmer)

http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:name&oldid=1162522 wrote:

Usually only used when the alternative names do not fit in a single alt_name=* key.

Die Dokumentation von name_x kam dann erst im August dazu und basiert wohl nicht auf irgendwelchen Proposals oder Diskussionen sondern auf dem puren Vorhandensein dieses Tags:

http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:name&oldid=1204516 wrote:

Document de-facto name_N variant

Was auch immer man allgemein jetzt von diesen Werten halten will, die Dokumentation im Wiki ist meiner Meinung nach jeweils recht schlecht geraten.

Jetzt könnte man natürlich vermuten, dass das hohe Aufkommen von name_x durch den ID Editor entstanden ist. Interessant dazu wäre ja mal eine historische Entwicklung, gibt es dafür ein Tool? Also ein Taginfo das die Anzahl in der Vergangenheit erhebt? Den ID gibt es ja noch nicht soo lang. Außerdem wäre ein Zusammenhang zwischen "Changeset der mit ID gemacht wurde" und "name_x ist neu getaggt worden" Interessant. Stichproben nach zumindest bestätigt sich, dass das zusammengehört.

Allerdings geht das Problem dann ja auch weiter, wenn man den ID betrachtet. Denn wie in einem der verlinkten Beiträgen auch schon erwähnt wird:

Chrysopras wrote:

Denn, was man nicht vergessen darf: nur ein Teil der _1-Tags wird von iD automatisch erzeugt – ein anderer Teil wird von fortgeschrittenen Newbies angelegt, die eben von iD "gelernt" haben, dass man beliebige Tags mit _1, _2 etc. anlegen kann und sogar soll. Das sind die Folgen dieses dummen Features, und gerade deshalb (weil es sozusagen "die Jugend verdirbt") halte ich es für einen dicken fetten Bug.

Wie in dem Thread gezeigt wird, handelt es sich übrigens nicht um einen Bug sondern ein Feature, ist also extra eingebaut, wie es dazu kam zeigen diese Kommentare von den Entwicklern:

bhousel wrote:

https://github.com/openstreetmap/iD/issues/2043 https://github.com/openstreetmap/iD/pull/2228 I handle the "tiny complication" by keeping both values if there is a conflict, but one of them will have a numeric suffix (e.g. "name" and "name_1"). This lets the user choose which one to keep.
----
In fact the current behavior in iD with duplicate tags is kind of unfriendly. If you try to add a duplicate tag, e.g. another name=, it destroys the old one (which probably contained the actual name of the object). Undo can put it back, but users can easily miss that it changed.

Also anstatt einer Warnung oder Erklärung baut der ID da eine "Lösung" die die Daten vermüllt und, noch schlimmer, die Leute darin trainiert das auch selbst weiter zu machen. Eigentlich wollte jemand dazu was in den ID Bugtracker schreiben, ich weiß aber nicht ob dass dann passiert ist?


Dieses Verhalten vom ID sollte auf jeden Fall aufgehalten werden weil es völlig unkontrolliert ist und sich ja auch nicht nur auf name_x oder alt_name_x bezieht sondern noch viel mehr Blüten treibt (schöne Beispiele gibts in dem verlinkten Thread).

Trotzdem weiß ich nicht, ob man generell sagen kann "braucht man nicht, muss weg, semikolon ist besser". Natürlich hat sich zuallererst mal das Semikolon etabliert, auch mit dem Argmument, dass sich das besser auswerten liesse. Das wundert mich allerdings ein bisschen, zwar kann ich das total nachvollziehen für Fälle in denen ich mir einen bestimmten Datensatz genau anschaue. Aber für Programme wie Nominatim beispielsweise die in den Daten suchen ist das doch viel komplizierter / kostenreicher weil dann reguläre Ausdrücke etc. genutzt werden müssen. Allerdings werden sich diese Programme wahrscheinlich sowieso einen eigenen Index zusammenbasteln womit das dann schon wieder obsolet wird.

Viel wichtiger finde ich aber zu beachten, dass es in manchen Ländern nicht so eindeutig festgelegte offizielle Namen gibt und da dann vielleicht wirklich mehrere Namen vorkommen könnten, die den Rahmen von 255 Zeichen sprengen würden? Wahrscheinlich kommt das aber auch nicht wirklich oft vor und wahrscheinlich könnte man das oft mit sprachenspezifischen Name-Tagging auffangen. Ich fänd nur wichtig, dass diese Möglichkeit auch Bestandteil der Diskussion ist. Ich hab mir das nochmal grob in Sierra Leone angeschaut wo es die 4000 alt_name_x gibt. Mir scheint, dass es sich dabei auch eher um sprachliche Variationen handelt, aber hab da natürlich keine Ahnung. Auf jeden Fall seh ich aber auch keinen wirklichen Grund, warum da nicht das Semikolon Tagging verwendet wurde. Für die menschlichen Augen sind die multiplen Tags halt einfacher zu erfassen, das ist glaub ich ein Knackpunkt bei der gesamten Geschichte.

Auf jeden Fall gefällt mir der Vorschlag, darauf hinzuweisen dass immer erst die semantisch reicheren name Tags verwendet werden sollte, dann erst alt_name und im absoluten Ausnahmefall wenn die 255 Zeichen von alt_name nicht ausreichen noch alt_name_1. Aber dann sollte man sich auc nicht wundern wenn das nicht ausgewertet werden kann (sollte eigentlich auch nicht vorkommen der Fall). Problematisch ist, dass viele wahrscheinlich überfordert sind mit der Unterscheidung zwischen den einzelnen Name-Tags, oder auch Operator und Brand etc. Da muss wahrschienlich mehr Arbeit ins Wiki gesteckt werden.

Und name_1 is halt leichter, und der Editor machts ja auch so und es steht sogar im Wiki, da darf man sich nunmal nicht wundern...


Also Fazit:
1. gibt es einen Bugtracker Report dazu im ID? Ich hab keinen gefunden
2. Weiß jemand wie man mal auswerten kann seit wann der name_1 benutzt wird oder wie der mit ID changesets zusammenhängt (oder mit Mappern die vorher ID benutzt haben, das wär die Königsaufgabe wink)
3. Kann ich name_1 und alt_name_1 aus dem Wiki hauen? zumindest aus dem deutschen? Oder wo müsste man dazu noch diskutieren etc? raushauen = empfehlen das nicht zu verwenden etc.

Last edited by Hakuch (2016-01-06 13:27:11)

Offline

#18 2016-01-06 13:39:25

gormo
Member
Registered: 2013-08-01
Posts: 2,030
Website

Re: alt_name und name_1 - Voting

Danke für deine Analyse!

Hakuch wrote:

3. Kann ich name_1 und alt_name_1 aus dem Wiki hauen? zumindest aus dem deutschen? Oder wo müsste man dazu noch diskutieren etc? raushauen = empfehlen das nicht zu verwenden etc.

Nein.

Du kannst im Wiki schreiben, dass u.a. der iD das so verwendet, aber dass das nicht empfohlen ist, mit Verweis auf diesen und den anderen Forums-Thread. Und hoffen, dass niemand das anders sieht.

Ansonsten musst du die Diskussion im Wiki lassen (habe ich neulich schmerzhaft erfahren müssen). Problematische Wiki-Seiten-Edits werden im Wiki diskutiert.

Wir hier im Forum sind halt nicht die einzige DE-OSM-Community. Es gibt noch den Teil auf den Mailinglisten und den Teil, der nur im Wiki diskutiert...

Last edited by gormo (2016-01-06 13:40:12)


OSM hat nicht das Ziel bis Ende des Monats einen vollständigen Datensatz der Welt zu enthalten.
(nach S.W.) - Aber weil die Welt vielfältig ist, weil sie auch im Detail interessant ist, mag ich genaue Karten (nach C.)

Offline

#19 2016-01-06 21:04:20

Hakuch
Member
Registered: 2014-03-16
Posts: 638

Re: alt_name und name_1 - Voting

vielleicht könnt ihr mir ja mal helfen, ich befürchte, dass der ID Entwickler da nicht so ein Problem drin sieht neutral

https://github.com/openstreetmap/iD/issues/2896

Offline

#20 2016-01-06 21:56:32

R0bst3r
Member
Registered: 2015-04-23
Posts: 533

Re: alt_name und name_1 - Voting

Seh ich auch nicht ... so lange man sich auf keine bessere Lösung einigt.
Wie soll man denn mehrere Namen, Telefonnummern usw. beschreiben?

Jede bisher vorhandene Lösung wird von irgendeiner Gruppe abgelehnt und Verbindlichkeiten gab es in OSM noch nie ... viel Erfolg!

Offline

#21 2016-01-06 22:12:47

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 3,504
Website

Re: alt_name und name_1 - Voting

gormo wrote:

Mit dieser Overpass-Abfrage müsste man eigentlich viele der _n-Tags finden: http://overpass-turbo.eu/s/dzY .

Danke...

Mit dieser Abfrage habe ich Elemente gefunden, wie

lit=yes + lit_1=yes... was nun wirklich Quark ist.


Sven

Last edited by streckenkundler (2016-01-06 22:13:01)

Online

#22 2016-01-06 22:18:43

Hakuch
Member
Registered: 2014-03-16
Posts: 638

Re: alt_name und name_1 - Voting

R0bst3r wrote:

Seh ich auch nicht ... so lange man sich auf keine bessere Lösung einigt.
Wie soll man denn mehrere Namen, Telefonnummern usw. beschreiben?

Jede bisher vorhandene Lösung wird von irgendeiner Gruppe abgelehnt und Verbindlichkeiten gab es in OSM noch nie ... viel Erfolg!

Das Hauptproblem ist ja, dass das in ID nicht mal als Tagginglösung gedacht ist, sondern nur als "da will jemand einen tag eingeben den es schon gibt, bevor er den löscht setz ich mal eine _1 dahinter, dann merkt er ja dass da was nicht stimmt und er löscht keine daten". Das heißt, es ist nur eine Absicherung aber entspricht keinerlei Taggingschema. Die User verstehen es unter Umständen aber als Taggingschema, und dann kommt da halt auch so ein absoluter Mist wie hier gut zusammengefasst bei raus: http://forum.openstreetmap.org/viewtopi … 88#p497888

Offline

#23 2016-01-06 22:19:31

kreuzschnabel
Member
Registered: 2015-07-03
Posts: 5,997

Re: alt_name und name_1 - Voting

R0bst3r wrote:

Wie soll man denn mehrere Namen, Telefonnummern usw. beschreiben?

Wie schon gesagt: mit beschreibenden Schlüsseln wie old_name=*, alt_name=* oder loc_name=*. Dann stehen die Namen nicht nur numeriert nebeneinander, sondern es ist auch kodiert, welcher Name in welchen Kontext gehört. Kannst du da wirklich keinen Mehrwert drin sehen?

Konstrukte wie name=foo, name_1=bar, name_2=rumpel und name_3=stilzchen sagen nicht mehr aus als name=foo;bar;rumpel;stilzchen. Es werden einfach Werte aufgelistet, ohne zu sagen, welcher Wert wie aufzufassen ist.

Wenn wirklich die Notwendigkeit besteht, einem Element mehrere Teflonnummern zu geben, finden wir da auch einen entsprechenden Weg.

--ks

Offline

#24 2016-01-06 22:36:25

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 3,504
Website

Re: alt_name und name_1 - Voting

Hakuch wrote:

Das Hauptproblem ist ja, dass das in ID nicht mal als Tagginglösung gedacht ist, sondern nur als "da will jemand einen tag eingeben den es schon gibt, bevor er den löscht setz ich mal eine _1 dahinter, dann merkt er ja dass da was nicht stimmt und er löscht keine daten".

Sicher kommt dabei Mist heraus... wie ein Straßenobjekt mit lit=yes und zugleich lit_1=yes... Aber... von einem unbedarften Nutzer kommt auch das heraus: http://overpass-turbo.eu/s/dAL

hier mal herausgegriffen: http://www.openstreetmap.org/way/290393925 Da kann man sicher weiterarbeiten... man sieht, was der Nutzer meint...

Im Sinne der Fehlerprüfung wäre das eine Routine die in Standardanwendungen (Osmose, oder KeepRight!) aufgenommen werden sollte... Interessant wäre es, wie groß die Anzahl der Key-Werte mit Key_n=* wäre... Im Bereich Berlin und südliches Brandenburg waren es nicht sehr viel...

Sven

Online

#25 2016-01-06 22:48:58

R0bst3r
Member
Registered: 2015-04-23
Posts: 533

Re: alt_name und name_1 - Voting

Somit sind wir wieder soweit wie bei den letzten 10 Diskussionen.
Keiner findet TAG_1 TAG_2 etc gut.

Semikolon kann verwendet werden, sollte aber wie im WIKI immer wieder steht vermieden werden. Auswerten kann es kaum einer (Renderer, Karten, taginfo, XAPI, ...) obwohl durchaus machbar (Walter hat mal ein schönes Beispiel gezeigt), und viel schlimmer noch: Qualitätstools melden es als Fehler und auf der Karte werden Semikolonwerte ausgeblendet, während TAG, TAG_1, TAG_2 wenigstens angezeigt werden.

Meines Erachtens liegt das Problem somit nicht beim taggen, sondern an der mangelnden Umsetzung und er damit verbundenen Empfehlung (siehe QS-Tools) es nicht zu verwenden. Jeder Neuling, der richtig taggt und seine Objekte nicht auf der Karte findet, wird die Lösung mit den Nummern verwenden. Je länger das so weiter geht, umso mehr nummerierte Tags wird es geben.

Man sollte also nicht bei ID einen Fehler einstellen, sondern z.B. beim Renderer von openstreetmap.org, bei osmose, ....

Offline

Board footer

Powered by FluxBB