Jetzt schon Bürgersteige mappen?

Finde ich etwas übertrieben, zumal die selben Probleme wie bei straßenbegleitenden Radwegen auftreten. Ein Tag an der Straße (analog zu cycleway=*) ist (heute) wohl sinnvoller.

Quantität statt Qualität.... 😉
http://www.openstreetmap.org/?lat=48.36 … 7&layers=O
Ich frage mich auch manchmal wie man das ausufernde Detailmapping bremsen kann. 🙁

chris66 wrote:

Quantität statt Qualität.... 😉
http://www.openstreetmap.org/?lat=48.36 … 7&layers=O
Ich frage mich auch manchmal wie man das ausufernde Detailmapping bremsen kann. 🙁

Was ist denn für Dich "Qualitätsmapping"?

Dein Link zeigt _nur_ an, dass der Renderer Osmarender mit dem Ausschnitt völlig überfordert ist.

Wir haben auf der einer Seite die "Routing-Fraktion" aus der "Garmin-Ecke" und andererseits
die "Kataster-Jungs" mit 3D-/Indoor-/Gehsteig-Mapping.

Bin sehr gespannt - und gar nicht traurig - wie sich das in den kommenden Jahren entwickeln wird 🙂

Modern Times!

Qualitätsmapping ist z.B. wenn man nicht für die Renderer mappt, wie hier:
http://www.openstreetmap.org/?lat=48.37 … 8&layers=M
eine Wasserrutsche als leisure=swimming_pool und den Name-Tag dauernd missbraucht.

chris66 wrote:

Qualitätsmapping ist z.B. wenn man nicht für die Renderer mappt, wie hier:
http://www.openstreetmap.org/?lat=48.37 … 8&layers=M
eine Wasserrutsche als leisure=swimming_pool und den Name-Tag dauernd missbraucht.

Schön, schön (respektive Schlecht, schlecht)
Hat aber mit Ausgangsfrage weniger zu tun, denn bei jener geht es mehr um

Abstrakta (Erfassen wir unserer Welt verstärkt in eindimensionalen Gebilden wie Punkte und Wege)
versus
Konkreta (die Umwelt modelliert mit Hilfe unter anderen von Flächen/Räume)

chris66 wrote:

Quantität statt Qualität.... 😉
http://www.openstreetmap.org/?lat=48.36 … 7&layers=O
Ich frage mich auch manchmal wie man das ausufernde Detailmapping bremsen kann. 🙁

Da kriege ich Augenkrebs.

hi !

ich würde sagen - es kommt darauf an.

In den o.g. Fällen etwas übertrieben aber an sehr bereiten Straße wiederum schon relevant. Dort sind da aber oftmals auch Radwege "daran gebunden".

Das sich die Geister scheiden zeigt sich bei uns in Lübeck wo darüber diskuttiert wurde die Radwege - 15m !! vom Straßenrand entfernt (Eindeutig baulich getrennt !) nicht gesondert dargestellt werden sollten.

http://www.openstreetmap.org/?lat=53.86 … 8&layers=M

Habe es trotzdem gemacht.

Die Wege müssen nur "brauchbar" angebunden sein um ein Routing sinnvoll zu ermöglichen.

Gruß Jan :-)

kukuk wrote:

Was macht man mit so etwas? Einfach wieder löschen?

Nein, die übliche Fehlerbehebung bei solchen Floating Islands besteht darin kleine Verbindungswege
einzuzeichnen an Stellen wo man "typischerweise" vom Fußweg auf das Straßennetz wechseln kann.

Eines im Vorab: ich freue mich sehr über Detailmapping und bedauere nur, dass es so wenig ausgeprägt und an so wenigen Stellen zu finden ist.

Warum: für mich ist OSM ein Traum, der Traum von einer besseren Welt. Ein alter Traum der Enzyklopedysten: indem ich das Wissen den Menschen zugänglich mache, mache ich auch die Welt besser. Eine direkte Implikation ist also: je mehr Informationen in der Karte, umso besser die Karte.

Die Routing Beschwerden sind verständlich! Das momentane System ist nicht perfekt: Die Aufnahme bestimmter Informationn in die Karte erschwert die Auswertung auf der anderen Seite. Für mich heißt es aber: Wir müssen ein Weg finden, der Beides vereint.

Was die komplexe Routing Problematik angeht: Da ich direkt im Herzen der Profi Navigationsentwicklung stecke, kann ich nur sagen: OSM hat noch einiges zu tun an dieser Stelle...

marek kleciak wrote:

Eine direkte Implikation ist also: je mehr Informationen in der Karte, umso besser die Karte.

In Bezug auf *Karten* ist diese Aussage ganz sicher falsch; und selbst in bezug auf unsere Datenbank halte ich sie fuer fragwuerdig. Die Grenze fuer OSM liegt nicht bei irgendeinem Relevanzkriterium, sondern bei der Frage: Koennen wir noch warten, was wir da produzieren? Denn wenn wir irgendwann mehr Daten haben, als wir noch korrekt und aktuell halten koennen, dann verliert das ganze rapide an Wert. In Abwesenheit von Datenimporten reguliert sich das einigermassen selbst - weil die Daten eben auch von Menschen gesammelt werden, steht die Menge in einem bestimmten Verhaeltnis zu den mitarbeitenden Menschen. Wenn das aber aus dem Lot kommt, z.B. durch zu viele Datenimporte oder eine Stagnation bei der Mitmacher-Zahl, dann kriegen wir ein Problem.

