Jetzt schon Bürgersteige mappen?

Einige Beispiele:
Platzlinien / Einzeln gemappte Bäume:
http://www.openstreetmap.org/?lat=47.989692&lon=7.884064&zoom=18&layers=M

Eine Pollerorgie in Dortmund:
http://www.openstreetmap.org/?lat=51.511765&lon=7.464321&zoom=18&layers=M

Einzelne Bereiche eines Parkplatzes einzeln gemappt (POI Inflation):
http://www.openstreetmap.org/?lat=48.963553&lon=10.909777&zoom=18&layers=M

Na ja wie bereits gesagt wurde hat jeder seine eigenen Vorstellungen was wichtig ist und was nicht.

Nur eins ist klar: Wenn mal die ganze Welt so detailliert gemappt ist, passt das Planet-File auf keine Festplatte mehr drauf. :wink:

Mmh, ging es hier nicht um Augsburg oder doch um Freiburg, Dortmund und Treuchtlingen? :wink:

Hallo Frederik,
ich bleibe bei meiner Meinung, da ich statt Argumente, lediglich Befürchtungen registriere. Du hast Recht: eine Karte mit zu viel Inhalt ist schlecht, weil unleserlich, eine Geodatenbank die nicht aktualisiert wird, verliert schnell an Wert. Eine Geodatenbank ist aber natürlich umso wertvoller, je mehr Informationen sie liefert. Die besagten Gehwege die hier stellvertretend für ein großeres Problem - nämlich die wachsende Kompexität von OSM stehen, haben in der GIS Welt ihre Berechtigung - etwa bei der Planung unterirdischer Leitungen, der sog. Regensteuer, Landschaftsplanung.

Natürlich ist die Frage nach der Datenaktualität legitim, aber bisher meistert die Community die Datenaktualisierung so ziemlich gut, oder? Und die Mitgliederzahl nimmt auch weiter zu.

Hallo Chris

Da hast du ja einige sehr treffende Beispiele gefunden.

  • Die Platzlinien sind wirklich übertrieben und enthalten eigentlich keine wirkliche Informationen.
    Die Bäume hingegen scheinen mir vereinzelt zu stehen. Da gibt es krassere Beispiele.
  • barrier=bollard kann man auch an eine Linie setzen.
    Der Renderer kümmert sich dann um eine angemessene Platzierung.
  • Der Parkplatz ist etwas daneben. Der wurde offensichtlich aufgeteilt,
    um die Grünflächen dazwischen einzutragen. Das geht aber auch ohne Teilung.

In der Tat sind das (bis auf die Bäume) Bespiele, wo jemand (wahrscheinlich) wegen der Darstellung etwas übertrieben hat.

Edbert (EvanE)

Hi Chris
Sehr schöne Beispiele!

Das Platzlinientagging ist ein Mißbrauch von wichtigen Tags.
barrier=line und barrier=net lassen sich ja noch rausfiltern. Aber es ist trotzdem (vorsichtig ausgedrückt) keine wünschenswerte Verwendung des Tags.
highway=path für die Spielfeldlinien !?! Das kann ja wohl nicht sein! Das ist nicht akzeptabel!

Die Pollerorgie konnte ich nicht erkennen, nur die P-Orgie. :wink:

Das vereinzelte Mappen von Parkplätzen führt in Vektorkarten mit Suchfunktionen zu absolut undiskutablen Ergebnissen. In kleinen Handgeräten ist die Kapazität der Listen zum einen begrenzt, zum anderen macht die Auflistung der einzelnen Parkbuchten das Suchergebnis unbrauchbar. Wie soll man da noch eine Übersicht über die Parkplätze im näheren Umkreis erhalten? Der Mapper hat keine Möglichkeit eingebaut, mit der die für verschiedene Karten unbrauchbare Anhäufung von P durch Filterung dezimiert werden könnte. Eine große Fläche für amenity=parking ist wesentlich sinnvoller. Die einfassende Rasenfläche gliedert den Platz doch wohl genug. Und wenn das partout nicht reicht, dann muß das vor einiger Zeit diskutierte Taggingschema für die einzelnen Stellflächen bemüht werden, damit man diese Detailanzeigen rauswerfen kann. So ist es jedenfalls nicht sinnvoll.
Wenn diese Unsitte um sich greift, kann man entweder Straßen mit Parkbuchten irgendwann vor lauter P nicht mehr sehen oder man ist gezwungen die P früher auszublenden, stärker zu verdrängen oder was auch immer. Das wiederum erschwert dann die Parkplatzsuche mit Hilfe einer Rasterkarte, weil man dann möglicherweise so stark in die Karte hinein zoomen muß, daß die Gesamtübersicht beeinträchtigt wird. Diese Detailverliebtheit wird der Karte irgendwann also schaden.

