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.
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.
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.
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.
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.
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.048706&lon=13.74517&zoom=18&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.048706&lon=13.74517&zoom=18&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.912098&spn=0.000699,0.001206&t=h&z=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.
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.
@ 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
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.
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.
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.
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?
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.