marek kleciak wrote:

Die Routing Beschwerden sind verständlich! Das momentane System ist nicht perfekt: Die Aufnahme bestimmter Informationn in die Karte erschwert die Auswertung auf der anderen Seite.

Die Aufnahme bestimmter Informationen in die Karte erschwert vorallem auch die weitere Pflege und Erfassung von anderen Informationen. Wenn einer mit Buergersteigen (oder 3D-Gebaeuden) dafuer sorgt, dass andere nicht mal mehr viel weniger exotische Dinge wie eine normale Strassenkreuzung mappen koennen, weil alles zu unuebersichtlich, schwerfaellig, langsam wird, dann haben wir ein Problem (das ich, wenn noetig, immer zu Ungunsten des Nischenmappings entscheiden wuerde).

Das ist etwas, was sich langsam entwickeln muss, und es ist gut, wenn hie und da damit experimentiert wird, damit wir alle wissen, was auf uns zukommt und unsere Tools darauf anpassen koennen, so dass auch bei steigender Datenmenge und Detailtiefe auch noch das Editieren auf einem weniger detaillierten Level moeglich ist.

Bye
Frederik

chris66 wrote:

Quantität statt Qualität.... 😉
http://www.openstreetmap.org/?lat=48.36 … 7&layers=O
Ich frage mich auch manchmal wie man das ausufernde Detailmapping bremsen kann. 🙁

Eingleisige Straßenbahnen ohne richtige Weichen? Also wirklich! Schrecklich detailarm!

Gut gemeint ist nicht gleich gut gemacht (besser sinnvoll). Ich beobachte sehr gespannt die Entwicklung von OSM. Bis vor kurzem war ich sehr begeistert vom Projekt! Ich habe einigen Freunden davon erzählt und OSM empfohlen. Seit ich hier mehr über Vandalismus gelesen habe, betrachte ich das Projekt kritischer in Hinblick auf Verlässlichkeit, und Sinn der Karte (Daten).

Jetzt noch Gehwege um einen Häuserblock zu legen, finde ich übertrieben. Verwirrend.

(Der von mir geleserne Beitrag über Vandalismus hat nichts mit den Gehwegen zu tun. Er war nur der Anlass kritischer zu beobachten!)

kukuk wrote:

...
In Augsburg wurden die Bürgersteige teilweise gleich als Fläche gemappt:
http://www.openstreetmap.org/?lat=48.36 … 8&layers=M
...

Da steckt aber wohl die Uni (Lehrstuhl für Humangeographie und Geoinformatik) irgendwie mit drin. 🤔

Details dazu in der Wiki:
http://wiki.openstreetmap.org/wiki/Augs … lit%C3%A4t

kukuk wrote:

Hallo,

der neuste Trend, den ich heute feststellen mußte, macht mir echt Sorgen: Das Mappen von Bürgersteigen in Städten 🙁

Den ersten habe ich zufällig auf der Durchreise in Treuchtlingen festgestellt:
http://www.openstreetmap.org/?lat=48.96 … 8&layers=M

Das schlimme: da der Bürgersteig mit keinem anderen Weg verbunden ist, führt das unweigerlich zu Routing-Fehlern, sobald man eine Adresse innerhalb ansteuert. Was macht man mit so etwas? Einfach wieder löschen?

In Augsburg wurden die Bürgersteige teilweise gleich als Fläche gemappt:
http://www.openstreetmap.org/?lat=48.36 … 8&layers=M

Abgesehen davon, das ich keine Renderer finden konnte, der einen Fußweg als Fläche korrekt mappen kann, sind die Wege auch nicht alle Verbunden. Wenn es also nicht zu Routing-Fehlern kommt, dann zu sehr merkwürdigen Anweisungen, vor allem ist ein Fußweg nach Fußweg nach Fußweg in der Stadt nicht wirklich hilfreich.

Thorsten

Ich mappe in Augsburg u.a. Bürgersteige und finde das überhaupt nicht übertrieben. Ich mappe nicht nur für Autos, sondern halt auch für Fußgänger.

Die teilweise flächenhafte Mapperei von Bürgersteigen habe ich testweise importiert von der Uni, die mit der Stadt Augsburg das Projekt "Stadtplan für barrierefreie Mobilität der Stadt Augsburg" durchgeführt hatten und wo ich von der Stadt die Daten bekommen habe für den Import in OSM. Die Flächen sind aber optischer Natur und zum einen gab es nach dem Import das area:highway, das ich zukünftig nehmen würde als auch die Erkenntnis bei mir, daß die Flächen kaum oder nicht gebraucht werden.

Es gibt ja auch das Projekt Lorodux, das eine Navigation für Blinde auf OSM-Datenbasis bereitstellt.

Gerade die benachteiligten Personengruppen können am ehesten von OSM profitieren und nicht von anderen Kartendiensten. Aber da fängt nicht erst der Nutzen des Bürgersteigmappen an.

Viele Grüße

Dietmar aka okilimu

Ja ich denke Bürgersteige mappen gehört zu OSM dazu, genau so wie Spurmapping an Kreuzungen oder Straßenbreiten. Wir erfassen ja auch Zäune und Häuser. Die für Navigation hezlich wenig Bedetung haben. Dafür reichen Adressnodes.

GeoCounter wrote:

Finde ich etwas übertrieben, zumal die selben Probleme wie bei straßenbegleitenden Radwegen auftreten. Ein Tag an der Straße (analog zu cycleway=*) ist (heute) wohl sinnvoller.

