Ok, dass ist offensichtlich ein anderes Beispiel und fällt unter Indoormapping. Da kenne ich mich nicht mit aus. Aus dem Bauch heraus würde ich da kein Abtrennen der Infos in einen Extra-Node für richtig halten, da ja mit dem Indoor-Mapping schon die genau Position bis hin zur Position der Ein- und Ausgänge erfasst werden. Ein Herauslösen in ein Extra-Node zerstört hier sogar wichtige Informationen, wenn ich das auf die Schnelle richtig sehe, nämlich die Information, auf welchen Level (also in welcher Etage) sich das Fastfoodlokal befindet (hier offensichtlich Level=0)
Offenbar gibt es ein Faible für alt_name: https://www.openstreetmap.org/node/7123944912/ oder https://www.openstreetmap.org/node/2781240548/. Ist das nötig? Die Suche findet doch alle Begriffe, die in “name” stehen. Mal abgesehen davon, dass ich alt_name nur für echte Alternativnamen nutzen würde, nicht für Schreibfehler.
Ebenfalls merkwürdig: https://www.openstreetmap.org/node/5226312921/history. Auch wenn ich das von hier aus nicht beurteilen kann, bezweifle ich, dass es in einem McDonald’s keine Toilette geben soll.
Ich halte es auch für unnötig, in alt_name alle erdenklichen Schreibweisen und Schreibfehler zu hinterlegen. Dafür ist alt_name nicht gedacht.
Hallo,
KartenKurator hat den ersten Änderungssatzkommentar wegen der Flächen-POI-Sache am 7. Juni 2020 um 11:57 UTC bekommen. Seitdem hat er/sie fleißig weitergemacht. Ich habe die Bitte bekräftigt, das Ersetzen zu unterlassen und eine Sperre angedroht.
Per Direktnachricht habe ich um die unverzügliche Beachtung der Änderungssatzkommentare gebeten.
Wenn weitere Änderungen hochgeladen werden, wird er/sie ein Fall für die DWG.
Zum konkreten Fall, der Saturn-Filiale im Real in Karlsruhe-Durlach: Dieser war als Fläche im Gebäude gemappt, d.h. jemand hat sich die Mühe gemacht, seine Flächenausdehnung zu erfassen. KartenKurator hat die Tags, die sich auf den Laden bezogen auf einen Node übertragen und nur die Adresse an der Fläche belassen. Dass das schlechte fachliche Praxis ist, dürfte offensichtlich sein.
Viele Grüße
Michael
Danke, dann warten wir mal ab.
halte ich ebenfalls für unglaubwürdig. Andererseits halte ich es auch nicht für wahrscheinlich dass es dort unisex Toiletten geben soll, wie es zuvor getaggt war.
ob man Schreibfehler erfassen will, sofern sie auf den Schildern so vorkommen, kann man diskutieren, ich würde sie aber auch nicht als alt_name sehen. Warum aber Varianten nicht damit getaggt werden sollen verstehe ich nicht. Welchen tag hältst Du dafür für besser geeignet?
https://wiki.openstreetmap.org/wiki/Key:unisex
unisex=yes ist auch bei Friseur in Verwendung. Wenn nur der Zugang zu den Toiletten oder ein node eingetragen ist:
Was sollen solche “Varianten” für einen Sinn machen?
name=Aldi Süd
alt_name=Aldi
oder
name=McDonald's
alt_name=McDonalds
alt_name_1=Mc Donalds
alt_name_2=Mc Donald's
Ich finde die Frage gar nicht so trivial. Wenn jemand zu Aldi geht, sagt er Aldi und nicht Aldi Süd. Der Aldi (Süd) hier bei mir wird von der Firma ALDI GmbH & Co. KG betrieben. Aldi Süd ist eine schlecht fassbare Bezeichnung einer Unternehmensgruppe. Ich finde nur zwei Firmen die tatsächlich Aldi Süd heissen (ALDI SÜD Dienstleistungs-GmbH & Co. oHG & ALDI SÜD Dienstleistungs-GmbH) und die sind keine Supermärkte. Jetzt steht zwar Aldi Süd auf dem Schild über dem Eingang, aber der Name (name=) muss ja nicht zwingend dem Schild entsprechen…bspw “Landeshauptstadt Stuttgart” ist nicht name=.
Zurück zu Deiner Frage: Ich finde das Tagging jetzt nicht so abwegig, dass man da keinen Sinn darin sehen kann.
Es hat keinen Sinn, weil bereits im name-Tag “Aldi” steht. alt_name ist hier kein alternativer Name, sondern nur eine Verkürzung von name. Jede Suche sollte das finden, ohne dass es extra getaggt ist.
Hallo,
ich finde die Duplizierung von name=“Aldi Süd” + alt_name=Aldi übertrieben. Das name-Tag sollte genügen. Wer nämlich eine gute Suchfunktion anbieten will, wird die Daten, auf die gesucht werden soll, in einem gewissen Maße vorverarbeiten, indem man die Zeichenketten in ihrer Schreibweise normiert (Kleinschreibung, keine Akzente) und an worttrennenden Zeichen zerlegt, also an Leerzeichen, Bindestriche, Komma usw. Zudem ist es IMHO für eine gute Suchfunktion sinnvoll, nicht auf die Gleichheit/Ähnlichkeit mit der gesamten Zeichenkette zu achten, sondern schon das Übereinstimmen eines Wortes der Zeichenkette (also “aldi” in “aldi süd”) für einen Treffer berücksichtigt.
Aldi doppelt zu erfassen – einmal mit Süd, einmal ohne – wirkt für mich ein Stück weit wie Mapping für eine zu einfach gestrickte Suchmaschine. Ergänzen wir als nächstes noch wrong_name=Adli? 
Viele Grüße
Michael
Warum nehmen wir nicht Bundesrepublik Deutschland für name= statt “Deutschland”? Ist doch auch nur eine Verkürzung und wer Deutschland sucht, wird das schon finden ^^^so die Argumentation. Oder Freie und Hansestadt Hamburg? Ich würde den Aldi auch nicht in der strittigen Form erfassen. Ich sage nur, es gibt keine Regel, sondern es wird nach Gefühl getaggt. Und dann kann sich halt auch jemand anders entscheiden.
der Vergleich hinkt, denn für die Bundesrepublik und die Freie Handelsstadt gibt es official_name. An unserem Beispiel wäre das dann also
name=Aldi
official_name=Aldi Süd
was ich aber ebenfalls für übertrieben halte. Und ein alternativer Name wird es trotzdem nicht.
Akzeptabel fände ich dagegen bei unseren österreichischen Nachbarn
name=Hofer
alt_name=Aldi Süd
weil für den Urlauber aus Süddeutschland das bereits am Logo erkennbar ist.
PS: Und dann gäbe es noch das short_name…
Der User hat auf die verschiedenen Changeset-Kommentare reagiert, u.a. in https://www.openstreetmap.org/changeset/86301287. Ich habe ihn nochmal nach hier eingeladen.
Hallo zusammen,
zunächst einmal vielen Dank an alle die meine Changesets kommentiert, mich per PM kontaktiert oder die Mühe gemacht haben hier im Forum zu schreiben.
Im folgenden möchte ich mich kurz zu meinen Beweggründen zu den Änderungen äußern:
OpenStreetMaps ist in meinen Augen ein wunderbares Projekt. Ich liebe den OpenSource Gedanken dahinter und bewundere die einfache Möglichkeit für jedes Individuum zur bestmöglichen Karte der Welt beizutragen. Umso schöner finde ich es, wenn Leute es schaffen Diensten wie Google Maps (sprich kommerziellen Monopolisten) und ihren Alltag mittels OSM bewältigen können. Daher versuche ich auch explizit die Nutzererfahrung auf mobilen Endgeräten zu verbessern.
Vor diesem Hintergrund versuche ich (neben dem Mappen von bisher unerfasstem) auch die bestehende Datenbasis zu „optimieren“, das allerdings im Rahmen von Empfehlungen die ich über die Jahre aus der Community erhalten habe.
Eine dieser Empfehlungen ist das erfassen von POI als Punkte, also nicht im Rahmen eines Umrisses. Zum einen soll dies ein Editieren leichter machen, was ich nachvollziehen kann.
Beispiel: Ein Supermarkt schließt. Ein anderes Geschäft eröffnet. So kann der alte Poi einfach gelöscht werden und ein neuer ergänzt, ganz unabhängig vom Gebäude selbst. Weiterhin ist so ein erfassen auch leichter bei Gebäuden mit mehreren Shops (z.B. Einkaufscenter). Alternativ würden ja durch gebäudeflächen mehrere Shops überlagert, die sich auf unterschiedlichen Ebenen befinden
Außerdem ist das erfassen von POIs problematisch im Hinblick auf die Darstellung in manchen Apps. So wird ein „McDonald‘s“ in „OSMAnd“ als Fast Food Restaurant Kategorisiert, wenn er als Punkt eingetragen ist und als Gebäude, wenn er mit der Fläche als Einheit erfasst ist. Dies führt zu fehlerhaften Suchergebnissen und ist wenig einheitlich, wenn einige Filialen so und andere so erfasst sind.
Zum Thema Alt Names: Habe bisher mehrere Apps ausprobiert und einige haben eine relativ schlechte Suchfunktion. So wird beispielsweise ein „McDonald‘s“ nicht gefunden, wenn „McDonald“ oder „Mc Donalds“ gesucht wird.
Aus diesem Grund habe ich mir überlegt, alternative Schreibweisen über Alt_name zu erfassen, da dies die besten Resultate über alle Apps liefert und ich es zumindest persönlich als wenig schädlich für die Kartenbasis ansehe.
Ich sehe allerdings auch die Problematik, dass für das richtige funktionieren der Apps deren Entwickler verantwortlich sind und nicht wir Mapper uns mit der Kartierung nach denen richten sollen. Allerdings sehe ich aktuell mehr Positives darin, eine leicht angepasste und zeitgleich „ wenig destrukive“ Strategie zu wählen, der OSM für alle besser in der Benutzung macht.
Denn OSM wird auch nur dann erfolgreicher werden, wenn mehr Leute diesen Dienst nutzen und kennen. Und ich finde es schade wenn so viele Menschen Ihre Zeit und und Mühe in ein tolles Projekt investieren, dass vergleichsweise wenig Beachtung findet. Dagegen stellen auch viele Nutzer Ihre Zeit einem Milliardenschweren Konzern wie Google kostenlos zur Verfügung, bei dem eben nicht alle davon profitieren können, denn dort gehören die Daten nur einem. Und ein Problem was ich da sehe ist die unterschiedliche Qualität der OSM Apps. Und wenn diese durch leichte Anpassungen in der Datenerfassung (wie eben durch die Alt_names) verbessert werden können, bin ich bereit diesen Mehraufwand zu leisten.
Ich hoffe dadurch wurden meine Absichten verständlich und freue mich auf euer Feedback.
Im besten Sinne
KartenKurator
Sorry, aber ich habe für diese/deine “alles zurück auf Nodes”-Aktion keinerlei Verständnis …
Auch schon erlebt, ein Mapper on mission, der korrekt erfasste historische Kirchen und Kapellen aufspaltete in
“Restgebäude” und “place_of_worship”-Node - dass dann bei der Aufteilung der Tags Mist rauskam war erwartbar.
In diesem Disk-Beispiel
https://www.openstreetmap.org/node/7599642857
ist das wheelchair=yes dochwohl primär die Eigenschaft der Immobilie und nicht des Nutzers.
Es gibt gute Gründe (Kleingewerbe)nutzung als Node/Poi zu erfassen,
wenn monofunktionale Nutzungen allerdings korrekt als Fläche erfasst sind, dann ist dies - die Arbeit anderer - bitte zu respektieren.
+1
Wir mappen nicht für Auswerter. Wenn Auswerter Daten falsch interpretieren, müssen die Auswerter ihr Verarbeitungsroutinen anpassen, nicht wir unsere Daten… Das ist genauso mit den Namen… Es ist nicht unsere Aufgabe dem Auswerter alle möglichen und unmöglichen Namensvorschläge anzubieten.
Der Tag name_1 ect… ist aus guten Grund für deprecated erklärt…https://wiki.openstreetmap.org/wiki/Proposed_features/Remove_suffixed_name-tags_from_wiki Für mich gilt das für alle Varianten des name-Tags, also auch alt_name=*… Ansonten kannst du bitte als name_99=MäckDoof auch noch aufnehmen, Die Variante hattest du vergessen.
+1
Blauäugiges verschieben von Informationen von Fläche auf Punkt würde ich ein stückweit als Vandalismus ansehen.
Sven
Als erstes, danke dass Du Dich hier zu Wort gemeldet hast. Ich verstehe jetzt Deine Motivation für die Edits, möchte Dir aber auch Argumente für die Flächen nennen.
je nach Fall ist das komplette Löschen auch bei nodes nicht angebracht, manche Eigenschaften wie die Adresse (oder bei ways meistens der Umriss 
) bleiben auch.
das Überlagern von Nutzern in mehrstöckigen Gebäuden kann man mit “level” und evtl. layer sortieren.
Die Anwendungen müssen sich auf das Einstellen, was von OpenStreetMap kommt, nur weil manche Apps evtl Probleme mit Flächen haben, können andere Anwendungen dagegen mehr mit Daten anstellen, wenn sie die räumliche Ausdehnung enthalten und nicht nur Punkte für eigentliche Flächen. Sobald man mehr Details mappt (was bisher immer der Fall war) und Dinge in Dingen sind, ist der implizite räumliche Bezug vermutlich am Nachhaltigsten, was die Skalierbarkeit angeht (gemeint ist, anstatt mühsam manuell Bezüge herzustellen, z.B. per Relation, stehen die Sachen automatisch bereits im Bezug).
Gebäude und Restaurant sollten idealerweise 2 unterschiedliche OpenStreetMap Objekte sein, da gebe ich dir völlig Recht, nur ist die Fläche dabei grundsätzlich besser als ein Punkt fürs Abbilden von allem mit einer gewissen Ausdehnung. Die Punkte kann Software automatisch erzeugen, die Fläche ist dagegen verloren wenn man nur einen Punkt hat.