MENTZ GmbH/Diskussion und Kritik
MENTZ GmbH
Diskussionen
Rolltreppen
Hallo Zusammen, es gibt momentan zwei Möglichkeiten Rolltreppen zu Taggen. Die erste Methode ist die über Escalator zu machen wie es auf der folgenden Wiki-Seite: 4 beschrieben ist. die zweite Möglichkeit besteht über den Tag conveying auf folgender Seite zu finden: 5. Welche Methode scheint Ihr zu bevorzugen? Es scheint so als sei die erste Methode etwas älter und durchgesetzter bei Tag Info wurde 1812 mal der Tag Escalator vergeben und 412 mal der Tag conveying. --MentzDV (talk) 07:16, 14 August 2013 (UTC)
- Falls die Frage noch offen ist: Der Weg über conveying ist durch Abstimmung "abgesegnet" und mittlerweile auch häufiger verwendet, sollte also bevorzugt werden. --Tordanik 19:43, 29 August 2015 (UTC)
Aufzug
Ein weit verbreitet Diskussion fand in der Talk-de Mailingliste zu Aufzügen statt. Auf Grund dieser Diskussion haben wir uns entschieden den Aufzug nur als einen einzelnen Knoten darzustellen. Bei einer 2-D Modellierung scheint dieses kein Problem zu sein, was ist aber wenn es sich um eine 3D-Modellierung handelt. Wäre es dann nicht sinnvoll mit Knoten und Linien zu arbeiten um die einzelnen Ebenen darzustellen? Was meint Ihr dazu?--MentzDV (talk) 07:16, 14 August 2013 (UTC)
Fußwege
Vielen Dank an EinKonstanzer für diesen Kommentar zu den Fußwegen. Wir würden diesen Kommentar gerne nutzen um darüber zu Diskutieren. Wie ist die weit verbreitet Meinung zu diesem Thema? Oft ist es so wie z.B. in München das ziemlich viele Fußwege getaggt sind. Sollen Fußwege separat getaggt werden oder lieber durch den Tag sidewalk in die Straßen integriert werden? --MentzDV (talk) 15:49, 6 August 2013 (UTC)
- also ich würde auf die bauliche Trennung fokusieren --ToniE (talk) 15:59, 8 August 2013 (UTC)
- eigene Fußwege (statt sidewalk=[both|left|right]) entlang der Straße haben den Nachteil, dass man die Straße nur an explizit gemappten Punkten überqueren kann
- highway=sidewalk ist für mich keine gute Lösung zwischen separatem footway und sidewalk=both
- Parkbuchten (längs oder quer) akzeptiere ich als bauliche Trennung, da es zwischen den Buchten zumeist Möglichkeiten der Überquerung gibt
- dann müssen diese aber auch gemapped werden!
- parkende (Dauerparker?) Autos entlang des Bordsteins gehören m.E. aber nicht zu "Parkbuchten"
- es gibt leider auch Stellen, wo ein (highway=cycleway foot=yes, segregated=yes) direkt neben einem (highway=fooway) liegt
- das ist eindeutig: Mappen for the Renderer. Z.B. macht die AIO Garmin map aus Ersterem schon zwei Linien (dieser Renderer kann es also)
- Das anerkannte Tagging-Schema ist mittlerweile "*:lanes(:*)=", siehe lanes=*. Leider ist das noch nicht weiterentwickelt worden um auch Bordsteine und den Rest der Straße damit zu taggen, aber footway=* bzw. sidewalk=* mit den Werten "both/left/right/none" und cycleway=* funktionieren soweit ja auch. Für Parkstreifen/-buchten gibt es schon parking:lane=* ! --Skyper 13:44, 11 August 2013 (UTC)
- eigene Fußwege (statt sidewalk=[both|left|right]) entlang der Straße haben den Nachteil, dass man die Straße nur an explizit gemappten Punkten überqueren kann
- Wir würden die Fußwege einzeln erfassen aber nur direkt um den Bahnhof herum. --MentzDV (talk) 07:11, 12 August 2013 (UTC)
Kritikpunkte
Es wurden folgende Kritikpunkte zu unseren bisherigen Edits vorgebracht:
Gelöschte Tags und Elemente
Wir wurden u.a. bzgl. des Freiburger Bahnhofs darauf hingewiesen, dass wir korrekte Objekte bzw. Tags gelöscht haben. Wenn wir bisher etwas gelöscht haben, dann nur, wenn das aus unseren Quellen hervorgegangen ist.
- Diese Aussage ist falsch ! Dafür habe ich Beweise in der Datenbankhistorie. Darum nocheinmal die Bitte den Freiburger Hauptbahnhof komplett zurückzusetzten. - Danke. --Skyper 15:16, 4 August 2013 (UTC)
Sollten wir weitere Edits machen, werden treten wir erst mit dem User, der zuletzt erfasst hat, in Kontakt. Tag designation Um eine Beschreibung einzufügen, haben wir anfangs den Tag designation verwendet. Wir wurden darauf hingewiesen, dass dies falsch ist. Diesen Fehler haben wir bereits behoben und den Tag mit description ersetzt.
Rampen
Wir haben Rampen bisher folgendermaßen modelliert:
- Highway = steps
- Ramp = yes
Aus dem Wiki: [[1]] Wir wurden darauf aufmerksam gemacht, dass es zwei verschiedene Arten von Rampen gibt. Diese eben erwähnte Modellierung beschreibt eine Rampe, die direkt mit einer Treppe verbunden ist und nicht baulich von ihr getrennt ist. Die meisten von uns erfassten Rampen sind aber baulich getrennt. Also würden wir sie nun so erfassen:
- Highway = footway / path
- Incline = *% / up / down
- Wheelchair = yes
Aufzüge
Wir haben Aufzüge bisher als Kante modelliert und folgendermaßen getaggt:
- highway = elevator
- level = 0;1
Die Knoten haben jeweils das Level der Ebene bekommen, auf der sie liegen. Nachdem Kritik an dieser Umsetzung geäußert wurde, schlagen wir folgende Modellierung vor: Der Aufzug wird als node erfasst und bekommt den Tag highway = elevator. Auf jeder Ebene, die er bedient, schließen Fußwege an den Aufzug an.
Tunnelflächen
Wir haben bisher bei Unterführungen und Zwischengeschossen zusätzlich zu den Tunnelwegen Tunnelflächen angelegt. Folgende Tags haben wir gesetzt:
- area = yes
- building = yes
- description = Unterführung
- level = …
- layer = …
- tunnel = yes
Ein großer Kritikpunkt war, dass ein Tunnel kein Gebäude sei. Als Zwischenschritt hatten wir uns überlegt, den Tag building zu entfernen. Wir würden aber auch die Tunnelfläche komplett entfernen, wenn sie nicht gewünscht ist. Der existierende way bleibt.
geteilte Bahnsteigflächen
Diese Möglichkeit der Bahnsteigerfassung haben wir z.B. am Ostbahnhof in München vorgefunden. Wir haben diese Modellierung so übernommen, weil hier die Aussparungen der Aufgänge in Form von Löchern vorhanden waren. Da dies von einigen Seiten kritisiert wurde, haben wir über folgende Möglichkeit nachgedacht: Wir schlagen vor, die Bahnsteigflächen als Multipolygone zu erfassen. So wären die Aufgänge realitätsgetreu vorhanden, aber die Flächen müssten nicht geteilt werden.
Aufzählungszeichen (Komma oder Semikolon)
Wenn wir Aufzählungen verwendet haben, wurden diese mit Komma getrennt. Nachdem wir darauf hingewiesen wurden, dass es in OSM üblich ist, mit Semikolon zu trennen, würden wir dies verbessern.
- In Kirchzarten wurden Rund um den Bahnhof massiv Fußwege angelegt die die Bürgersteige darstellen sollen. Bürgersteige werden in OSM generell nicht eingezeichnet. Es wird vielmehr davon ausgegangen, daß in Ortschaften welche vorhanden sind. Sind keine Vorhanden dann foot=no. Zebrastreifen, Fußgängerampeln sind als highway=crossing einzuzeichnen. Auf dieser Basis ist auch ein Routing realisierbar. Entsprechende Änderungen sollten Rückgängig gemacht werden. Weiteres habe ich dem Bearbeiter (Rossner) geschrieben.--EinKonstanzer (talk) 17:45, 5 August 2013 (UTC)
- PS: Vielleicht bringt das euch was: DE:Key:sidewalk oder Sidewalks. Ich könnte mir vorstellen den Bürgersteig direkt als highway=sidewalk einzuzeichnen. Das würde das bisherige OSM-Schema NICHT STÖREN und wäre eindeutig hinsichtlich der Abgrenzung zum klassichen footway. Dinge die "NICHT STÖREN" sind in der Regel auch kein Problem...
Router (Routingprogramme)
Welcher Router nutzt die Daten? Gibt es ein Beispiel für Fußgängerrouting (z.B. mit - eurer - MP-Auswertung)? Zur Zeit werden in keep_rigth auch Wege als "nicht angeschlossen" angezeigt. --Geri-oc (talk) 09:30, 13 November 2013 (UTC)