Und morgen, wenn es doch gebraucht wird - muss ich es neue erfassen. Denn als Tag an der Straße sagt es nicht, wo er tatsächlich verläuft.

geri-oc wrote:

GeoCounter wrote:

Finde ich etwas übertrieben, zumal die selben Probleme wie bei straßenbegleitenden Radwegen auftreten. Ein Tag an der Straße (analog zu cycleway=*) ist (heute) wohl sinnvoller.

Und morgen, wenn es doch gebraucht wird - muss ich es neue erfassen. Denn als Tag an der Straße sagt es nicht, wo er tatsächlich verläuft.

+1
Auch gibt es noch keine Unterschiede zwischen links und rechts neben der Straße.
Und wenn für Autofahrer schon doppelte weiße Linien oder Sperrflächen für eine Trennung genügen, dann ist der Bürgersteig erst recht einen bauliche Trennung. Vorallem für Fahrradfahrer. Für Fußgänger vielleicht weniger.

Ist denn ein eindeutiges TAG für einen Bürgersteig bereits beschlossen und wird dieses von den Renderern auch sinnvoll ausgewertet?
Ich denke, dass darin das größte Problem besteht, und nicht in der Frage, sollen wir Detailmapping zulassen, fördern, schlechtreden oder gar (per edit-war oder wie auch immer) unterbinden.

highway=footway ohne footway=sidewalk führt ganz sicher zur Verwirrung, da ein sidewalk nun mal nicht gleich einem footway ist daher ohne eigene Kennzeichnung nicht auf Wunsch ausblendbar wäre.
Wer der Meinung ist, auch den Bürgersteig erfassen zu müssen, der sollte zuallererst einmal für ein eindeutiges Schema sorgen, und das ist anscheinend immer noch in Diskussion.

Wenn es eine eindeutige Unterscheidungsmöglich gibt, ist auch die Aufregung über dieses Detailmapping hinfällig.
Renderer, die Bürgersteige anzeigen wollen, sollen das tun, andere werden sie einfach ausblenden.

Da bereits begonnen wurde, über sidewalk zu diskutieren, halte ich es am sinnvollsten, diese Diskussion zu Ende zu führen.
Es wird nie möglich sein, Detailmapping komplett zu unterbinden, daher halte ich jede Anstrengung in diese Richtung für überflüssig.
Das einzig sinnvolle ist, rechtzeitig für eine eindeutige Unterscheidungsmöglichkeit zu sorgen, bevor das entsprechende Detailmapping unkontrolliert überhand nimmt.

Ich empfehle auch jener Fraktion, die sich für Bürgersteige nicht interessiert, konstruktiv an der Diskussion teilzunehmen.
Wer nur die Augen verschließt, muss die Folgen trotzdem mittragen. (siehe obige Beispiele)

Derzeit können wir viele Wege leider nicht mehr wirklich unterscheiden.
highway=path ist ein Wanderweg manchmal auch ein Gehweg oder Bürgersteig
highway=footway ist ein Weg gekennzeichnet für Fußgänger manchmal auch ein Wanderweg.
highway=sidewalk wäre zwar eindeutig, darüber gab es jedoch nie ein Proposal.

Der einzige Beschluss, den es derzeit gibt, ist jedenfalls alles andere als optimal:
http://wiki.openstreetmap.org/wiki/Prop … parate_way

Walter

okilimu wrote:

Ich mappe in Augsburg u.a. Bürgersteige und finde das überhaupt nicht übertrieben. Ich mappe nicht nur für Autos, sondern halt auch für Fußgänger.

Die teilweise flächenhafte Mapperei von Bürgersteigen habe ich testweise importiert von der Uni, die mit der Stadt Augsburg das Projekt "Stadtplan für barrierefreie Mobilität der Stadt Augsburg" durchgeführt hatten und wo ich von der Stadt die Daten bekommen habe für den Import in OSM. Die Flächen sind aber optischer Natur und zum einen gab es nach dem Import das area:highway, das ich zukünftig nehmen würde als auch die Erkenntnis bei mir, daß die Flächen kaum oder nicht gebraucht werden.

Es gibt ja auch das Projekt Lorodux, das eine Navigation für Blinde auf OSM-Datenbasis bereitstellt.

Gerade die benachteiligten Personengruppen können am ehesten von OSM profitieren und nicht von anderen Kartendiensten. Aber da fängt nicht erst der Nutzen des Bürgersteigmappen an.

Gerade die von Dir ins Felde geführten Personengruppen haben rein gar nichts davon, wenn die Gehwege einfach im Nichts enden. Wie auf dem von mir verlinkten Ausschnitt.
Was passiert im Moment?
- Die Fußgänger werden im Kreis geführt, nur um am Ausgangspunkt wieder an zu kommen
- Bei der Genauigkeit von GPS im Stadtgebiet weiß keiner ob er auf der Fläche ist oder nicht
- Bei einer Anweisung "Gehweg nach Gehweg" fragt man sich dann vor allem an Kreuzungen, welcher Gehweg den jetzt nun?
- Wenn man auf die andere Straßenseite muß, führt einen die Routingsoftware auf riesen Umwegen dorthin, da es keinen Weg "über die Straße" gibt.

Also ich hatte damit ja schon als "normaler" Mensch meine Probleme beim Zurechtfinden gestern in Augsburg, ich möchte nicht wissen, wie jemand damit klar kommen soll, der wirklich in der Mobilität eingeschränkt ist.

