Wenn du keinen Algorithmus kennst, der mich davon überzeugt, sehe ich da keine verlässliche Methode.

Meine momentane Einschätzung:

• Lose Spurways ohne irgendeine Verbindung → keine Chance

• Lose Spurways “eingerahmt” von einer area:highway-Fläche, oder in einer Relation pro highway → machbar mit großem Rechenaufwand und sehr komplexer Programmierarbeit

• Tag-basierende Lösung (:lanes) → verhältnismäßig einfach auswertbar, aber hat keine Lösung für komplizierte Kreuzungen und einige andere Details

Eine Relation wäre machbar, aber ihre flächendeckende Verwendung in der Praxis sehe ich als unwahrscheinlich. Ich befürchte eher, dass Mapper das Konzept mit Spur-Ways dann einfach verwenden und (vergeblich) auf eine funktionierende Auswertung hoffen würden, weil es für den naiven Betrachter ja so aussieht, als sei alles erfasst.

Auch für Routing ist übrigens die Zusammengehörigkeit relevant - zum einen für Straßennamen etc. wegen entsprechender Hinweise, was man notfalls auch über ein Duplizieren der Tags der Straße erreichen könnte, aber auch für Spurwechsel. Hast du dafür eine Lösung parat?

Ich sehe auch nicht unbedingt den flächendeckenden Einsatz. Aber dort, wo jetzt schon highway “vergewaltigt” wird, um Spuren abzubilden (siehe http://forum.openstreetmap.org/viewtopic.php?pid=277700#p277700 und extrem http://www.openstreetmap.org/?lat=51.324055&lon=12.291283&zoom=18 ), sehe ich den Ansatz als Alternative. Durch die high res-Bilder befürchte ich eine Inflation des highway-Missbrauchs, und da sollten wir schnell eine vernünftige Lösung finden.
Zum routing und Spurwechsel:
Vorausschauendes routing sollte über mehrere Kreuzungen/Abzweigungen hinaus möglichst wenig Spurwechsel erzeugen. Verlaufen parallele Spuren über eine längere Strecke oder über die nächste Abbiegemöglichkeit hinaus geradeaus, könnte entweder die geometrische Mitte zwischen den Spuren oder die gemäß regionaler Vorschriften bevorzugt zu verwendende Spur (rechte Spur bei Rechtsverkehr) für den Graph verwendet werden.
Für die Spurwahl bzw. den Wechsel kann der Router den frühestmöglichen Verbindungsknoten wählen. Die GPS-Ungenauigkeit macht insbesondere in Häuserschluchten die genaue Ortung der Spur als Standort sowieso unmöglich.

Bild doch erst mal die Fahrbahnen ab, bevor du die ganze Straße zusammen bastelst, weil bei ner zusätzlichen carriageway-Relation wäre das ganze dann wenigstens von der Realtionstypen kompatibel zu meiner Idee. Jetzt gerade habe ich auch gesehen, das man aus meiner Sicht lane_restriction nicht braucht, da man ja bei dir eh nur an der Kreuzung immer dahin fahren darf, wo auch ein verbundener Weg hinführt.

Naja, ich bin da so heran gegangen: Flächenunterstützung ist aus meiner Sicht auf jeden Fall Pflicht, auch soll darüber geroutet werden können. Dann sollen ja unbedingt auch die Spuren auf der Fläche richtig abgebildet werden können, weil dafür machen wir die Veranstaltung hier ja. Wenn man das alles als Anforderung zur Grunde legt, gibt es für Flächen ja nur zwei Möglichkeiten:

1. Man sieht die Fahrbahn, wie in der Realität, als eine zusammenhängende Fläche an. Die Spuren müßten dann, in logischen Konsequenz, über das Einzeichenn von Linien bzw. Stützpunkten auf dieser Fläche repräsentiert werden. Was sicher auch irgendwie geht, aber was aus meiner Sicht den Auswerteaufwand, weil man ja gerade über die Spuren routen will, enorm nach oben treibt. Im Grunde müßte man in der vorverarbeitung die Fahrbahn dann wieder segmentieren und dann über die Segmente routen, also kann man es aus meiner Sicht auch gleich mit Teilflächen machen.

2. Man mappt die (Teil)Spuren und setzt daraus dann die Fahrbahn zusammen. Damit kann man dann auch die Übergänge impliziet definieren, was gegenüber der Gesamtfahrbahn ein Vorteil ist. Routing ist da dann auch problemlos möglich, da er jeweils zwiscchen den Linien bzw. Mittelpunkten der gemeinsamen Linien der Flächen, definiert durch die Übergangsrelationen erfolgt. Ja, das geht, schließlich kommt man ja nur über eine Übergangskante der Fläche überhaupt auf sie rauf. Dann klappert man einfach lokal alle Relationen auf den Übergangslinien ab und schon weiß der Router, wo er potenziell weiter hinfahren darf. Somit sind also die Flächen problemlos auf Kanten/Knoten für den Router abgebildet worden und damit auch an sich zu einer Linienabbildung selbst kompatibel. So, jetzt kommt aber der große Nachteil: Nein, es ist nicht der erhöhte Speicherbedarf, da die Festplattenkapazitäten ja schneller wachsen sollten, als wie alle Straßen mit Spuren gemappt haben, es ist der Aufwand bzw. das fehlerträchtige Gefummel für das Mappen selbst! Mal abgesehen davon, das durch die vielen Teilflächen und Übergangsrelatione,n man da um vernüftige Toolunterstützung leider nicht drum herum kommt, hat das Schema ja auch mindestens die Komplexität des Oxomoa-Schemas… Immerhin sollte sich, bei meinem leider noch nicht überarbeiten Schema, die Flächenumsetzung leicht automatisiert zu Liniendarstellung wandeln lassen, sowie die Liniendarstellung in eine vorläufige, vom Mapper noch zu zu bearbeitende, Flächendarstellung (flächige Aufweitung der Linien und Erzeugen von Recht-/Vielecken an den Knotenpunkten der Wege).

Unübersichtliches Gefummel gibt es bei dir ja auch, da brauch ich mir ja nur mal die Kreuzungsflächen anzusehen, neben den ganzen Zusatztags für die Lanes selbst. Ob das trotz des bisherigen Verzichts auf Relationen, anfängertauglich ist, bezweifele ich stark, da ich es nach selbst nach nochmaligen kurzen Ansehen, zwar vom Ansatz, aber noch lange nicht im Detail verstanden, geschweige selbst getestet, habe.

Wie oben schon im Nachsatz andeutungsweise geschrieben, könnte es gehen, wenn mindestestens einer der Teilwege irgendwie mit dem restlichen Spurnetz verbunden ist und da dann eine Relation drauf ist, wo der unverbundenen Weg Mitglied ist. Das aber imho auch nur bei erhöhten Rechenaufwand, geht aber imho über entsprechendes Tagging (*:left/right=yes). Kennt jemand einen Fall eines Weges, welcher potentiell fürs Routing in Frage kommt und der in der Realität komplett unverbunden ist? Weil mir fällt da gerade echt nichts ein und der wäre mal eine interessanter Testfall. Ansonsten stimme ich da deiner Sicht zu den anderen Punkten voll zu.

Gedacht ist, zumindest bei mir, das *:left/right=yes/no-Tagging ja auch nur dafür um Sachen wie: “Man kann ja aber mit dem Fahrrad vom Radweg aus jederzeit über die Straße fahren…” abzubilden. Durch dieses Tagging weiß der Router dann nämlich da Bescheid!

Naja, nicht wenn man die alte Verkehrsbedeutungsklassifizierung in eine, bei mir, carriageway-Relation, und den Straßennamen und Sachen wie wikipedia=* dann in eine highway-Relation, bestehend aus carriageway-Relationen packt. Schließlich besteht die Straße ja, abstrakt, aus mehreren generischen Fahrbahnen (zusammenhängende Fläche von surface=*) und die Verkehrsbedeutung der Fahrbahn ist ja das, was eigentlich mit highway=primary/secondary/… gemeint ist. Und natürlich hat sie Straße den namen ja unabhängig davon, aus wie vielen Fahrbahnen, welcher Verkehrsbedeutung auch immer, sie sich zusammensetzt.

Moin!

Die Definition der “lane”-Tags finde ich brauchbar, nur lane=signals ist als name nicht intuitiv verständlich.
Wie schon von anderen erwähnt, fehlen einfach auswertbare Angaben zu möglichen Spurwechseln.
Die “highway_junction”-Fläche als bloßes Hilfsobjekt für den Renderer passt m. E. nicht zum OSM-Konzept.
Eine Fläche, die bis zu den Haltelinien reicht und auch Rad- und Fußwege umfasst, entspricht eher dem intuitiven Verständnis einer Kreuzung. Damit lassen sich bessere Routinganweisungen generieren und auch Fußwegquerungen der Kreuzung zuordnen.

Warum lädst du die Daten nicht in die Hauptdatenbank? Es sollten sich doch keine Konflikte zu bestehenden Tags ergeben.
Ich hatte auch einmal mit Einzelspurmapping experimentiert [1]. Die dabei erstellt Kreuzung [2] ist noch unverändert und hat niemanden gestört.

Viele Grüße
Stephan

[1] http://lists.openstreetmap.org/pipermail/talk-de/2012-January/092178.html
[2] http://osm.org/go/0HsPVeHXn-

ok, was hältst du von lane=control_signs? Suchmaschinen spucken das aus.

Nö, Spurwechsel ist möglich, solange lane_changing=no/no_right/no_left nicht gestetzt ist. Sollte ich vielleicht deutlicher machen

Stimmt, Hilfsflächen waren mein erster Ansatz. Die Zeichnungen in der grafischen Erläuterung stammen daher. Wenn wir die Straßenflächen sowieso erfassen wollen, macht dein Vorschlag Sinn. Dann wäre “highway_junction” unabhängig auch vom lane-tagging der Verbindungsbereich mehrerer highways.

Leider ist das Testgebiet http://www.openstreetmap.org/?lat=47.99061&lon=7.84464&zoom=18&layers=M durch den exzessiven Gebrauch von highway zur Spurdarstellung derart unübersichtlich, dass “meine” lanes dort das totale Chaos anrichten würden. Außerdem halte ich nichts davon, die Datenbank mit derartigen Gedankenspielen zu belasten.

Da räumlich getrennte Fahrbahnen schon jetzt als highway=* erfasst werden, ist ein zusätzliches carriageway auch als Relation wohl überflüssig und irritierend.

Das sehe ich anders, denn lane_restriction bildet die Verkehrszeichen bzw. die Richtungspfeile auf den Spuren ab, die Renderer dann auf die Straßen zeichnen und router für die Abbiegeanweisungen auch vorausschauend verwenden können, ohne dass dies aus den Winkeln der Spuren am nächsten Knoten erraten werden muss.

Ich kann doch den routern nichts als Pflicht diktieren. Ich kenne keine Methode, die routing über Flächen ermöglicht. Kanten und Knoten sind etabliert und die Spurerfassung als gerichteter Graph und die deren Auswertung ist bewährt und erfordert weniger Erfassungsaufwand, Speicher und Preprocessing.

Hier im Forum wurde von mir eine praktische Umsetzung an einem komplexen Beispiel gefordert. Dies habe ich mit dem Testgebiet in Freiburg geliefert. Zum Grundverständnis ist das aber nicht geeignet. Dazu dient http://ubuntuone.com/6HPgoCItJy0WtwKrKpU3H2.
Ich ging so vor:
Beginne an einer einmündenden Spur, verbinde diese mit allen von dieser aus erlaubten abgehenden Spuren und mache das im Uhrzeigersinn mit den nächsten einmündenden Spuren, bis du einmal um die Kreuzungsfläche herum bist.

Ich denke da nur an die ganzen Befürworter von Sachen wie cycleway/sidewalk=letf/right/both, weil die sehen highway=* bestimmt nicht nur als Ersatz für die Fahrbahn an, weil sonst würden sie ja die Fuß-/Radwege getrennt mappen. In der Praxis ist highway=* mehr als schwammig definiert und ist irgendwie inzwischen quasi Alles zwischen Fahrbahn, Fahrspur, Straße und z.B. Fahrstuhl. Ich denke eher schon noch an eine zusätzliche Relation für die Fahrspur, wenn sie als Fläche gemappt wurde, weil dann ist die Zugehörigkeit der Teilflächen zu den einzelnen Spuren ja nicht mehr unbedingt eindeutig…

Ich würde/habe das Problem von Verkehrszeichen und Richtungspfeilen, wenn es sich denn nicht immer per Algorithmus lösen läßt, als weitere Relation (z.B. type=street_marking) auf den jeweiligen Spuren definieren. Ich hatte das ja schon mal beschrieben und inzwischen gibt es eine testweise Umsetzung:
http://www.openstreetmap.org/browse/node/1925906781 und http://www.openstreetmap.org/browse/node/1925906794 als zu ergänzende (weitere Tags für die Realtion) Teillösung für meine simple Testkreuzung http://wiki.openstreetmap.org/wiki/File:Kreuzung.JPG. Das ist im Unterschied zu deiner Teillösung dann wenigstens universell.

Das war ja auch nur meine Anforderungsliste an ein Erfassungsschema, welche ich für mich zusammengetragen hatte. Flächenrouting ist sehr wohl möglich! Lösung siehe oben. Das die Erfassung dann aber alles andere als feierlich ist, hatte ich da ja auch schon geschreiben, aber das Schema löst zumindest erst mal recht universell die Spurmappingprobleme, die ich bisher so überlegen konnte, funktioniert für (hoffentlich) Flächen (für Flächen ist es noch nicht ganz zu Ende überprüft) und Linien und läßt sich dazwischen ohne große Probleme auch gemischt benutzen. Die Grundsätze sind soweit klar, die Feinheiten werden aber sicher noch Arbeit machen. Das sind solche Sachen wie z.B. das man natürlich die Übergansrelationen auch für das Linienschmea benutzen könnte, und zum Teil sogar muß, so das die Idee mit den 4-Richtungen da eher eine Vereinfachung war (die ist noch aus der Ueit wo das ganze ein reines Linienschema war…), aber wohlmöglich ist die nicht haltbar und man braucht die Übergansrelationen immer.

Es seh es mir vielleicht noch mal genauer an, auch wenn es vielleciht sinnvoller ist, mein Schema stattdessen zu optimieren, was ja überhaupt ja nur existiert, weil ich einen Vorschlag brauchte, um zu belegen, warum mir die anderen Schemata nicht so zusagen bzw. wie man es aus meiner Sicht noch besser machen könnte… Sicher sind viele Lösungen auch und dadurch übersichtlicher, aber sie sind dafür meist nicht unversell oder teilweise schlecht auszuwerten.

Deshalb habe ich in meinem Testgebiet u.a. bei der Kronenbrücke auch lane=cycleway (lila-orange gestrichelt) und lane=footway (grün-orange gestrichelt) erfasst:
http://ubuntuone.com/3iRiThVGBF8vqzpmzihFFL

Warum unbedingt als Relation? Wir erfassen z.B. oneway=+ oder maxspeed=* ja auch jetzt schon als tag am highway Obwohl dafür Schilder rumstehen. kann man Richtungsbeschränkungen usw. doch auch am lane=* genauso als Zusatztag anbringen. Dann muss ich als Renderer/Router/Erfasser nicht erst eine Relation durchstöbern, um zu erkennen, dass entsprechende regeln erfasst sind. Wer will, kann das Schild ja zusätzlich erfassen. KISS

Ich habe nichts dagegen, die Flächen einer Straße zu erfassen, damit diese auf Karten in hoher Zoomstufe der Realität entsprechen. Beispielsweise so wie hier:
http://wiki.openstreetmap.org/wiki/DE:Street_area
Für routing ist aber die Spur als gerichteter Graph wichtiger, denn beim Fahren kommt es zur Orientierung weniger auf die wirklichkeitsnahe Darstellung der Realität als auf die frühe und schnelle optische oder akustische Erfassung von Richtungsinformationen durch den Fahrer an. Dazu bedarf es generalisierter Darstellung wie z.B. diesen:
http://www.gpsmagazine.com/assets/nuvi465T_HR.jpg
http://static.mapfactor.com/images/n11_navigation.png
http://www.gpsmagazine.com/assets/review-tomtomgo930/map_screen_tomtom_lane_guidance.jpg
http://www.navigon.com/export/sites/default/common/images/features/NAVIGON_lane_assistant_android_DE.jpg
http://www.chip.de/ii/1/3/8/3/4/0/7/3/NAVIGON42Plus_Front_ActiveLaneAssistant_FunctionBar_D_600-79cbd10c1b1fa95f.jpg
http://www.smartoshop.com/images/kuvat/motorway.jpg
Das kann sich ein Router dann aus den lane=* direkt auslesen und, wenn er will, durch hereinzoomen auch noch in 2D/3D die verschiedenen Spuren nebeneinander anzeigen und farblich die Route hervorheben.

P.S.: Ein Ausgangspunkt für meine Überlegungen war dieser Workshop http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%c3%bcndel und davon insbesondere das Fazit von Tordanik: http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%c3%bcndel#Fazit_von_User:Tordanik

Vielleicht, weil ich die Realität mappen will! Wenn man böse ist, könnte man ja die maxspeeds=* alles löschen, da es keine Straßeneigenschaft ist, sondern die von einem Schild, das meist neben der Straße steht/hängt. Also mappt man die Laterne oder den Pfosten, wo es dran bestefigt ist. Man erfaßt dann einfach jedes Schild, seine Richtung und seinen Bezug (bei Zusatzzeichen), das geht am einfachsten udn genausten per Relation und entspricht mehr der Wirklichkeit, als wenn ich an 1000 kurzen Wegfragmenten (hoffentlich bringt der Mapper genügend Zeit mit und vergißt nicht mal ein Teilsegment…) von überlappenden Schildern und Routen jeweils die Tags ändern muß und dann immer noch nicht weis, wo und an was sich das Schild genau befindet.

Vielleicht sollte ich mir mal einen Papagei für das Forum hier zulegen, denn soweit ich weiß, ist das hier nicht der erste Post, wo ich schreibe, das man einfach nicht, und schon gar nicht mit begrenzten Speicherkapazitäten, eine Linie auf Tags und eine Fläche auf ein Linie abbilden kann! Das hatr nichts mit einfach zu tun, sondern eher mit beschränkt. Das gilt genauso für die Erfinder der Zusatztags auf https://wiki.openstreetmap.org/wiki/Proposed_features/advanced_navigation. Naja, inzwischen habe ich ja noch das eben frisch hochgeladene https://wiki.openstreetmap.org/wiki/File:Generisches_spurmodell.pdf als zuätzliche Referenz.

Das ist ja auch abhängig von der Datenlage, hat man nur Bilder in Landsat-Qualität, dann ist eine Erfassung als Linie imho genau genug. Habe ich tolle Hires-Luftbilder, dann erfasst man die Wege und Flächen alle Flächig mit allen erkennbaren Details. Soll heißen: man braucht ein Schema, das grundsätzlich von Flächen als genauersten Mappingrad ausgeht, darüber hinaus aber auf ein kompatibeles Linienschema reduziert werden kann, um nicht Flächen mappen zu müssen, wo man es nicht hinreichend genau kann. Nur so ist gewährleistet, das man wenn man Flächen hat, eben Flächen rendert und darüber routet und wenn dann irendwann Linien mit der Fläche verbunden sind, nicht der Router “geht nicht” sagt.

Ja, der gerichtete Graph ist wichtig, aber den kann man auch für den Router in der Vorverarbeitung/Datenaufbereitung konstruieren und eine Spur muß der Graph deswegen ja auch noch nicht sein.
Was das ganze dann mit unterstützenden Zusatzfeatures wie der darstellung der Spurzahl und richtung zu zun hat, verstehe ich jetzt gerade nicht.

Man beachte die interessanten Popcorn-Diskussionen bei allen Fällen, die über das reine lanes=* hinaus gehen…
…gleich mal noch einen neuen Tag dafür erschaffen, das die Spur erst 100m parallel, dann 50 m halblinks im 30°-Winkel verläuft und anschließend eine scharfe Linkskurve macht, um dann unter der Unterführung als Beschleunigungsspur einzumünden… Ach ja, die neuen Tags für die Art der Linie fehlen ja auch noch, und wenn dann noch der access=*, die maxspeeds, Überholverbote, Einbahnstraßen, Parkbeschränkungen, die Bordsteinhöhen und -übergänge alle durch geeignetes “einfaches” Splitting und Tags am Weg dargestellt werden, wird das ganze bestimmt alles total einfach und übersichtlich… KISS eben…

Danke für den Hinweis auf die Wikiseite, das kannte ich noch nicht und macht es auch einfacher, weil mein Schema am erhesten der der dort vorgestellten Variante 5 + 1 entspricht, aber deutlich darüber hinaus geht.

Ja, und iregndwie kotzt es mich auch an, als ich dort sehen mußte, das man mit dem Thema seit 4 Jahren nicht aus dem Arsch gekommen ist… Weil irgendwann muß man ja mal die Entscheidung zwischen zunehmender Datenmüllhalde aus halben Lösungen, die leicht zu taggen sind und auch irgendwie erst funktionieren, aber dann durch neue, ebenfalls beschränkte Lösungen erweitert werden müssen, und unterstützung der Mapper durch geeignete Tools/libs, für den optionalen/ersatzweise Einsatz erweiterter Taggingschemata treffen.

Was für ein Quatsch. Willst du auch die Namen auf Schilder setzen statt auf die Straßen? Namen, maxspeeds usw. sind klar die Eigenschaften der Straßen, nicht der Schilder. Für Anwendungen ist es völlig egal, wo die Schilder stehen und ob überhaupt welche dort stehen. Es zählt nur, wo die Eigenschaften gelten. Darum finde ich es albern, Straßenschilder in OSM überhaupt zu erfassen.

Mit der Argumentation könnte man ja genau so gut auch Bänke an Wander-/Fußwegen mit an den Weg taggen.

Naja, wenn es aus deiner Sicht vollig egal ist, wo die Schilder stehen, warum werden denn dann die Straßen überhaupt wegen der Eigenschaften gesplittet?
Wenn keine Schilder dort stehen/hängen dann ist das Eintragen von Daten, die nicht mit der Realität übereinstimmen.

Im Rahmen der Einschränkungen die OSM für die Linien und Flächen hat, dass beide nur durch Punkte definiert werden, wäre es rein technisch sogar vollständig moglich, diese rein in Tags darzustellen, da man in den Tags beispielsweise relative Punktkoordinaten ablegen könnte. Allerdings ist dies natürlich in dieser universellen Form nur sehr schlecht handhabbar und daher nicht sinnvoll.

Für die Navigation ist diese exakte Beschreibung aber nicht nötig. Meine Ansatz ist daher, die funktionale Beschreibung für die Navigation in den Tags des primären Highway unterzubringen.

Weiterhin können die Tags eine rudimentäre Beschreibung für den Spurverlauf (durch Parallelabstände) und die von den Spuren belegte Fläche (durch Spurbreite) enthalten. Für viele Straßenabschnitte dürfte diese Beschreibung jedoch hinreichend genau sein.

Wenn Abschnitte eine weitergehende Beschreibung erfordern und die Datenlage entsprechend gut ist, sollten ausschließlich auf den kritischen Abschnitten zusätzliche spezielle OSM Wege hinzugefügt werden, die dem Renderer dann Spurverlauf oder Spurbegrenzung vorgeben. Die Spurbegrenzung kann dabei flächendefinierend sein, auch wenn es sich nicht um eine konventionelle OSM Fläche handelt. Funktional haben diese zusätzlichen speziellen OSM Wege keine weitere Bedeutung.

OK, absolut gesehen hast du natürlich recht, praktisch reichen aber die 255 Zeichen für den Wert schon nicht mal mehr für die Definition der bundeseinheitlichen Feiertage nach opening_hours=* inkl. Beschreibung aus.

Aber die gleichen Daten sollen auch gerendert werden und da möchte ich auch die gemappten (Teil-)lfächen richtig dargestellt sehen und nicht nur zwei sich kreuzende Linien oder nur ein Quadrat als Kreuzung mit ein paar Linien dran.

Klar kann man Linien zu Flächen ausweiten und ich würde das z.B. auch als Zeichen-/Konstruktionshilfehilfe für Flächen bei meinem Schema machen, aber das das ganze sieht gerendert bei komplexeren Kreuzungen nicht so toll aus, da brauchst du dir nur mal “Street area” anzusehen, da hat es Marek nämlich vorgemacht. Das ist für mich als Hauptlösung nicht praktikabel, sondern nur als Fallback wenn man mangels Daten nur Linien einzeichnen kann. Sonst will ich da nach Möglichkeit richige Flächen sehen.

Für die meisten 0815-Straßenverläufe sieht sicher halbwegs ordentlich aus, aber die Probleme der flächigen Linienersatzdarstellung gehen ja schon bei parallel verlaufenden Fuß-/Radwegen (sollten sie gemappt sein) und angrenzendem überdecktem landuse=* los. Als Vorgeschmack auf die Probleme mit als Linen einmündenen Fuß-/Radwegen, braucht man sich ja nur mal in Mapnik anzusehen, wie highway=service + access=private in z.B. highway=residential einmündet.

Schon mal dran gedacht, das man Linien am besten als Linie und Flächen als Fläche darstellt? Das geht nämmlich deutlich einfacher, schneller und intuitiver als das ganze über Tags, funktionslosen Hilfhilen-Müll oder andere Hacks darzustellen.

Besser geht man von Flächen aus und macht die für den Router zu Linien, das bringt mehr, als sich gleich vom Anfang nur auf Linien zu beschränken, wenn man eigentlich auch Flächen braucht.

Das macht übrigens: https://wiki.openstreetmap.org/wiki/File:Generisches_spurmodell.pdf.

Der Vorschlag löst immerhin schon mal Routing über Flächen, die Querungs-/Wechselprobleme bei straßenbegleitenden Wegen und die Kompatibilität bzw. das Downgrade vom Flächen- zum Linienschema. Da fehlt natürlich noch das diverse Autofahrer-Spielzeug wie Markierungen und Schilder, die man da noch, als Relationen auf den Übergangswegen, bei Markierungen, bzw. Relation mit from/to/sign und zum Knoten des Schilderpfosten, auf dem Stück wo das Schild steht (bei Schildern), einbauen muß.

Ich würde ehrlichgesagt glaube ich die Markierung als zusätzlichen Weg zwischen die Spuren legen. Das dürfte einfacher zu Rendern sein und ist flexibler, wenn man zum Beispiel mehrere Spuren erstmal nur als eine Fläche mappt. Außerdem trennt es Aussehen und Bedeutung, die sich ja unterscheiden können. Genauso mappen wir ja auch die Schilder (so wir das tun) als eigene Knoten und die zugehörigen Auswirkungen als Relationen oder Tags an den Wegen.

Da müßte man natürlich die Daten auf mehrere Tags verteilen oder die Beschränkung beseitigen, dies ist ja aber ohnehin nur eine theoretische Überlegung.

Sofern nur die Navigations-relevanten Daten erfasst werden, kann man natürlich nicht erwarten, dass dies perfekt gerendert wird. Aber natürlich sollte die Navigationslösung damit kompatibel sein, dass die für perfektes Rendering erforderlichen Daten zusätzlich erfasst werden können.

Sicher ist dies nicht in allen Fällen hinreichend. Das Konzept “Street area” sehe ich auch als unzureichend an.
Es gibt aber 3 Fälle, in denen eine Beschränkung auf die rudimentäre Beschreibung für den Spurverlauf sinnvoll ist:

Wenn diese Beschreibung für das hochwertige Rendering ausreichend ist. Beispielsweise sehe ich keinen Grund, tausende Kilometer Autobahnen mit einem komplizierter zu zeichnenden Einzelspur-Linien oder gar Flächenmodell zu erfassen.

Wenn die Datenlage keine höherwertige Beschreibung zuläßt. Dies kann sowohl durch Fehlen eines entsprechend hochauflösenden und gut ausgerichtetem Luftbildes, als auch durch Verdeckung durch Wolken, Bäume, Tunnellage oder Überbauung bedingt sein. Ebenso kann das Luftbild veraltet sein.

Wenn sich noch kein Mapper die Zeit genommen hat, die Daten für ein optimiertes Rendering zu erfassen.

Zunächst einmal werden in OSM Linien als Punktfolgen und Flächen durch derartige Linien definiert. Nun muss die umschließende Linie ja nicht immer die optimale Variante sein, um eine Fläche zu beschreiben, wie man z.B. schon an der Einführung des Multipolygon erkennt.
Z.B. könnten auch zwei weitgehend parallele Linien eine dazwischenliegende Fläche definieren.

Zum Rendern wäre es wohl am besten, wenn man den genauen Linienverlauf der Straßenränder als auch der Fahrbahnmarkierungen hat. Dieses sollte auch das Ziel sein. Nun haben wir aber üblicherweise viele parallele Linien. Hier ist dann mein Ansatz, diese nicht zu zeichnen, sondern durch den Parallelabstand zu definieren. Dies ist erstens einfacher und zweitens genauer als diese einzeln einzuzeichnen. Selbst wenn der Mapper die Nodes für zwei Parallelkurven exakt setzt, kann die Kurveninterpolation dazu führen, dass der Abstand der beiden Kurven beim Rendern sehr unschön schwankt. Man müßte daher eine extrem hohe Node-Dichte wählen. Wenn jemand die Kurven auf Basis unzureichender Luftbilder oder einfach nur etwas schlampig zeichnet, wird es natürlich noch schlimmer.

Die maxspeed ist, im Gegensatz zur Bank, eine Straßeneigenschaft; sie wird dem Autofahrer nur durch Schilder mitgeteilt! Somit kann es theoretisch ein maxspeed ohne Schilder geben, nur werden weder wir, noch die Autofahrer es wissen.

Ich habe mir mal dein https://wiki.openstreetmap.org/wiki/File:Generisches_spurmodell.pdf angeschaut, wobei ich noch nicht verstehe, wieso dies schon eine Referenz sein soll
Unter anderem beziehst du dich auf http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area/de . Dort wird aber ausdrücklich vorgeschlagen, Straßen analog zu den waterways doppelt als Linie für die Mittelachse und als Fläche zu erfassen, was imho aus Gründen der Abwärtskompatibilität auch weiter erforderlich bleibt. Die genaue Flächenerfassung ist für das Rendern von Karten in hohen Zoomstufen wünschenswert, für Routingauswertungen und -anweisungen eher nicht, weil hier eine starke Generalisierung in Form von Pfeilen oder Sprachanweisungen erforderlich wird, um den Fahrer nicht mit Details zu überfordern, die ihn vom Straßenverkehr ablenken. Die Generalisierung willst du durch preprocessing herbeiführen, wobei du allerdings auch darauf eingehen solltest, wo und in welcher Form dies geschehen soll. Ich bezweifele, ob dies bei der Menge von abhängigen und verschachtelten Relationen mit all den resultierenden Fehlermöglichkeiten überhaupt zuverlässig möglich ist. Wie ein funktionierendes Erfassungstool gestaltet sein muss, sehe ich auch noch nicht.

Mein erster Eindruck deines Vorschlags für die Flächenerfassung mit Informationen zum Routen ist, dass er zwar theoretisch machbar, aber leider mindestens genauso komplex wie die bisher vorliegenden Alternativen für das spurbezogene Erfassen von Richtungsanweisungen und Spureigenschaften ist. Deshalb bezweifele ich, ob es zu einer Akzeptanz durch die Masse der Mapper kommen kann.

Was hältst du davon, deinen Ansatz mal an einem praktischen Beispiel wie etwa diesem http://wiki.openstreetmap.org/wiki/File:StreetsGeneralisedVectorLevel.JPG umzusetzen? Dann hätten wir die Chance, die Möglichkeiten und Grenzen des Schemas besser abzuschätzen als wie durch das Lesen von elf Seiten Text. Auch ich bin ein Freund von KISS, erkenne dieses Prinzip in deinem Vorschlag aber noch nicht.

Und zuletzt noch ein Tip:
Manchen wird wie mich die teilweise von dir verwendete Wortwahl abstoßen. Begriffe wie “kotzt es mich an”, “aus dem Arsch” und andere sind in einer sachlichen Diskussion unangebracht.

Das ist wie gesagt, noch kein komplett fertiges Schema, aber es löst eben genau die Sachen, wo immer alle jammern, das man die nicht lösen kann…
Der Bezug zu “Street area” beschränkt sich darauf, das die wesentliche Idee von dort ist und von mir weiterentwickelt wurde, sonst hat es keinen weiteren Bezug dazu. Das ist also eine reine Danksagung.

Wieso soll die Doppelerfassung nach meinem Schema konkret weiter erforderlich sein? Hast du da ein Beispiel wo man unbedingt noch die Linien braucht, wenn man die Flächendarstellung hat?

Wie man das Schema auf eine reine Linendarstellung für den Router bringen kann, steht doch unter Routing bzw. Fall 6, da verstehe ich nicht, was jetzt dein Problem ist.

Hast du einen konkreten Fall, wo es nicht möglich ist?

Das Ziel war erst mal ein funktionierendes Erfassungsschema, das auch Flächenrouting unterstützt und noch nicht der konzeptionelle Entwurf für ein Erfassungstool für das Schema. Prinzipielle Ideen wie z.B. Linien zu Flächen für die einfachere (Grob)Erfasung aufzuweiten, hatte ich oben ja schon mal kurz angerissen.

Was ist denn an den fünf Relationen (da ist type=crossing schon in beiden Varianten gezählt) und an Flächen und Linien, die nicht mal zwingend getaggt sein müssen, jetzt so komplex? Drei der vier verschiedenen Relationen sind simpkle Sammelcontainer für die Spur, Fahrbahn und Straße. Da sind die komplizierten, fallabhängigen Tags, aller bisher vorgeschlagenen Linienschemavarianten, doch wesentlich komplexer!