Gruß
tippeltappel

Oder die Straße wird einfach nur nicht als Fläche dargestellt und sie hat deshalb keinen Anschluss. Das von diesen Flächen in kleineren Zoomstufen nichts übrig bleibt ist derzeit noch ein Mangel der Clusterstraegie.
Den gibt es übrigens an anderer Stelle auch. Bei Bahnlinien haben sich viele Nutzer schon gewünscht das mehrere Gleise zu einer Strecke zusammengefasst werden. Autobahnen hingegen bleiben immer in ihrer vollen (Zeichen-)Breite.

Ich gebe dir bei den ersten Einschätzungen recht. Beim Parkplatz teile ich deine Meinung nicht! Schon gar nicht mit der begründung das der der Garmin irgendwann keine Kapazität hat. Das ist genau wie im anderen Thread geschrieben, alles was kleiner 4m Durchfahrtshöhe ist, ist hgv=no. Weil wir von richtigen Lkw sprechen.
Genauso muss es Lösungen für Parkplätze geben. Bei Openlayers werden auch Cluster gebildet. Wer also weniger "P"s haben möchte muss nur vorher nach bestimmten Regeln zusammenfassen.
Und nur weil die Erstellung von Karten immer schwerer wird auf Informationen zu verzichten halte ich für Falsch. Die Wirklichkeit ist nicht immer einfach. Man muss sie nachher vereinfachen. Wenn ich diesen Schritt aber bei der Datenerfassung schon gehe, dann werde ich später die Details nicht wieder hinzufügen können.

PS Dein Einfahrtsproblem kannst du vielleicht reduzieren in dem du alles was service=driveway und und service=parking_asile getagt ist rauswirfst.

Bitte einfach mal beim Thema bleiben. Die angefangenen anderen Themen

  • Osmarender und Layer
  • übertriebenes Detailmapping
    sollten nicht das eigentliche Thema verwässern, macht bitte neue Threads auf.

Die Ursprungsfrage war, ob Bürgersteige gemappt werden sollen.

a) sollen Sie nun aus Eurer Sicht?

b) wie sollen sie gemappt werden?

  • an der Straße per sidewalk=both/left/right/none [1] würde ich dann nehmen, wenn ich keine Details ergänzen will/kann, also z.B. abgesenkte Bordsteine.
  • als extra Weg per highway=footway (ich sehe nicht ein, warum dann aber noch zusätzliches Tagging a la [4]

c) Wiki-Probleme

  • Proposed features/Sidewalk [2] bringt nichts zusätzliches zu Sidewalk [3] und sollte weg, finde ich (nein, ich machs nicht, ich habe andere Prios).
  • Proposed features/Sidewalk as separate way [4]: wozu das? Einfach nur zusätzlich ein weiteres Tag, Basis bleibt highway=footway und rendered als ebenso?
    Das trägt doch alles nur zur Verwirrung bei. Jeder taggt wie er/sie will, ein Neuer kann sich raussuchen, wie oder dann eher gar nicht.

Kommen wir hier zur Übereinstimmung, das Bürgersteige relevant sind für OSM und evtl. noch, wie sie zu taggen sind?

Dietmar

[1] http://wiki.openstreetmap.org/wiki/Sidewalk
[2] http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk
[3] http://wiki.openstreetmap.org/wiki/Sidewalk
[4] http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way

Ich sehe da keinen großen Unterschiede zur Frage ob Radwege separat gemappt werden sollen. Das wurde auch
schon hinreichend diskutiert, wie üblich ohne Ergebnis. Es gibt halt für alle Möglichkeiten Pros und Contras.

Chris

Für mich stellt sich die Frage, ob Bürgersteige/Fußwege gemappt werden sollen, nicht ernsthaft. Natürlich gehören sie in OSM, genauso wie Radwege oder Eisenbahnlinien.

Davon zu unterscheiden ist, finde ich, die Frage, wie sie gemappt werden sollten. Dabei ist meines Erachtens einmal sicher zu stellen, dass eine vernünftige Kartendarstellung erfolgt/erfolgen kann (einschließlich eines gegebenenfalls notwendigen Wegfilterns) und andererseits diese Daten dann auch noch gewartet/aktualisiert werden können. Dabei scheint es mir wichtig zu beachten, dass Bürgersteige/Fußwege, die nicht auf einer Karte erscheinen, in großer Gefahr sind, bei der Wartung vernachlässigt zu werden!

Ich handhabe das Mapping von Bürgersteigen/Fußwegen derzeit so, das ich nur die Bürgersteige/Fußwege einzeichne, die deutlich von der Straße abgesetzt sind. Sobald sie direkt an der Straße verlaufen, enden sie halt mit einem gemeinsamen node auf der Straße. Sinnvoll erscheint es mir aber, bei direkt, also ohne Abtrennung/Absetzung von der Straße verlaufende Bürgersteige/Fußwege dadurch zu kennzeichnen, dass der entsprechende tag dem jeweiligen Straßenabschnitt hinzugefügt wird. Da könnte man auch noch ergänzen, ob etwa ein abgesenkter Bordstein vorhanden ist.