So gut und richtig die Idee dahinter ist: Die Umsetzung kann mich nicht überzeugen. Ich hätte es für hilfreicher gefunden, wenn die Daten direkt an die Straße gepackt worden wären. Das Gefälle ist dort ja das gleiche.

Grüße,
Thorsten

Der ringförmige Fußweg wurde nicht von der Uni Augsburg sondern der GIS-Abteilung der Stadt Treuchtlingen gemappt.
Aber egal, falsch ist falsch. 😉

kellerma wrote:

Dein Link zeigt _nur_ an, dass der Renderer Osmarender mit dem Ausschnitt völlig überfordert ist.

Nicht nur mit dem Ausschnitt. Frage mich wieso der auf unserer Hauptseite osm.org überhaupt noch als
Layer drin sein darf. 😉

Walter Schlögl wrote:

Ist denn ein eindeutiges TAG für einen Bürgersteig bereits beschlossen und wird dieses von den Renderern auch sinnvoll ausgewertet?
Ich denke, dass darin das größte Problem besteht, und nicht in der Frage, sollen wir Detailmapping zulassen, fördern, schlechtreden oder gar (per edit-war oder wie auch immer) unterbinden.

highway=footway ohne footway=sidewalk führt ganz sicher zur Verwirrung, da ein sidewalk nun mal nicht gleich einem footway ist daher ohne eigene Kennzeichnung nicht auf Wunsch ausblendbar wäre.
Wer der Meinung ist, auch den Bürgersteig erfassen zu müssen, der sollte zuallererst einmal für ein eindeutiges Schema sorgen, und das ist anscheinend immer noch in Diskussion.

Wenn es eine eindeutige Unterscheidungsmöglich gibt, ist auch die Aufregung über dieses Detailmapping hinfällig.
Renderer, die Bürgersteige anzeigen wollen, sollen das tun, andere werden sie einfach ausblenden.

Da bereits begonnen wurde, über sidewalk zu diskutieren, halte ich es am sinnvollsten, diese Diskussion zu Ende zu führen.
Es wird nie möglich sein, Detailmapping komplett zu unterbinden, daher halte ich jede Anstrengung in diese Richtung für überflüssig.
Das einzig sinnvolle ist, rechtzeitig für eine eindeutige Unterscheidungsmöglichkeit zu sorgen, bevor das entsprechende Detailmapping unkontrolliert überhand nimmt.

Ich empfehle auch jener Fraktion, die sich für Bürgersteige nicht interessiert, konstruktiv an der Diskussion teilzunehmen.
Wer nur die Augen verschließt, muss die Folgen trotzdem mittragen. (siehe obige Beispiele)

Derzeit können wir viele Wege leider nicht mehr wirklich unterscheiden.
highway=path ist ein Wanderweg manchmal auch ein Gehweg oder Bürgersteig
highway=footway ist ein Weg gekennzeichnet für Fußgänger manchmal auch ein Wanderweg.
highway=sidewalk wäre zwar eindeutig, darüber gab es jedoch nie ein Proposal.

Der einzige Beschluss, den es derzeit gibt, ist jedenfalls alles andere als optimal:
http://wiki.openstreetmap.org/wiki/Prop … parate_way

Walter

Na dann wollen wir doch mal konstruktiv anfangen.
- kann man Fußwege genau wie Straßenflächen mit area:highway=footway... mappen. Dann kümmert sich schon heute kein router rendere darum.
- sind Straßen und Fußwege perse 2-Dimensoinal nicht wie derzeit 1-Dimensional.
- fällt mir die Unterscheidung zwischen footway und sidewalk sehr sehr schwer. Im Deutschen würde ich immer sagen gehe auf dem Fußweg nicht auf der Straße.
- ist bis heute nicht gelöst wie man einen nur auf einer Seite verlaufenden Fuß oder Radweg taggen sollte
- wo ist der Unterschied zwischen einem Fußweg mit oder ohne Grünstreifen zwischen der Straße Für den Fußgänger wohl kaum einer.

Das Thema highway=path mit foot=yes (footway) und highway=path mit bicylce=yes (cycleway) wurde an anderer Stelle schon umfangreich diskutiert und es gibt immer noch verfechter beide taggingschemata. Insofern ist es einfach ungerecht wenn du jetzt von einem fehlenden Taggingschemata ein Verbot ableiten möchtest.
Dann möchte ich andere Baustellen gar nicht erst ansehen. Eigentlich hätte mit dieser Auffasung OSM von Anfang an verboten sein müssen. Aber es lebte von dieser Freiheit und ist deshalb so groß geworden.

Petja wrote:

chris66 wrote:

Quantität statt Qualität.... 😉
http://www.openstreetmap.org/?lat=48.36 … 7&layers=O
Ich frage mich auch manchmal wie man das ausufernde Detailmapping bremsen kann. 🙁

Da kriege ich Augenkrebs.

Ich würde mal sagen, umschalten auf Mapnik und alles ist in Ordnung. Ich mappe nicht für Osmarender, sondern erfasse einfach die Sachen vor Ort (bin dort auch nicht allein unterwegs). Vieles davon sind Ärzte und die finde ich nebenbei wichtig.

Grüße

Dietmar aka okilimu

chris66 wrote:

