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
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
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?
Wenn Du den von Dir zitierten Text noch einmal genau liest, wirst Du feststellen, daß ich durchaus die Möglichkeit für das Mappen einzelner Stellflächen sehe (auch wenn ich die auf Sonderflächen beschränken würde). Die Frage ist, wie man das macht. Der Parkplatz muß mit all seinen Details als Ganzes faßbar bleiben. Damit dem Bedarf nach Vereinfachung Rechnung getragen werden kann, gehört da eine große Gesamtfläche hin, in die dann - wie bereits mit anderen Worten beschrieben - Details zusätzlich eingefügt werden können. Es ist aber ein Unding nur Details zu mappen, denen dann Eigenschaften zu geben, die bislang für große Flächen benutzt wurden und dann zu sagen, da muß der Renderer jetzt irgendwie mit klar kommen und ein Ganzes draus machen.
Was die Kapazität der Suchergebnislisten betrifft, erweckt Deine Antwort bei mir den Eindruck, daß Du diese Funktion nicht kennst. Sonst würdest Du verstehen, daß diese Listen durch die Aufzählung einzelner Stellplätze unbrauchbar werden. Selbst wenn die Liste eine unendliche Kapazität hätte, wäre dem so.
Auf Bürgersteigflächen bezogen vertrete ich eine ähnliche Meinung. Wenn überhand nehmende Detailerfassung das Gesamtbild zerstört, dann läuft was falsch.
Wenn Verläufe von Bordsteinkanten erfaßt werden sollen, dann bitte nicht dadurch, daß Straßen oder Gehwege alle paar Meter aufgeteilt werden.
Wenn diese Daten so wichtig sind, warum erfaßt man sie nicht in einer separaten Linie rechts und links neben der Straße oder neben dem Gehweg? Es ist doch nicht notwendig, sämtliche Eigenschaften an ein und dieselbe Linie zu hängen. Wer diese Linien benötigt, der wertet sie aus und wer sie nicht braucht, der filtert sie raus. Und wo obendrein Gehwegflächen als notwendig erachtet werden, sind diese Linien dann eben die straßenseitige Begrenzung. Ich kann nur hoffen, daß diejenigen, die hier vehement für das detaillierte Micromapping eintreten und dafür Toleranz erwarten, denjenigen, die das nicht unterstützen und darauf bestehen, einfach faßbare Grundformen in der Karte zu erhalten, dieselbe Toleranz entgegenbringen, die klaren Grundstrukturen belassen und Details als zusätzliche Elemente einbringen.
In Bezug auf den Parkplatz ist mein Kompromißvorschlag: eine große Fläche als Parkplatz mappen und die Teilflächen als Stellplatzgruppen taggen.
In Bezug auf die Gehwege ist mein Kompromißvorschlag: für Gehwegflächen ein neues Taggingschema entwickeln, das klar von dem highway-Schema abgegrenzt und auch nicht mit highway=pedestrian verwechselt werden kann.
Wenn die in der Datenbank steckenden Informationen irgendwann nicht mehr auswertbar sind, dann ist ihr Wert = 0 und man hätte sich deren Erfassung sparen können.
Wie heißt das schöne Sprichwort? Weniger ist oft mehr!
Ginge ja im Prinzip mit dem parking_space proposal, nur leider sieht dieses vor, bei Verwendung von amenity=parking_space auf das
amenity=parking zu verzichten, anstelle dessen die vielen kleinen Stellplätze per Relation wieder zu einem Gesamtobjekt
zusammenzufügen. Also nicht abwätskompatibel mit bestehenden Anwendungen ist.
je nun, solange man mit parking_space wirklich nur Teilbereiche eines größeren Parkplatzes beschreibt, bleibt das ja abwärtskompatibel - schlicht und einfach, weil man dann jeweils unterschiedliche Objekte taggt.
amenity=parking wäre dann ja die site-Relation.
Erst wenn man den gesamten Parkplatz - fälschlicherweise? (*) - mit parking_space taggen will - erst dann ist es nicht mehr abwärtskompatibel.
Aber dort braucht man doch weder das parking_space noch eine site-Relation - das geht mit parking wie gehabt.
Gruß
Georg
(*) “It should not be used as a representation of one big single parking area. Highways should not cross this areas.”