Also wenn ich den letzten Absatz lese, dann habe ich ganz große Angst.
Warum?

  • es gibt keine Karte die das darstellt insofern stellt sich die Frage der Wartbarkeit dennoch. Insbesondere was die Absenkungen des Bordsteins angeht.
  • Wenn du jedem Straßenabschnitt ein Merkmal Fußweg zu ordnen möchtest, ist das wahrscheinlich noch ok, da sichd as Merkmal nur selten zwischen zwei Querstraßen ändert. Aber wenn jetzt angefangen wird jede Absenkung zu erfassen und wo möglich noch getrennt nach links oder rechts der Straße, dann werden unsere Straßen bald nur noch Stückwerk, welches kein Renderer mehr zusammensetzen kann. Dann wird es auch keine Straßennamen mehr geben etc.

Als Beispiel nehme ich gerne diese Straße hier:
http://www.openstreetmap.org/?lat=51.092739&lon=13.71986&zoom=18&layers=M
Hier sind jetzt noch keine Fußwege als Key an der Straße erfasst, sondern nur die Parkmöglichkeiten und die zulässig Höchstgeschwindigkeit.
Damit ist die Burgsdorffstraße zwischen Großenhainerstraße und Reichenbergerstraße schon heute in 5 Teile gegliedert. Würde man jetzt noch jede Bordsteinabsenkung erfassen, käme man bei großzügiger Auslegung schon auf 6 Teile zwischen Wahnsdorfer und Reichenberger Straße. Was gegenüber heute eine Verdopplung wäre.
Wenn man sich jetzt noch an die Vorschläge aus Mühlheim zum Rohlstuhlmapping hielte, also ein Wegstück vor und nach der Absenkung zu mappen, in welchem der Bordstein von normal auf abgesenkt übergeht, dann wären wir bei bei 10 Segmenten und wenn man das dann noch genauer (Luftbild) nach links und rechts unterscheidet bei noch mehr Segmenten. Das hielte ich nicht für wirklich sinnvoll.

Mir ist da immer noch der Aufschrei in Erinnerung wieso man einen Kreisverkehr für eine Buslinie auftrennen würde.

Könnte man den ganzen Aufwand nicht vermeiden, wenn highway=residential impliziert, dass diese Straße Bürgersteige hat? Damit dürfte die Masse der Bürgersteige datentechnisch ohne zusätzliche tags erfasst sein. Dann müssen wir uns nur noch Gedanken über die Ausnahmen in diesen Fällen machen.

Dies Methode ist aber nichts für die Detailverliebten, die auch die Breite, die Oberfläche usw. eines Bürgersteiges taggen wollen :roll_eyes:

Meiner Meinung nach gehören Bürgersteige schon in die Datenbank von OSM. Auf der Karte sollten die direkt an der Straße laufenden Bürgersteige allerdings nicht erscheinen, um die Übersichtlichkeit zu gewährleisten. Wenn jemand die Bürgersteige für spezielle Karten oder Fussgängerrouting benötigt sollte er sie aus der Datenbank auslesen können.

Vor zwei Jahren habe ich die Straßen meines Wohnortes gemapt und dabei die Bürgersteige als Tags an die Straßen gehängt, nach dem Muster: footway=both; oder footway:left=track und footway:right=none.
Nach einer damaligen Diskussion hier, habe ich das so gemacht. Das von okilimu unter [1] verlinkte Schema passt meiner Meinung nach. Nur muss ich dann die, bereits von mir an die Straßen gehängten footway-Tags ändern?

Im kommenden Winter will ich die Straßen der Nachbarstadt genauer aufnehmen. Daher wäre mir recht, wenn es mal ein Schema geben würde das allgemein akzeptiert wäre und wo ich sicher sein kann, dass die eingtragenen Daten auch richtig verwendet werden können.

Allgemeine Akzeptanz ist das eine. Nachvollziehbarkeit und Umsetzbarkeit durch den “einfachen” Mapper sowie Auswertbarkeit (u.a. durch Renderer) ist m.E. genauso wichtig. Wir müssen über Schnittstellen hinaus denken.