Quantität statt Qualität.... 😉
http://www.openstreetmap.org/?lat=48.36 … 7&layers=O
Ich frage mich auch manchmal wie man das ausufernde Detailmapping bremsen kann. 🙁

Was passt Dir denn da nicht? Bitte mal begründen, was nicht gemappt werden sollte.

Grüße

Dietmar

kukuk wrote:

okilimu wrote:

Ich mappe in Augsburg u.a. Bürgersteige und finde das überhaupt nicht übertrieben. Ich mappe nicht nur für Autos, sondern halt auch für Fußgänger.

Die teilweise flächenhafte Mapperei von Bürgersteigen habe ich testweise importiert von der Uni, die mit der Stadt Augsburg das Projekt "Stadtplan für barrierefreie Mobilität der Stadt Augsburg" durchgeführt hatten und wo ich von der Stadt die Daten bekommen habe für den Import in OSM. Die Flächen sind aber optischer Natur und zum einen gab es nach dem Import das area:highway, das ich zukünftig nehmen würde als auch die Erkenntnis bei mir, daß die Flächen kaum oder nicht gebraucht werden.

Es gibt ja auch das Projekt Lorodux, das eine Navigation für Blinde auf OSM-Datenbasis bereitstellt.

Gerade die benachteiligten Personengruppen können am ehesten von OSM profitieren und nicht von anderen Kartendiensten. Aber da fängt nicht erst der Nutzen des Bürgersteigmappen an.

Gerade die von Dir ins Felde geführten Personengruppen haben rein gar nichts davon, wenn die Gehwege einfach im Nichts enden. Wie auf dem von mir verlinkten Ausschnitt.
Was passiert im Moment?
- Die Fußgänger werden im Kreis geführt, nur um am Ausgangspunkt wieder an zu kommen
- Bei der Genauigkeit von GPS im Stadtgebiet weiß keiner ob er auf der Fläche ist oder nicht
- Bei einer Anweisung "Gehweg nach Gehweg" fragt man sich dann vor allem an Kreuzungen, welcher Gehweg den jetzt nun?
- Wenn man auf die andere Straßenseite muß, führt einen die Routingsoftware auf riesen Umwegen dorthin, da es keinen Weg "über die Straße" gibt.

Also ich hatte damit ja schon als "normaler" Mensch meine Probleme beim Zurechtfinden gestern in Augsburg, ich möchte nicht wissen, wie jemand damit klar kommen soll, der wirklich in der Mobilität eingeschränkt ist.

So gut und richtig die Idee dahinter ist: Die Umsetzung kann mich nicht überzeugen. Ich hätte es für hilfreicher gefunden, wenn die Daten direkt an die Straße gepackt worden wären. Das Gefälle ist dort ja das gleiche.

Grüße,
Thorsten

In dem Innenstadtbereich sind etliche sehr kurze Fragmenge von Fußwegen enthalten, ja. Das hatte mit dem Testimport der Detaildaten zu tun. Diese kurzen Wegstücke markieren Fußwegabschnitte, wo der Bürgersteig abgesenkt ist. Der gesamte Bürgersteigverlauf ist nicht in den Daten enthalten gewesen und muß noch von OSM-lern (u.a. mir) ergänzt werden. Ein Gesamtimport des Bereichs war aber einfacher und verhilft uns auch, Spezialkarten für Garmin zu machen, um die Abshcnitte gezielt anzugehen.

Es gibt halt nicht den Zustand perfekt alles routingfähig oder noch nicht in OSM sondern was dazwischen. Ich habe nicht behauptet, das wir fertig sind und alles toll ist bei uns.

Thema highway=footway vs. sidewalk: letzterer ist noch nicht wirklich lange da und wenig in Gebrauch. Lieber schon mal erfassen und dann ggfs. ziemlich einfach umtaggen als erstmal das Ergebnis abwarten. Ist zumindest mein Motto. Geht auch anders, klar.

Viele Grüße

Dietmar

Grundsätzlich läßt mich dieses Detailmapping erschaudern, wenn daraus kein wirklicher Mehrwert ableitbar ist.
Die Frage nach dem Mehrwert beurteilt jedoch jeder anders. Daher ist es kein sinnvoll diskutierbares Kriterium.

Nicht wegzudiskutieren ist jedoch, daß durch fortschreitende Verdichtung der Daten mancherorts die Datenmenge bereits derart groß geworden ist, daß es für den individuellen Kartenbastler zunehmend aufwändiger wird, die Rohdaten herunter zu laden und anschließend auszuwerten.
Marqqs bastelt fleißig an Programmen, mit denen die Datenmenge vor dem Rendern reduziert werden kann, damit beim Rendern nicht der ganze überflüssige Ballast mit durchgeschleust werden muß. Doch letztendlich helfen nur immer größere Kapazitäten ...

Ich finde Osmarender als abschreckendes Beispiel ganz gut. 😉

Was mich wirklich verärgert ist, wenn Mapper, um die Darstellung irgendwelcher Details zu erzwingen, z.B. das name-Tag mißbrauchen. Es wäre gut, wenn ein Konsens dafür geschaffen werden könnte, daß ein derartiger Mißbrauch ohne Nachfrage umgetagt wird. Natürlich nicht ohne einen passenden Hinweis z.B. note= name in description umgewandelt, da kein Eigenname

Wenn jemand partout Bürgersteigflächen erfassen möchte, dann muß er dafür sorgen, daß diese herausgefiltert werden können. Denn nicht auf jeder Karte macht die flächige Darstellung von Bürgersteigen Sinn.

