nö, nur “anders zeichnen” - ist zumindest meine Meinung. Das müsste wirklich ohne andere oder gar neue Tags gehen.
highway=service mit area=yes haben wir ja schon öfters. MMn könnte area auch weg und das war es dann.
In der Datenbank, die in der Regel mit osm2pgsql gepflegt wird, sind die Straßen und die Flächen schön sauber getrennt, da diese automatisch in unterschiedlichen Tabellen landen. Einfach nur aufgrund ihrer Geometrie (Linestring und geschlossener Linestring) . Was will man mehr?
Lieber Walter,
nun, mal wollen wir eine Donut Topologie, Mal nicht. Also Linestring bzw.geschlossener Linestring. Vielleicht verstehe ich hier aber Was nicht.
Es wäre schön, wenn Du anhand eine Skizze zeigen könntes wie Du es meinst.
Grüße,
Marek
Ich glaube auch, dass er vergessen hat, dass ein highway eine geschlossene Linie nicht als Area interpretieren darf, da sonst seeeeehr viel kaputt geht.
Ein Way im OSM-Sinn ist eine einfache Linie aus mehrere Punkten. Das nennt man in GIS: Linestring. — Eine Fläche ist ein geschlossener Way und das nennt man “Closed Linestring”.
Straßen bestehe bei uns aus mehreren Ways - die landen automatisch in planet_osm_roads. Aber auch Mauern oder Hecken oder Richtfunkstrecken: alles sind Linestrings. Der Tabellenname …roads ist nur historisch.
Sobald der Way geschlossen ist (erster und letzter Node sind identisch) wird das ein “closed linestring” und landet in planet_osm_polygon. Das ist zum Beispiel bei allen Landuse (residential, commercial, …) oder highway=service der Fall - völlig unabhängig vom Tagging.
Danach hat man als Auswerter die freie Auswahl: nehme ich die Straßen aus der Roads-Tabelle oder aus der Polygon-Tabelle oder gar aus beiden. Mapnik nimmt auf jeden Fall beide.
Multipolygone/Boundaries werden ähnlich behandelt: Routen landen bei den Roads und Flächen bei den Polygonen. Ebenfalls vollautomatisch.
Was ich eigentlich klarstellen möchte: Ein spezielles Tagging um Wege von Flächen zu unterscheiden, ist mMn nicht nötig. Das macht die Software mit links - und zwar seit 2007 (?)
Gruss
walter
EDIT: Nun, ich hab das ein wenig generalisiert, aber das Prinzip sollte schon zu erkennen sein.
Lieber walter, danke für die Erklärung.
Beginnt eine Straße und endet also in dem gleichen Punkt, ist die automatisch eine Fläche.
Das kann in einigen Fällen problematisch sein. Etwa dann wenn eine geschlossene Service road eine Donut Topologie hat.
Oder ein Feldweg um eine Wasserfläche herum.
Ich glaube, wir müssen differenzieren.
so einfach geht es nicht. Ein Unterscheidungsmerkmal (sei es durch zusätzliche Angabe von area=yes oder spezielle Tags für die Flächen) muss vorhanden sein. Es gibt etliche “geschlossene Linien”, welche keine Fläche darstellen, z.B. alle Kreisverkehre oder etliche Biegungen von Straßen/Wegen, die noch eine “diagonale Abkürzung” haben usw.). Auch Fußgängerzonen als Plätze können nur aufgrund “area=yes” von Straßen nur für Fußgänger (meist Einkaufspassagen) unterschieden werden, welche durchaus um ein Einkaufszentrum herumführen können. Gleiches Problem bei highway=service - handelt es sich bei der geschlossenen Linie um einen frei überfahrbaren Platz oder verläuft “highway=service / service=parking_isle” kreisförmig?
Wenn Straßen als Fläche gezeichnet werden, dann zusätzlich(!) zu herkömmlichen Linien (Routing mit aktuellen technischen Möglichkeiten) und mit abweichendem Tagging (sonst hat man drei parallele Straßen - die herkömmliche Linie und die beiden nächsten Ränder der Fläche). Das Proposal von Marek geht schon in die richtige Richtung.
Ja, da hast du wirklich Recht. Manche closed linestrings sind Flächen und andere nicht. Muß mal nachsehen wie das osm2pgsql feststellt.
Der area-tag ist da mein Verdacht. Aber mit dem könnte ich “leben”
Nun denn, da war ich wohl ein wenig zu konsequent.
Irgendwo hatten wir doch schon mal so eine Straßenflächen-Diskussion
Von mir eine erste Idee:
Warum nehmen wir für die Flächen denn nicht z.B. area=highway oder area=sidwalk usw. Dadurch, dass der way "highway=* über diese Flächen führt, ließe sich doch die geometrische Zuordnung auswerten und für Darstellungen verwenden Je nach Bedarf holt sich der highway-linestring zusätzlich Informationen aus der area welche er kreuzt oder umgekehrt.
Schlagt bitte nicht zu fest, wenn ich falsch liege.
Nun,
ich habe es eingetragen.
Bitte sieht Euch den Vorschlag an. http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
soll ich den Part “Advanced concept for rendering optimization” vielleicht besser woanders einbauen, damit es die Leute nicht verwirrt?
Dann könnten wir mit der Abstimmung für den kleinsten gemeinsamen Nennen starten, oder?
Ich halte es für ungünstig, das etablierte area=yes/no um Attribute wie area=highway zu erweitern. Warum? Dadurch würde die Information verlorengehen, dass es sich um einen highway handelt. Entweder nutzt man (wie bisher) 2 Attribute (highway=* area=yes) oder man führt highway:area=/area:highway= ein. Letzteres allerdings zum Nachteil, dass alle Auswertungsprogramme und Editoren erst nachgerüstet werden müssten. Die Variante mit 2 Attributen hat sich für highway=pedestrian bereits durchgesetzt und hat nur den Nachteil, dass es 2 Attribute sind. Aber sogar die Editoren könnten damit auf Anhieb umgehen und es gibt sicherlich weniger Widerstand in der Community. Glaube ich zumindest mal…
Hey. Ich habe da gleich mal eine Frage und einen Änderungsvorschlag
Worin besteht der Unterschied zum area:highway Proposal ?
Statt “area=sidewalk” sollte besser “area=sidepath” verwendet werden, so das eine Verbindung zu “bicycle=use_sidepath” bzw. “cycleway:left/right=sidepath” geknüpft werden kann. (Bei Alternativen Lösungen analog.)
Junctions ist anders. An jeder Kreuzung wo 3 oder mehr Straßen antreffen, gibt es einen connector.
Dadurch kann in zukunft die Kreuzungsfläche besser gerendert werden, was ich ansatzweise in dem "Advanced Part2 beschreibe.
2. Ist ok.
Also ich hab mir beide Proposals noch mal durchgelesen und ein wenig sinniert und ich kam zum Schluss, dass das derzeit benutzte highway=* area=yes Tagging auch ein paar Nachteile hat, vor allem die Notwendigkeit, der area auch den Namen zu geben, was ja auch nicht das gelbe vom Ei sein kann. Also frage ich mich: warum möchten wir eigentlich Straßen als area darstellen? Da fällt mir ein:
Weil es einfach besser aussieht
Weil man Kreuzungen viel detaillierter mappen kann mit all den Inseln, etc.
Weil man theoretisch die Breite einer Straße ermitteln kann
Weil man die surface so automatisch bekäme (in Deutschland wohl als default „paved“)
Das derzeitige Benutzen von highway=* heißt auch, dass Attribute, die ein highway=* implizit hat, auf einmal auch für die area gelten, was z.B. im Falle von oneway=no doch eher erheiternd ist. Wenn wir highways als Flächen erfassen sind einige Attributem die ein highway=* haben kann/muss überdies ziemlich unsinnig (z.B. name, maxspeed oder oneway), andere hingegen besser (z.B. access, surface). Ich halte es deshalb für geboten, sich vom alten highway=* area=yes zu verabschieden, da highway=* Dinge impliziert welche auf einer area keinerlei Bedeutung haben und eher zu Problemen führen könnten. Nach einiger Überlegung finde ich das Tagging des area:highway=-Proposals für sinnvoller als weiterhin area=yes zu nehmen oder auf area=highway: zu wechseln. Der Trend geht nicht umsonst in letzter Zeit zu Key:Subkey=*
Abgesehen davon gat mir die gute Ausarbeitung Deines Propoals schon immer gut gefallen, befürchte aber, dass es wieder Stimmen geben wird, die „zu komplex!“ rufen werden. Ob man z.B. die Kreuzungen separat erfassen sollte oder nicht halte ich für diskussionswürdig. Ich sehe momentan noch den Informationsgewinn im Verhältnis zum Aufwand als nicht so toll an. Gerne lasse ich mich eines Anderen belehren.
Nur zur Erinnerung: Ich hatte als Flächen-tag für Straßenflächen lediglich area=highway vorgeschlagen und angeregt, dass alle anderen highway-Attribute auf dem way (highway=*) gelegt werden. Durch die Geometrie des innerhalb der Fläche liegenden highway-linestring können Auswertungen die linestring-Informationen den highway-Flächen zuordnen.
Dadurch erübrigt es sich auch m.E., values wie area=highway:residential einzuführen. Redundanzen könnten so verhindert werden. Ich denke jetzt bewusst nicht daran, highway= und das entsprechende area=* in eine Relation zusammenzufassen.*
Wenn wir immer dort, wo tatsächlich eine Haltelinie direkt vor der Kreuzung ist, mit dem Zeichnen der Kreuzungsfläche beginnen, kann aus den Straßenflächen und dem Tagging für sie Straßenpolygone (proposal Lanes) das Bild wie oben gerendert werden.
Die weiteren Beispiele die das detailliert erläutern sowie die mapping guidelines für dieses Thema bin ich Euch natürlich noch schuldig, daher verstehe ich die Fragen.
Der Proposal dafür wird mich einige Tage Arbeit kosten, aber ich möchte es in den nächsten Tagen definitiv machen, damit man dies auch besser versteht.
Eines im Vorab: Ich bin mir ziemlich sicher, das wir damit Google und alle anderen ganz schön abhängen können.
Ich wollte doch nur wissen, wie der aktuelle Stand zur Straßenbreite ist.
Grundsätzlich finde ich Flächen zur Linie auch gut. Aber wirklich alles einzeln als Fläche? Wären für eine normale Straße mindestens 5 Flächen: Fußweg,Parkreihe,Straße,Parkreihe,Fußweg.
Hi Chatter, ups
Natürlich, Du hast Recht. Das Thema passte aber.
In Zukunft werden wir sicherlich auch den Detaliierungsgrad mit 5 Flächen erreichen, wenn man bedenkt wie das Projekt noch vor 5 Jahren aussah und wie viele neue User dem Projekt beitreten.
Vor 5 Jahren habe ich es kaum für möglich gehalten, dass wir Gebäudegrundrisse einzeln erfassen.
Der Ansatz kann uns einfach einen neuen Entwicklungsschub geben. Mich irritiert an einigen Stellen mittlerweile, dass die Karte die in den Titel “Street” hat, ausgerechnet die Straßen am wenigsten detailliert rendert. Insbesonder bei großen Kreuzungen stört dies und führt in einigen Fällen zu einem Übermaß an Verbindungselementen weil die Leute die Realität abbilden wollen.