Du machst es dir aber auch wieder sehr einfach. Also es gibt Anwendungsfälle da ist dies von Bedeutung. Nämlich bei der Frage Rohlstuhltauglich oder nicht auch die Querungen für eben jene Personengruppe fällt auf diese Art unter den Tisch.
Wenn wir weiterdenken, kommen ja noch die ganzen Hauptstraßen dazu und wenn wir dann schon Bürgersteige mit implizit erschlagen wie willst du es mit Fahrradwegen machen?
Wie willst du unterscheiden wo die Lage des Fußweges ist? kommt erst noch eine Reihe parkender Autos? etc. All dass kannst du versuchen implizit zu erschlagen. Du wirst aber dennoch soviele Ausnahmen haben, dass es günstiger erscheint die Dinge als Fläche zu erfassen und lieber eine Strategie zu entwickeln wie man in kleinen Zoomstufen aus Flächen Linien erzeugt.
Derzeit geht das nicht, daher gibt es highway=xy als Linien und area:highway=xy als umgebende Fläche. Und damit die Herren der Routingfähigen Daten auch glücklich sind jede Menge Fußwege, die eigentlich solche gar nicht sind, sondern nur die zwei aneinanderstoßenden Flächen überwinden machen.

Wenn ich deinen post #42 lese, bekomme ich den Eindruck, dass du es gerne einfach hättest :roll_eyes:
Ich habe nichts gegen besondere Anwendungsfälle, die besondere Daten erfordern. Nur stellt sich mittlerweile die Frage, ob diese Daten alle noch in OSM unter einer Datenbankebene mit unserem Datenmodell zu erfassen und auszuwerten sind.

Natürlich hätte ich es gerne so einfach wie möglich. Ich sage ja nur welche Konsequenzen es hätte, wenn wir versuchen Key-Value-Paare an die Wege zu heften, dann müssen wir die Wege auch immer dann trennen wenn sich eine Eigenschaft ändert. Und das wird mit Bordsteinkantenhöhen eher mehr als weniger werden. Wenn man hingegen Fußwege als Flächen erfasst, dann hat man das Theater nicht, weil man einfach einen Weg (meiner Meinung nach besser eine Relation) an die Grenzlinie heftet und dort die neue Eigenschaft die nur dort am Rand auftaucht einträgt.

Wir hatten so eine Diskussion bereits geführt. Sind Wege Relationen? Ist es besser statt Wege zu splitten für jede Eigenschaft eine Relation anzulegen?
Vergessen habe ich das alles nicht. Es hat nur keine Zustimmung gefunden. Vielleicht werden wir später mal Flächen als Objekte bekommen. Aber ich denke das macht es auch nicht einfacher.

Deswegen denke ich ja, dass wir verschiedene Datenbankebenen benötigen. Ebenen oder auch Relationen könnten helfen, um physikalische von virtuellen Eigenschaften zu trennen. Wir hängen mittlerweile einfach zuviele Sachen an die nodes oder deren Verbindungslinien. Die Splitterei bei der Veränderung nur einer Eigenschaft ist jetzt schon fast unüberschaubar und fehleranfällig. Aber die richtige Idee, wie das einerseits einfach zu erfassen und andererseits einfach auszuwerten ist, habe ich auch noch nicht.

Was sind denn Datenbankebenen? Also ich denke in OSM besteht alles aus Punkten. manche Punkte werden für Linien benutzt andere Punkte werden sogar als Begrenzug für Flächen benutzt. Mehr gibts nicht.
Wie man die Sache einfacher machen kann? In dem man brav filtert und filtert und nochmal filtert. Wenn ich bearbeite dann habe ich grundsätzlich alles was Boundary hat ausgeblendet. Ich will weder diese Grenzen verschieben noch will ich das ständig die irgendwelche Veränderungen daran vorgenommen werden.
Daher war ich ja der Meinung jede Eigenschaft in einen eigenen Weg zu packen und aus der Summe aller Wege zwischen zwei Punkten wird dann das richtige Element generiert.

Ok, Datenbankebene war wohl der falsche Begriff. Ich dachte an so etwas wie layer im Sinne einer grafischen Anwendung, um für verschiedene Themenbereiche verschiedenen Abbildungsebenen vorzuhalten, die wie transparente Folien übereinanderliegen und nach Bedarf ein- oder ausgeblendet werden. Da alles in OSM nur aus Punkten (nodes) besteht, sind die ways streng genommen schon Relationen, welche Bezüge zwischen Punkten beschreiben.

Der Ansatz hat was. Aber da bekommen wir wieder das Problem, den richtigen Weg aller übereinanderliegenden bei der Bearbeitung zu erwischen. JOSM, Potlatch usw. müssten gänzlich andere Arbeitsweisen und -hilfen entwickeln. Wie filtere ich einen Weg über n Punkte zur Bearbeitung heraus? Und wie mache ich das, wenn von meiner Änderung an diesem way nur eine Teilstrecke über n-x Punkte betroffen ist? Wie sehe ich, welche Eigenschaften des ways über n punkte für den gesamten way (oder mehr) oder nur für einen Teil gelten?