Kürzlich habe ich mich mit Maperitive beschäftigt. Das damit erzeugte Kartenbild läßt sich in Rasterkarten umwandeln. Wenn man dafür ein Layout entwickelt, kommt man schon bald auf völlig andere Wünsche/Ideen/Ansprücke als man sie an ein mit mkgmap erzeugtes Layout für Vektorkarten entwickelt. Und sogar innerhalb der "Sparte" ändern sie die Wünsche je nach Anzeigegerät.

Da die Karten-Rohdaten also unterschiedlichsten Ansprüchen gerecht werden müssen, ist es meines Erachtens am Wichtigsten, dafür zu sorgen, daß die Datenstruktur durchschaubar, auswertbar und vor allem gut filterbar bleibt. Das Erfinden neuer Tags/Keys macht mir dabei solange keine großen Kopfschmerzen, wie sie sinnvoll durchdacht sind. Vielleicht sollte man auf allen TAG-Wiki-Seiten einen Hinweis einblenden, der darauf hinweist, wie wichtig gut durchdachte Tag-Schemata sind, daß alte Schemata nicht nach Belieben "umgemünzt" werden können und daß es sinnvoll sein kann, völlig neue Ideen erst einmal zu diskutieren, damit eine größere Chance besteht, Schwächen der Idee rechtzeitig, also vor der Umsetzung aufzudecken und bessere Alternativen zu finden.

Schlimm ist die Umdeutung oder "Bedeutungserweiterung" vorhandener Tags/Keys. Die führen dazu, daß man hilflos zusehen muß, wie einem die Karte mit unerwünschten/überflüssigen Details zugemüllt wird.

Der einzige Weg, den Mißbrauch von etablierten Tags einzudämmen wird sein, an prominenter=leicht auffindbarer Position der wichtigsten osm-Webseiten Karten mit verschiedenen Layern anzubieten. Es gibt ja schon verschiedene Beispiele mit sehr interessanten Layer-Kombinationen. Wenn bei jedem Layer eine leicht auffindbare Info erläutert, wie man mappen muß, damit die Inhalte im passenden Layer angezeigt werden, kann man die Verwendung der Tags möglicherweise zumindest teilweise steuern.
Es ist wichtig, daß sauber strukturiertes Mappen durch sichtbaren Erfolg belohnt wird. Nur dann wird es sich durchsetzen.

Da so manch interessante Themenkarte auf Privatinitiative beruht, benötigt man eine Art Netzwerk (oder wie soll man das nennen?), das es dem Kartennutzer leicht macht, die für ihn interessanten Karten zu finden.

All diejenigen, die aus irgendwelchen Gründen ein kommerzielles Interesse an den OSM-Daten haben, also Gewinn daraus ziehen, sollten sich überlegen, wieviel ihnen gut strukturierte Daten wert sind. Warum? Die OSM-Server sind vermutlich nicht in der Lage, alle thematisch interessanten Layer zu präsentieren. Bei auf Privatinitiative basierenden Angeboten muß man damit rechnen, daß sie von heut auf morgen aus dem Netz verschwinden, wenn der Anbieter die Kosten nicht mehr tragen und die dafür notwendige Arbeit nicht mehr leisten möchte. Also sollten diejenigen, die an bestimmten Daten interessiert sind, überlegen, inwieweit sie das Vorhandene z.B. finanziell unterstützen können.

Frederiks mahnende Worte, auch daran zu denken, daß die gesammelten Daten wartbar bleiben müssen, verhallen hoffendlich nicht!
Sonst wird OSM irgendwann im Chaos ungewarteter Daten untergehen.

Veraltete Daten werden nur entdeckt, wenn sie in übersichtlichen Karten angezeigt werden. Auch das ist ein Grund, Karten wie Mapnik und Osmarender als neutrale Grundkarten beizubehalten und sie mit verschiedenen Layern zu ergänzen. Daher scheint mir aktuell besonders wichtig zu sein, Layer-Karten bekannter zu machen und dafür zu werben, über neue Layer-Ideen nachzudenken, bevor man die Darstellung weiterer Details in Mapnik und Osmarender "erschummelt" / forciert / beantragt.

Strukturiertes Mappen führt auch zu mehr Übersichtlichkeit beim Mappen selbst, wenn mit JOSM z.B. gezielt bestimmte Objekte isoliert und diese dadurch besser gewartet werden können. Auch das ist nur mit einer gut filterbaren Datenstruktur möglich. Für ungeübte Anwender erschließt sich der Filter in JOSM allerdings nicht so ohne weiteres auf Anhieb. Vielleicht hat ja jemand eine Idee, wie man den noch etwas leichter handhabbar gestalten kann. Schön wäre, wenn man in einer Liste Häkchen setzen könnte, um bestimmte Objektarten isoliert anzeigen lassen zu können.

Einen schönen Sonntagnachmittag !

tippeltappel

tippeltappel wrote:

Was mich wirklich verärgert ist, wenn Mapper, um die Darstellung irgendwelcher Details zu erzwingen, z.B. das name-Tag mißbrauchen. Es wäre gut, wenn ein Konsens dafür geschaffen werden könnte, daß ein derartiger Mißbrauch ohne Nachfrage umgetagt wird. Natürlich nicht ohne einen passenden Hinweis z.B. note= name in description umgewandelt, da kein Eigenname

