Das finde ich auch gut, dass ganze Thema darf eines nämlich auf keinen Fall - vorschnell und übereilt angegangen werden.
Deswegen ändere ich ja auch nichts daran sondern bin der Meinung das wir hier mal diskutieren sollten… Und wie du und ich ja schon geschrieben haben… Technisch ist daran gar nichts auszusetzen. topologisch absolut ok gemappt…
Nur… Nach meiner Erwartungshaltung die ich an eine Karte habe, wird hier die Realität auf der Karte nicht so abgebildet wie sie ist (und das ist immer mein persönlicher Anspruch an die von mir erfassten Daten)
Als Vergleich hier mal Google https://www.google.de/maps/@49.5115861,8.5566614,19z und Falk https://www.falk.de/maps?gs=falkOriginal&gp=49.511863,8.557190&gz=16
Bei Google sieht die Kreuzung zwar aus meiner Sicht erstmal realitätsgetreuer aus, da sie nicht diesen komischen 5-Stern in der Mitte hat, aber der Kniff ist, das Google einfach schon bei Sperrflächen anfängt zu trennen, nicht erst bei der baulichen Trennung (imho. finde ich dass sogar in vielen Fällen besser)…
Und Falk hat die meiner Meinung beste Ansicht, wenn ich eine reine Straßenkarte haben möchte… Einfach eine Kreuzung zwischen 2 Straßen… Ohne gedöns… Aber halt auch nur gut wenn ich einen groben überblick über den Verlauf der Straßen will… Wenn ich wissen will, wo die Fußgänger hin können, bringt mir sowas nichts.
Und die OSM ist eben nicht mehr nur eine einfache Straßenkarte (so wie die Falk-Karte) sondern mittlerweile eher wie ein CAD-Abbild einer Satellitenansicht, was aus meiner Sicht auch sehr gut so ist und überhaupt erst den echten Endusermehrwert ausmacht (Die Daten interessieren ja nur uns Interessierte). Und die ganze Arbeit die in den Polygonlinen steckt, war/ist auch gut und wichtig - eben weil man damit supertoll Routen berechnen kann. Nur im Moment haben die Renderer gar keine Chance es anders zu machen - Die Width-Tags auszulesen halte ich für sehr schwierig und Falsch, da sie nur eine Kenngröße darstellen. Ich jedenfalls habe noch keine Straße entdeckt, bei der sich die Breitenangabe an jedem Knick und auf Ganzer länge immer überall korrekt ändert, das könnte auch niemand erfassen, bzw. wäre es viel mehr Aufwand das zu erfassen, als diese Informationen z.B. aus Area-Flächen automatisch zu errechnen! Straßen sind eben in der Realität keine “plattgewälzten” symmetrischen Linien, sondern sie sind Asymmetrisch und mal rechts ein bisschen bauchig, mal links einen Meter Breiter, damit man besser abbiegen kann… In Kurven mal ein bisschen breiter, damit man besser um die Kurve kommt (Serpentinen)… Das kann man alles mit Linien-Tags gar nicht darstellen.
Mein Parade-Beispiel ist immer ein Fluss. Einen Fluss mappen wir grundsätzlich als Area. Wenn jetzt ein Fluss in den anderen fließt und im Delta herummeandert, mappen wir für gewöhnlich jeden einzelnen Meander (schreibt man das so? ) als Fläche. Die Flussmitten jedoch haben ihre Polyline… wie z.B. hier beim Rhein http://www.openstreetmap.org/way/83015625#map=9/51.3436/6.6093… Die Koexistenz zwischen Wasserfläche und “Linie” ist hier irgendwie völlig normal und keiner Hinterfragt es groß… Aber bei Straßen schon?! das Verstehe ich dann irgendwie nicht so ganz.
Angenommen die Kreuzung wäre mit Areas gemappt… und die Renderer würden auf das System irgendwann wechslen. Dann sähe die Kreuzung aus wie sie in der Realität ist. Die Spuren könnten dann dort getrennt werden, wo es in der Realität sinn macht. So wie es jetzt abgebildet ist würde man - wenn man sich exakt an die Linien hält in jeder Kurve eine durchgezogene Linie überfahren und bekommt Probleme mit der StVo…, wenn die Standart-Ansicht aber Flächen rendert, sind die Daten nicht mehr zwangsläufig an solche Dogmen gebunden wie “Wir trennen nur wo baulich getrennt ist” … sondern dann kann man davon - wo es sinn macht auch abweichen. Z.B. um nicht über durchgezogene Linien geroutet zu werden… Die Kartenansicht - bleibt dann - von so etwas unberührt, da sie auf den Areas beruht.
Analog zum Flussmodell … Wenn Rhein jetzt irgendwo unter Wasser ne Sandbank hätte, dann müsste man die “Fahrspur” des Schiffes auch entsprechend anpassen und um die Sandbank herumleiten… Die Ansicht des Flusses sollte sich dabei aber nicht ändern, da der von oben Betrachtet immer noch das gleiche Bild zeigt.
Ich glaube dass sich highways-Area und Polylinien ergänzen und nicht gegeneinander stehen sollten!
Deinen Beitrag fand ich sehr gut… vielleicht taucht Marek ja auch noch in diesem Thread auf… Aber das ist konstruktives herangehen an die Sache… Deinen Ansatz hingegen halte ich für falsch, da ich ganz massiv gegen
bin. Warum? Weil es eine wahnsinnige Arbeit bedeutet die alles bisher dagewesen bei weitem übersteigt… In welchem Abstand soll man die Straßenbreiten den Messen gehen, in 50m Stücken, in 5m Stücken…? Wenn ich alleine an die Ortsstraße vor meiner Haustüre denke, ergibt sich bestimmt auf 2km Länge 300-400 mal eine Breitenänderung im Bereich von 1-2m. Wer soll das auf diese Weise erfassen? Und wenn ich die Daten aus den Satellitendaten ermessen muss, dann habe ich die Area deutlich schneller abgezeichnet und kann einen OSM-Mathematiker dransetzen, der mir dann die Breite an jeder Stelle aus dem Polygon errechnet.
Das dürfte sehr merkwürdige Ergebnisse bei asymmetrischen Straßenverläufen ergeben, da der Schlauch ja immer von der idealisierten Mitte aus betrachtet wird. Wenn die Straße jetzt aber nur Rechts breiter ist (z.B. in der Kurve einer Serpentine) wird die Straße aber nach deiner Methode überall gleich breiter. Und das dürfte dann sehr merkwürdig aussehen.