Ich denke wir sollten hier beim Ursprungsthema bleiben. Die Verwendung von fremden Tags wie name um die Darstellung zu erzwingen ist denke ich nicht Gegenstand der eigetnlichen Disskussion.

tippeltappel wrote:

Wenn jemand partout Bürgersteigflächen erfassen möchte, dann muß er dafür sorgen, daß diese herausgefiltert werden können. Denn nicht auf jeder Karte macht die flächige Darstellung von Bürgersteigen Sinn.

es macht nicht immer Sinn. Es macht genauso wenig Sinn wie jede Zufahrt oder Parkstreifen zu erfassen. Oder gar auf Parkplätzen die Fahrtwege.
Ich denke ab einer bestimmten Zoomstufe(Detailgrad) macht es wesentlich mehr Sinn eine Straße und einen Weg als Fläche zu erfassen, als hier eine abstrakte Linie irgendwo in der Mitte zu haben.
Dazu kommt dann noch das ungelöste Problem mit den nur einseitig verlaufenden Rad und Fußwegen bzw. wenn die Linienbündel nicht symetrisch sind. Wo ist denn die Straßenmitte wenn an Kreuzungen sich Straßen aufweiten und dann je zwei Fahrspuren rechts links und geradeaus sowie in der Gegenrichtung sind?
Wie traurig sehen an solchen Stellen denn dann weißen Flecken zwischen Straße und angrenzender Grünfläche aus? Eigentlich wären die gar nicht da.
Ein tolles Beispiel wäre hier: http://www.openstreetmap.org/?lat=51.04 … 8&layers=M
Man sieht deutlich wie die Grünfläche schmaler wird um der Linksabbiegerspur Platz zu machen. Was man gar nicht erkennen kann, ist dass der Radweg zwischen geradeaus und rechtsabbiegerspur läuft. Würde man sowas rendern, wäre der Radweg wohl immer beidseitig am Rand.
http://www.openstreetmap.org/?lat=51.04 … 8&layers=M
Das lässt sich hier wegen der Fahrradroute nur in der Grunaerstraße erkennen. Solange dafür keine im konventionellen Schema keine handhabbaren Lösungen existieren, ist der Flächenansatz der einzig gangbare.
Spannender finde ich bei der Diskussion aber solche Stellen hier:
http://maps.google.de/?ll=51.112483,13. … 20&vpsrc=6
Man sieht einen Busbahnhof. Würde man zwischen die Straßen jetzt Bahnsteige zeichnen soll man jeden Bahnsteig mittels Fußweg mit den Straßen verbinden. Aber es ist gar kein Fußweg da. Das ist nur ein Hilfsmittel für das routing. In wirklichkeit stoßen Bahnsteig und Straße dazwischen aneinander.
In Dippoldeswalde hat sich schon einer erbarmt und dort die nichtvorhandenen Wege eingezeichnet, damit der Navigator nicht auf dem Bussteig gefangen bleibt. Und highway=platform war auch unerwünscht, weil Garmin eher railway=platform haben möchte.

chris66 wrote:

kellerma wrote:

Dein Link zeigt _nur_ an, dass der Renderer Osmarender mit dem Ausschnitt völlig überfordert ist.

Nicht nur mit dem Ausschnitt. Frage mich wieso der auf unserer Hauptseite osm.org überhaupt noch als
Layer drin sein darf. 😉

Weil es so schön her passt:
Seit November gibt es vom mapsforge-projekt die PrioritizedMapViewer.apk
Deren Stil ist osmarender-like. In dieser Prototype-app kann man z. B. on-the-fly die labels pro Tile einstellen: 1, 3, 5, 8, 10, unlimited.

A ready to run APK, based on the AdvancedMapViewer. This app is merely used to give a general idea how the new labeling mechanism would look like when it's released. Please report issues.

@ viw
Es ist und bleibt eine Frage der Zielsetzung, welche Kartendetails zu erfassen sinnvoll sind und welche nicht. Unzählige Kartendetails tragen nicht unbedingt zur besseren Lesbarkeit einer Karte bei. Daher betonte ich ja bereits, daß es wichtig ist, die Datenerfassung so zu strukturieren, daß sie ohne "Klimmzüge" gefiltert, sowie zu- und wegschaltbare Layer generiert werden können.

Eine Karte kann nicht "traurig" aussehen. Sie kann aber ein mehr oder weniger klares und gut bis schlecht lesbares Layout haben.
Es ist eine Frage des Maßstabs, wieviele Details ausgeblendet werden (müssen!). Man kennt dafür den Fachausdruck "Verdrängung". Auf einem großen Bildschirm liest sich zudem eine Karte völlig anders, wie auf einem kleinen Display. Und ein leistungsstarker Rechner wird mit einer großen detailreichen Karte besser fertig, als ein einfaches, weniger leistungsstarkes Gerät.
Auf dem Pferd schleppe ich nun mal kein Laptop mit mir herum. Daher bin ich mehr an einem einfachen gut lesbaren Layout für das winzige Display des etrexVHCx interessiert, als am Bürgersteigmapping.

Wenn es das Tagging hergeben würde, würde ich auch die ganzen Grundstückszufahrten ausblenden.
Denn die müllen mir auch die Karte unnötigerweise zu.
Nur leider ist kein sinnvolles Schema für das service-Tag erkennbar, nach dem diese Wegeart verläßlich gefiltert werden kann. In der "Pampa" ist highway=service eine durchaus wichtige Wegart. Also muß ich in den sauren Apfel beißen und die Garageneinfahrten drin lassen.

Kommen wir auf das Bürgersteigmapping zurück.
Ich lehne es ab. Aber nicht, weil es mich aus persönlichen Gründen stört oder ich es nicht gebrauchen kann. Vielmehr können mich die bislang vorgebrachten Argumente dafür in keiner Weise überzeugen. Ich glaube nicht, daß die Erfassung der Flächen für irgendjemanden von praktischem Nutzen sind. Für blinde Mitbürger wäre das Taggen einer Ideallinie, die sicher über Plätze führt, wesentlich sinnvoller. Mit einer Technologie, die es GPS-Geräten ermöglicht, sich sozusagen am Weg festzuhalten, lassen sich solche Ideallinien vielleicht mal wie eine Art Leitstrahl nutzen. Argumente wie "traurig" aussehende Karten sind mir zu sehr an persönlichem Geschmacksempfinden orientiert.

Das Flaechen nicht fuer Blindennavigation geeignet waeren, wuerd ich mal widersprechen.
ImGegenteil, beim Vorhandensein eines "Katasters" weiss ich zu jeder Zeit, wie breit der Gehsteig
ist. Etwas, was mit width bei Linien nur ansatzweise wiedergebe, da die Breite des Buergersteigs durchaus schwanken kann.
Die Ermittlung der Route wird aufweniger, da man erst die "Buergersteigmitte" ermitteln muss, aber auch kein Hexenwerk und die Route wird dann von mir aus als Overlay angezeigt.

Bei niedrigeren Zoomleveln wird dann wieder generalisiert und die Buergersteigflaeche zur Linie,
bei noch niedriger verschwindet er ganz und der Sttassenstrich bleibt uebrig (no pun intended 😉

okilimu wrote:

Was passt Dir denn da nicht? Bitte mal begründen, was nicht gemappt werden sollte.

Einige Beispiele:
Platzlinien / Einzeln gemappte Bäume:
http://www.openstreetmap.org/?lat=47.98 … 8&layers=M

Eine Pollerorgie in Dortmund:
http://www.openstreetmap.org/?lat=51.51 … 8&layers=M

Einzelne Bereiche eines Parkplatzes einzeln gemappt (POI Inflation):
http://www.openstreetmap.org/?lat=48.96 … 8&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. 😉

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

woodpeck wrote:

marek kleciak wrote:

Eine direkte Implikation ist also: je mehr Informationen in der Karte, umso besser die Karte.

In Bezug auf *Karten* ist diese Aussage ganz sicher falsch; und selbst in bezug auf unsere Datenbank halte ich sie fuer fragwuerdig. Die Grenze fuer OSM liegt nicht bei irgendeinem Relevanzkriterium, sondern bei der Frage: Koennen wir noch warten, was wir da produzieren? Denn wenn wir irgendwann mehr Daten haben, als wir noch korrekt und aktuell halten koennen, dann verliert das ganze rapide an Wert.

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.

chris66 wrote:

okilimu wrote:

Was passt Dir denn da nicht? Bitte mal begründen, was nicht gemappt werden sollte.

Einige Beispiele:
- Platzlinien / Einzeln gemappte Bäume: ...
- Eine Pollerorgie in Dortmund: ...
- Einzelne Bereiche eines Parkplatzes einzeln gemappt (POI Inflation): ...

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)

chris66 wrote:

okilimu wrote:

Was passt Dir denn da nicht? Bitte mal begründen, was nicht gemappt werden sollte.

Einige Beispiele:
Platzlinien / Einzeln gemappte Bäume:
http://www.openstreetmap.org/?lat=47.98 … 8&layers=M

Eine Pollerorgie in Dortmund:
http://www.openstreetmap.org/?lat=51.51 … 8&layers=M

Einzelne Bereiche eines Parkplatzes einzeln gemappt (POI Inflation):
http://www.openstreetmap.org/?lat=48.96 … 8&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. 😉

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. 😉

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

EvanE wrote:

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

Edbert (EvanE)

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.

tippeltappel wrote:

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. 😉

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

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/Prop … s/Sidewalk
[3] http://wiki.openstreetmap.org/wiki/Sidewalk
[4] http://wiki.openstreetmap.org/wiki/Prop … parate_way

okilimu wrote:

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

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.

miraculixOSM wrote:

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.09 … 8&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.

blauloke wrote:

...
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.

hurdygurdyman wrote:

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 🙄

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.

viw wrote:

...
Du machst es dir aber auch wieder sehr einfach.
...

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.

hurdygurdyman wrote:

viw wrote:

...
Du machst es dir aber auch wieder sehr einfach.
...

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.

viw wrote:

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.

hurdygurdyman wrote:

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.

viw wrote:

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.

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.

viw wrote:

...
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.

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?

viw wrote:

tippeltappel wrote:

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. 😉

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

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.

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!

Gruß
tippeltappel

tippeltappel wrote:

...
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.

+1

tippeltappel wrote:

In Bezug auf den Parkplatz ist mein Kompromißvorschlag: eine große Fläche als Parkplatz mappen und die Teilflächen als Stellplatzgruppen taggen.

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.

Moin,

chris66 wrote:

tippeltappel wrote:

In Bezug auf den Parkplatz ist mein Kompromißvorschlag: eine große Fläche als Parkplatz mappen und die Teilflächen als Stellplatzgruppen taggen.

Ginge ja im Prinzip mit dem parking_space proposal, ...

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."