You are not logged in.

#351 2012-10-01 08:45:54

hurdygurdyman
Member
Registered: 2009-12-10
Posts: 2,850

Re: Routing / Spurmapping

Fabi2 wrote:

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

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

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

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 cool

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/revie … idance.jpg
http://www.navigon.com/export/sites/def … oid_DE.jpg
http://www.chip.de/ii/1/3/8/3/4/0/7/3/N … 1fa95f.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/Wiki … %c3%bcndel und davon insbesondere das Fazit von Tordanik: http://wiki.openstreetmap.org/wiki/Wiki … r:Tordanik

Last edited by hurdygurdyman (2012-10-01 09:14:03)


Gruß Michael (hurdygurdyman)
Ich mappe für Menschen, die Karten verwenden, welche aus OSM-Daten gerendert wurden tongue http://de.wikipedia.org/wiki/KISS-Prinzip cool

Offline

#352 2012-11-09 06:59:35

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Routing / Spurmapping

hurdygurdyman wrote:

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

Warum unbedingt als Relation? Wir erfassen z.B. oneway=+ oder maxspeed=* ja auch jetzt schon als tag am highway Obwohl dafür Schilder rumstehen.

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.

hurdygurdyman wrote:

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 cool

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/Pro … navigation. Naja, inzwischen habe ich ja noch das eben frisch hochgeladene https://wiki.openstreetmap.org/wiki/Fil … modell.pdf als zuätzliche Referenz.

hurdygurdyman wrote:

Ich habe nichts dagegen, die Flächen einer Straße zu erfassen, damit diese auf Karten in hoher Zoomstufe der Realität entsprechen.

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.

hurdygurdyman wrote:

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.

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.

hurdygurdyman wrote:

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.

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

hurdygurdyman wrote:

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

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.


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#353 2012-11-09 08:55:36

fkv
Member
From: Wien
Registered: 2010-08-12
Posts: 772
Website

Re: Routing / Spurmapping

Fabi2 wrote:

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)

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.

Offline

#354 2012-11-09 20:20:48

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Routing / Spurmapping

fkv wrote:
Fabi2 wrote:

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)

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.

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

fkv wrote:

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.

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.


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#355 2012-11-10 03:01:12

slhh
Member
Registered: 2012-09-02
Posts: 358

Re: Routing / Spurmapping

Fabi2 wrote:

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/Pro … navigation.

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.

Offline

#356 2012-11-11 13:15:19

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Routing / Spurmapping

slhh wrote:
Fabi2 wrote:

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 hat 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/Pro … navigation.

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.

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.

slhh wrote:

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.

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.

slhh wrote:

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.

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.

slhh wrote:

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.

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.


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#357 2012-11-11 14:30:37

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Routing / Spurmapping

Fabi2 wrote:

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/Fil … modell.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ß.

Last edited by Fabi2 (2012-11-11 14:34:20)


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#358 2012-11-11 22:17:46

errt
Member
Registered: 2009-12-01
Posts: 1,068

Re: Routing / Spurmapping

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.

Offline

#359 2012-11-12 00:25:02

slhh
Member
Registered: 2012-09-02
Posts: 358

Re: Routing / Spurmapping

Fabi2 wrote:
slhh wrote:

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.

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.

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.

Fabi2 wrote:
slhh wrote:

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.

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.

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.

Fabi2 wrote:
slhh wrote:

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.

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.

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.

Fabi2 wrote:

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.

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.

Offline

#360 2012-11-12 08:26:50

Jimmy_K
Member
Registered: 2011-01-05
Posts: 562

Re: Routing / Spurmapping

Fabi2 wrote:
fkv wrote:
Fabi2 wrote:

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)

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.

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

fkv wrote:

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.

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.

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.

Offline

#361 2012-11-12 09:54:45

hurdygurdyman
Member
Registered: 2009-12-10
Posts: 2,850

Re: Routing / Spurmapping

Fabi2 wrote:

Vielleicht, weil ich die Realität mappen will!
...
Naja, inzwischen habe ich ja noch das eben frisch hochgeladene https://wiki.openstreetmap.org/wiki/Fil … modell.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.
...
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... wink tongue
...
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.

Ich habe mir mal dein https://wiki.openstreetmap.org/wiki/Fil … modell.pdf angeschaut, wobei ich noch nicht verstehe, wieso dies schon eine Referenz sein soll hmm
Unter anderem beziehst du dich auf http://wiki.openstreetmap.org/wiki/Prop … et_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 … rLevel.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.

Last edited by hurdygurdyman (2012-11-12 11:03:56)


Gruß Michael (hurdygurdyman)
Ich mappe für Menschen, die Karten verwenden, welche aus OSM-Daten gerendert wurden tongue http://de.wikipedia.org/wiki/KISS-Prinzip cool

Offline

#362 2012-11-12 13:02:42

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Routing / Spurmapping

hurdygurdyman wrote:

Ich habe mir mal dein https://wiki.openstreetmap.org/wiki/Fil … modell.pdf angeschaut, wobei ich noch nicht verstehe, wieso dies schon eine Referenz sein soll hmm
Unter anderem beziehst du dich auf http://wiki.openstreetmap.org/wiki/Prop … et_area/de .

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.

hurdygurdyman wrote:

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.

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?

hurdygurdyman wrote:

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.

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.

hurdygurdyman wrote:

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.

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

hurdygurdyman wrote:

Wie ein funktionierendes Erfassungstool gestaltet sein muss, sehe ich auch noch nicht.

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.

hurdygurdyman wrote:

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


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#363 2012-11-12 15:41:40

hurdygurdyman
Member
Registered: 2009-12-10
Posts: 2,850

Re: Routing / Spurmapping

Fabi2 wrote:

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

Alles schön und gut... theoretisch. Auf meine folgende Frage (und einige andere) gehst du leider nicht ein:

Was hältst du davon,, deinen Ansatz mal an einem praktischen Beispiel wie etwa diesem http://wiki.openstreetmap.org/wiki/File … rLevel.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.

Es ist dein Schema. Zeig uns was es kann.
Dann können wir hier nachvollziehen, ob es zu komplex ist oder nicht.

Last edited by hurdygurdyman (2012-11-12 15:44:48)


Gruß Michael (hurdygurdyman)
Ich mappe für Menschen, die Karten verwenden, welche aus OSM-Daten gerendert wurden tongue http://de.wikipedia.org/wiki/KISS-Prinzip cool

Offline

#364 2012-11-12 20:37:17

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Routing / Spurmapping

hurdygurdyman wrote:
Fabi2 wrote:

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

Alles schön und gut... theoretisch. Auf meine folgende Frage (und einige andere) gehst du leider nicht ein:

Was hältst du davon,, deinen Ansatz mal an einem praktischen Beispiel wie etwa diesem http://wiki.openstreetmap.org/wiki/File … rLevel.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.

In der Zeit, wo du diesen Post erstellt hast, hättest du die relevanten Teile bzw. alle der 8 Seiten auch schon gelesen haben können und dir das Posting dann klemmen bzw. konkreter zum Inhalt  nachfragen können.
Die Frage nach dem relevanten Fall, wo es nicht funktioniernt, und der auch nicht schon dokumentiert ist, hast du übrigens ja auch nicht beantwortet.

Und wenn du dir die Sachen nicht vorstellen kannst, dann sieht dir die Bilder in Version 2 (https://wiki.openstreetmap.org/wiki/File:Glm-doc.pdf) an, das Grundprinzip ist das Gleiche, es wird nur erweitert und ein paar Fehler werden korrigiert.


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#365 2012-11-13 00:57:12

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 432

Re: Routing / Spurmapping

Moin!

Fabi2 wrote:

Naja, inzwischen habe ich ja noch das eben frisch hochgeladene https://wiki.openstreetmap.org/wiki/Fil … modell.pdf als zuätzliche Referenz.

Ich habe mir den Text durchgelesen und habe folgende Kritikpunkte:

1. Ein rein flächenbasiertes Modell erscheint mir prinzipiell wenig geeignet um Straßen oder Fahrspuren abzubilden. Es ist ein großer Unterschied, ob ich mich längs der Straße oder quer dazu bewege. Einbahnstraßen geben überall eine Richtung vor, nicht nur an den Übergängen an den Enden.

2. Im letzten Beispiel in Abschnitt 5 wird nicht nur das Linksabbiegen von Weg 2 verboten, sondern auch die Geradeausfahrt von Weg 3. Der Fehler scheint mir im  flächenbasierten Modell nicht lösbar.

3. Das Modell ist viel zu kompliziert zu erstellen und zu pflegen.

4. Das Modell ist nicht kompatibel zum bestehenden Datenmodell. Eine Umstellung aller OSM-Tools auf ein neues Modell ist illusorisch.

5. Für effizientes Routing ist das Modell ungeeignet.

Viele Grüße
Stephan

Offline

#366 2012-11-13 08:17:48

hurdygurdyman
Member
Registered: 2009-12-10
Posts: 2,850

Re: Routing / Spurmapping

Fabi2 wrote:

In der Zeit, wo du diesen Post erstellt hast, hättest du die relevanten Teile bzw. alle der 8 Seiten auch schon gelesen haben können und dir das Posting dann klemmen bzw. konkreter zum Inhalt  nachfragen können.

Ich habe die 11 Seiten (die ich sehe, wenn ich deine pdf öffne) sogar mehrfach gelesen, was ich auch in einem meiner früheren Posts erwähnte.

Die Frage nach dem relevanten Fall, wo es nicht funktioniernt, und der auch nicht schon dokumentiert ist, hast du übrigens ja auch nicht beantwortet.

seawolf hat ja schon im letzten Post unter 2. einen Fehler gefunden. Ich habe an einer von mir erstellten typischen Musterkreuzung mal über deinen Ansatz nachgedacht, was leider mit der gebotenen Gründlichkeit erst spät nach meinem letzten Post möglich war. Dabei habe ich sechs realistische Abbiegebeschränkungen gefunden, die nach meiner Einschätzung nicht darstellbar sind, wenn alle möglichen Fahrwege auf dieser Kreuzung richtig abgebildet sind:
http://ubuntuone.com/6c6nUvff1Gs1ndBKMsL0mG
Sollte mir dabei ein logischer Fehler unterlaufen sein, weil ich deinen Ansatz nicht vollständig richtig verstanden habe, lasse ich mich gerne korrigieren. Wie du sicher weißt, hängt die Chance, etwas zu verstehen, aber auch von der Art und Qualität der gesendeten Information ab.


Gruß Michael (hurdygurdyman)
Ich mappe für Menschen, die Karten verwenden, welche aus OSM-Daten gerendert wurden tongue http://de.wikipedia.org/wiki/KISS-Prinzip cool

Offline

#367 2012-11-13 10:02:54

errt
Member
Registered: 2009-12-01
Posts: 1,068

Re: Routing / Spurmapping

seawolff wrote:

1. Ein rein flächenbasiertes Modell erscheint mir prinzipiell wenig geeignet um Straßen oder Fahrspuren abzubilden. Es ist ein großer Unterschied, ob ich mich längs der Straße oder quer dazu bewege. Einbahnstraßen geben überall eine Richtung vor, nicht nur an den Übergängen an den Enden.

Das ist das einzige große Problem, das ich hier sehe. Hierfür müssen wir wohl eine Lösung finden.

seawolff wrote:

2. Im letzten Beispiel in Abschnitt 5 wird nicht nur das Linksabbiegen von Weg 2 verboten, sondern auch die Geradeausfahrt von Weg 3. Der Fehler scheint mir im  flächenbasierten Modell nicht lösbar.

Was spricht denn gegen die altbekannten Turn-restrictions, hier halt mit Flächen statt Wegen als Membern?

seawolff wrote:

3. Das Modell ist viel zu kompliziert zu erstellen und zu pflegen.

Kann man drüber diskutieren. So ist diese Aussage erstmal subjektiv. Alles andere, was hier an Tagging-Modellen vorgeschlagen wurde, finde ich kein bisschen einfacher zu erstellen und zu pflegen.

seawolff wrote:

4. Das Modell ist nicht kompatibel zum bestehenden Datenmodell. Eine Umstellung aller OSM-Tools auf ein neues Modell ist illusorisch.

Es ist abwärtskompatibel, da es die linienbasierte Darstellung trotzdem erlaubt. Ansonsten müssen die Tools immer mit Änderungen klarkommen, von denen manche durchaus größer sein können. Man denke nur an die Auswirkungen, wenn denn endlich mal ein Flächentyp eingeführt wird, oder auch nur, was schon Multipolys für eine Umstellung waren. Trotzdem wird das kaum abgelehnt. Wir müssen uns eben auf neue Anforderungen einstellen.

seawolff wrote:

5. Für effizientes Routing ist das Modell ungeeignet.

Ebenfalls eher subjektiv. Routing erfordert auch auf unseren bisherigen Daten ein Preprocessing. Dieses wird zugegebenermaßen etwas komplexer, danach gibt es allerdings keine Unterschiede.

Offline

#368 2012-11-13 18:58:18

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 432

Re: Routing / Spurmapping

errt wrote:
seawolff wrote:

1. Ein rein flächenbasiertes Modell erscheint mir prinzipiell wenig geeignet um Straßen oder Fahrspuren abzubilden. Es ist ein großer Unterschied, ob ich mich längs der Straße oder quer dazu bewege. Einbahnstraßen geben überall eine Richtung vor, nicht nur an den Übergängen an den Enden.

Das ist das einzige große Problem, das ich hier sehe. Hierfür müssen wir wohl eine Lösung finden.

Vergiss dabei nicht Tag wie "maxspeed=forward" oder Buslinien mir "role=forward". :-)

2. Im letzten Beispiel in Abschnitt 5 wird nicht nur das Linksabbiegen von Weg 2 verboten, sondern auch die Geradeausfahrt von Weg 3. Der Fehler scheint mir im  flächenbasierten Modell nicht lösbar.

Was spricht denn gegen die altbekannten Turn-restrictions, hier halt mit Flächen statt Wegen als Membern?

Das Konzept behauptet, keine  Turn-restrictions zu benötigen. Wenn eine Kreuzung auf mehreren Kacheln besteht, wird die Relation viel komplizierter als im Linienmodell.

3. Das Modell ist viel zu kompliziert zu erstellen und zu pflegen.

Kann man drüber diskutieren. So ist diese Aussage erstmal subjektiv. Alles andere, was hier an Tagging-Modellen vorgeschlagen wurde, finde ich kein bisschen einfacher zu erstellen und zu pflegen.

Das glaube ich nicht. Bitte versuche einmal, das Konzept an einer Kreuzung mehrspuriger Straßen mit Radwegen umzusetzen. Für andere Modelle existieren Beispieldaten. Dann können wir vergleichen.

4. Das Modell ist nicht kompatibel zum bestehenden Datenmodell. Eine Umstellung aller OSM-Tools auf ein neues Modell ist illusorisch.

Es ist abwärtskompatibel, da es die linienbasierte Darstellung trotzdem erlaubt.

Das heißt, man muss alle Informationen doppelt im Linien- und Flächenmodell pflegen.

5. Für effizientes Routing ist das Modell ungeeignet.

Ebenfalls eher subjektiv. Routing erfordert auch auf unseren bisherigen Daten ein Preprocessing. Dieses wird zugegebenermaßen etwas komplexer, danach gibt es allerdings keine Unterschiede.

Wenn man die linienbasierte Darstellung ohnehin beibehält, kann man diese auch für das Routing verwenden und braucht die komplizierten Übergangsrelationen nicht.

Gruß
Stephan

Offline

#369 2012-11-13 19:24:08

errt
Member
Registered: 2009-12-01
Posts: 1,068

Re: Routing / Spurmapping

seawolff wrote:
errt wrote:
seawolff wrote:

1. Ein rein flächenbasiertes Modell erscheint mir prinzipiell wenig geeignet um Straßen oder Fahrspuren abzubilden. Es ist ein großer Unterschied, ob ich mich längs der Straße oder quer dazu bewege. Einbahnstraßen geben überall eine Richtung vor, nicht nur an den Übergängen an den Enden.

Das ist das einzige große Problem, das ich hier sehe. Hierfür müssen wir wohl eine Lösung finden.

Vergiss dabei nicht Tag wie "maxspeed=forward" oder Buslinien mir "role=forward". :-)

Ja, ich bezog das durchaus auf alle Daten, die richtungsabhängig sind. Eventuell braucht es einen Flächendatentyp mit Richtungsvektor, wobei ich mir nicht sicher bin, ob das wirklich ausreicht.

seawolff wrote:

2. Im letzten Beispiel in Abschnitt 5 wird nicht nur das Linksabbiegen von Weg 2 verboten, sondern auch die Geradeausfahrt von Weg 3. Der Fehler scheint mir im  flächenbasierten Modell nicht lösbar.

Was spricht denn gegen die altbekannten Turn-restrictions, hier halt mit Flächen statt Wegen als Membern?

Das Konzept behauptet, keine  Turn-restrictions zu benötigen. Wenn eine Kreuzung auf mehreren Kacheln besteht, wird die Relation viel komplizierter als im Linienmodell.

Ich habe es nicht im Detail durchgelesen, aber ich bezweifle, dass auf Turn Restrictions verzichtet werden kann. Möglicherweise braucht man sie allerdings seltener, was ja auch ein Fortschritt wäre. Warum die Restrictions komplizierter sein sollen, sehe ich allerdings nicht. Statt zwei Linien + Punkt oder mehrere Linien sind es dann halt mehrere Flächen. Kein großer Unterschied.

seawolff wrote:

3. Das Modell ist viel zu kompliziert zu erstellen und zu pflegen.

Kann man drüber diskutieren. So ist diese Aussage erstmal subjektiv. Alles andere, was hier an Tagging-Modellen vorgeschlagen wurde, finde ich kein bisschen einfacher zu erstellen und zu pflegen.

Das glaube ich nicht. Bitte versuche einmal, das Konzept an einer Kreuzung mehrspuriger Straßen mit Radwegen umzusetzen. Für andere Modelle existieren Beispieldaten. Dann können wir vergleichen.

Bedaure, mir fehlt für sowas aktuell die Zeit. Ich hoffe, dass Fabi ein Beispiel zeigen wird. Ich bleibe aber vorerst dabei, dass ich die anderen Varianten nicht für besser wartbar halte. Gerade alles, was viele Tags auf eine Linie quetscht hat ein großes Potential zu inkonsistenten Daten, weil die Auswirkungen der Tags vor allem für Mapper, denen das Schema nicht vertraut ist, nicht erkennbar sind. Modelle mit mehr Geometrie dürften offensichtlicher sein und leichter als kaputt erkennbar, wenn einer dran gepfuscht hat.

seawolff wrote:

4. Das Modell ist nicht kompatibel zum bestehenden Datenmodell. Eine Umstellung aller OSM-Tools auf ein neues Modell ist illusorisch.

Es ist abwärtskompatibel, da es die linienbasierte Darstellung trotzdem erlaubt.

Das heißt, man muss alle Informationen doppelt im Linien- und Flächenmodell pflegen.

Davon habe ich nicht gesprochen. Es ging darum, dass alle als Linien eingetragenen Straßen weiterhin voll gültig sind, nicht, dass sie parallel erfasst werden sollten. Entsprechend ist die Umstellung langsam und alle wichtigen Tools werden auf die Dauer mitziehen. Alle anderen werden mit der Zeit sowieso durch ganz andere Änderungen, beispielsweise an der API obsolet werden. Abgesehen davon schadet uns die doppelte Erfassung beispielsweise bei Flüssen auch nicht (auch wenn sie da zugegebenermaßen wesentlich simpler ist).

seawolff wrote:

5. Für effizientes Routing ist das Modell ungeeignet.

Ebenfalls eher subjektiv. Routing erfordert auch auf unseren bisherigen Daten ein Preprocessing. Dieses wird zugegebenermaßen etwas komplexer, danach gibt es allerdings keine Unterschiede.

Wenn man die linienbasierte Darstellung ohnehin beibehält, kann man diese auch für das Routing verwenden und braucht die komplizierten Übergangsrelationen nicht.

Wie gesagt, ich spreche nicht von Linien und Flächen für die selbe Straße, sondern von der grundsätzlichen parallelexistenz. Außerdem diskutieren wir hier dafür aktuell mindestens genauso komplizierte Relations- und Tagmodelle um geometrische Eigenschaften irgendwie in dafür ungeeigneten, stark generalisierten Linien unterzubringen. Da sollte man Alternativen zumindest bedenken. Zumal, wenn sie zwar vielleicht was einzelne Punkte um die es hier geht betrifft nicht viel besser sind, dafür aber in anderen (stichwort Rendering) wesentlich bessere Möglichkeiten für die Zukunft erlauben.

Offline

#370 2012-11-14 05:35:47

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Routing / Spurmapping

seawolff wrote:
Fabi2 wrote:

Naja, inzwischen habe ich ja noch das eben frisch hochgeladene https://wiki.openstreetmap.org/wiki/Fil … modell.pdf als zuätzliche Referenz.

Ich habe mir den Text durchgelesen und habe folgende Kritikpunkte:

1. Ein rein flächenbasiertes Modell erscheint mir prinzipiell wenig geeignet um Straßen oder Fahrspuren abzubilden. Es ist ein großer Unterschied, ob ich mich längs der Straße oder quer dazu bewege. Einbahnstraßen geben überall eine Richtung vor, nicht nur an den Übergängen an den Enden.

Rate mal, warum es da noch die Relation für die Fahrspur gibt?! Die ist genau dafür dam um durch die angrenzenden Flächen bzw. Linien den Verlauf der Spurhauptrichtung herausbekommen zu können. Da die quer angrenzenden Flächen nicht mit in der Spurrelation sind, gehören die eben auch nicht mit zur Fahrspur.

seawolff wrote:

2. Im letzten Beispiel in Abschnitt 5 wird nicht nur das Linksabbiegen von Weg 2 verboten, sondern auch die Geradeausfahrt von Weg 3. Der Fehler scheint mir im  flächenbasierten Modell nicht lösbar.

Das istr alles lösbar, aber ich bin nicht gerade der Freund des motorisierten Induvidualverkehrs (dafür gibt es viele objektive Gründe, die wollen aber viele nicht unbedingt wahrhaben...) und kennen da alle Regelungen genau, so das das Leute die sich auskennen mal korrigieren sollten.

seawolff wrote:

3. Das Modell ist viel zu kompliziert zu erstellen und zu pflegen.

Wie ich schon öfter und auch in dem Vorsclag geschrieben habe: man hat die Wahl zwischen vom Menschen mappbar und dafür beschränkt in der darstellung oder allgemeineren maschinentauglichen Modellen. Da mußt du mal sagen, was du gerne hättest!?

seawolff wrote:

4. Das Modell ist nicht kompatibel zum bestehenden Datenmodell. Eine Umstellung aller OSM-Tools auf ein neues Modell ist illusorisch.

Wieso? Da die Tags der konkreten Wege das Modell nicht interessieren, kann da gerne an einer Spur noch ein altes highway=* usw. getaggt sein. Ansonsten gilt da wieder das was bei Punkt 3 steht.

seawolff wrote:

5. Für effizientes Routing ist das Modell ungeeignet.

Was eine unbegründete Behauptung ist.


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#371 2012-11-14 07:01:05

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Routing / Spurmapping

hurdygurdyman wrote:

Die Frage nach dem relevanten Fall, wo es nicht funktioniernt, und der auch nicht schon dokumentiert ist, hast du übrigens ja auch nicht beantwortet.

seawolf hat ja schon im letzten Post unter 2. einen Fehler gefunden. Ich habe an einer von mir erstellten typischen Musterkreuzung mal über deinen Ansatz nachgedacht, was leider mit der gebotenen Gründlichkeit erst spät nach meinem letzten Post möglich war. Dabei habe ich sechs realistische Abbiegebeschränkungen gefunden, die nach meiner Einschätzung nicht darstellbar sind, wenn alle möglichen Fahrwege auf dieser Kreuzung richtig abgebildet sind:
http://ubuntuone.com/6c6nUvff1Gs1ndBKMsL0mG
Sollte mir dabei ein logischer Fehler unterlaufen sein, weil ich deinen Ansatz nicht vollständig richtig verstanden habe, lasse ich mich gerne korrigieren. Wie du sicher weißt, hängt die Chance, etwas zu verstehen, aber auch von der Art und Qualität der gesendeten Information ab.

Das geht, bei deiner Kreuzung müssen maximal 6x7 (5x4 Spuren + 2x2 Radwege) Felder erstellt werden. Dann kann man erst mal allen auf die Kreuzung einmündenden Übergängen eine Übergangsgruppe zuweisen und dann muß für die schwierigen Fälle, die sich nicht achon über die Standardfälle mit auflösen lassen, ggf. eine Mehrfachzuweisung von Übergangsgruppen erfolgen.  Der schlimmste Fall ist, daß man für jede Abbiegebeeschränkung die Übergangsgruppe der Spur explizit über den gangen Spurverlauf an jedem Übergang mitführen muß. Die Idee mit der Übergangsgruppe ist auch darauf ausgelegt, das sich die meisten üblichen Standardkreuzungen und -fälle damit effizient darstellen lassen, bei komplexen Kreuzungen kann dafür dann die Zahl der nötigen Relationen zunehmen. Es fehlt auch noch eine formale Beschreibung für eine möglichst effiziente Zuweisung der Gruppen (die hab ich erst ansatzweise), aber es lassen sich definitiv alle Abbiegebeschränkungen auflösen.

Die andere ungenaue "gut genug"-Alternative der Navibauer scheint, soweit ich das herausgefunden habe, zu sein, die Kreuzung zur "allgemeinen Verkehrsfläche" zu machen, wo man per Definition dann in alle Richtungen fahren kann und auf die einmündenen Spuren dann formale Zuordnungen der möglichen Spurübergänge per Relation bastelt. Frei nach der Devise: wir müssen ja auch nur routen, was schert uns denn, wie die Kreuzung in der Realität tatsächlich genau ausieht und wie dort die Spuren konkret verlaufen, bestenfalls redenrn wir noch die Sperrflächen und Fußgängerüberwege als funktionslose Bilddarstellung mit rein...


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#372 2012-11-14 07:57:55

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Routing / Spurmapping

seawolff wrote:
errt wrote:
seawolff wrote:

1. Ein rein flächenbasiertes Modell erscheint mir prinzipiell wenig geeignet um Straßen oder Fahrspuren abzubilden. Es ist ein großer Unterschied, ob ich mich längs der Straße oder quer dazu bewege. Einbahnstraßen geben überall eine Richtung vor, nicht nur an den Übergängen an den Enden.

Das ist das einzige große Problem, das ich hier sehe. Hierfür müssen wir wohl eine Lösung finden.

Vergiss dabei nicht Tag wie "maxspeed=forward" oder Buslinien mir "role=forward". :-)

Die sind kein Problem, weil die grundsätzliche befahrbarkeit hat ja nun noch nichts mit der richtungsbezogenen Gültigkeit der aufgestellten Verkehrsschilder oder dort verlaufenden Buslinien zu tun. Die Befahrbarkeit ist eine Tatsache, warum die dann so ist, also die Ursache, wie z.B. eine Line oder ein Schild, ist, muß man dann noch extra erfassen.

seawolff wrote:

2. Im letzten Beispiel in Abschnitt 5 wird nicht nur das Linksabbiegen von Weg 2 verboten, sondern auch die Geradeausfahrt von Weg 3. Der Fehler scheint mir im  flächenbasierten Modell nicht lösbar.

Was spricht denn gegen die altbekannten Turn-restrictions, hier halt mit Flächen statt Wegen als Membern?

Das Konzept behauptet, keine  Turn-restrictions zu benötigen. Wenn eine Kreuzung auf mehreren Kacheln besteht, wird die Relation viel komplizierter als im Linienmodell.

Die bekommt man ja qasi, wenn man die jeweilige Übergangsgruppe an alle relevanten Übergänge taggen muß.

seawolff wrote:

4. Das Modell ist nicht kompatibel zum bestehenden Datenmodell. Eine Umstellung aller OSM-Tools auf ein neues Modell ist illusorisch.

Es ist abwärtskompatibel, da es die linienbasierte Darstellung trotzdem erlaubt.

Das heißt, man muss alle Informationen doppelt im Linien- und Flächenmodell pflegen.

Die Liniendarstellung ist eine Ersatzdarstellung für die Flächendarstellung, so das man da nur eine Variante also Linien oder Flächen braucht.

seawolff wrote:

5. Für effizientes Routing ist das Modell ungeeignet.

Ebenfalls eher subjektiv. Routing erfordert auch auf unseren bisherigen Daten ein Preprocessing. Dieses wird zugegebenermaßen etwas komplexer, danach gibt es allerdings keine Unterschiede.

Wenn man die linienbasierte Darstellung ohnehin beibehält, kann man diese auch für das Routing verwenden und braucht die komplizierten Übergangsrelationen nicht.

Die Liniendarstellung wird eben nicht beibehalten, denn die ist in der Darstellung der Übergänge von der Straße und bei der Darstellung der realen Geometrie der beteiligten Flächen nämlich prinzipbedingt eingeschränkt.


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#373 2012-11-14 08:43:23

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Routing / Spurmapping

errt wrote:
seawolff wrote:

Was spricht denn gegen die altbekannten Turn-restrictions, hier halt mit Flächen statt Wegen als Membern?

Das Konzept behauptet, keine  Turn-restrictions zu benötigen. Wenn eine Kreuzung auf mehreren Kacheln besteht, wird die Relation viel komplizierter als im Linienmodell.

Ich habe es nicht im Detail durchgelesen, aber ich bezweifle, dass auf Turn Restrictions verzichtet werden kann. Möglicherweise braucht man sie allerdings seltener, was ja auch ein Fortschritt wäre. Warum die Restrictions komplizierter sein sollen, sehe ich allerdings nicht. Statt zwei Linien + Punkt oder mehrere Linien sind es dann halt mehrere Flächen. Kein großer Unterschied.

Das die Restrictionen abgeschfft werden, steht ja auch nirgendwo, sondern die sind prinzipbedingt gleich mit eingebaut. Was deren Ursache ist, muß man dann wie gesagt noch getrennt darstellen.

errt wrote:
seawolff wrote:

Kann man drüber diskutieren. So ist diese Aussage erstmal subjektiv. Alles andere, was hier an Tagging-Modellen vorgeschlagen wurde, finde ich kein bisschen einfacher zu erstellen und zu pflegen.

Das glaube ich nicht. Bitte versuche einmal, das Konzept an einer Kreuzung mehrspuriger Straßen mit Radwegen umzusetzen. Für andere Modelle existieren Beispieldaten. Dann können wir vergleichen.

Bedaure, mir fehlt für sowas aktuell die Zeit. Ich hoffe, dass Fabi ein Beispiel zeigen wird.

Naja, es gibt da die vier Fälle (1. Übergangsgruppe wird neu gesetzt (=keine Auswirkung, aber idt der Anfang eines z.B, "forward"s); 2. Übergansgruppe ist gleich der des letzten Überganges (=z.B. "forward" aus der Richtung des letzten Überganges); 3. Übergangsgruppe ist ungleich der des letzten Überganges (=Verbot für alle, außer für die definierte Gruppe) und 4. Übergangsgruppe ist irrrelevant, da nicht vorhanden (=erlaubt von allen anderen Übergängen der Fläche)) für die übergänge und damit bekommt man die nötigen Varianten: allgemeines Verbot, allgemeine Erlaubnis und richtungsbezogene Erlaubnis/Verbot dargestellt. Das kompliziertere Beispiel brauche ich zumindest nicht. Wer meint eines zu brauchen, soll sich eben eins malen.

errt wrote:

Ich bleibe aber vorerst dabei, dass ich die anderen Varianten nicht für besser wartbar halte. Gerade alles, was viele Tags auf eine Linie quetscht hat ein großes Potential zu inkonsistenten Daten, weil die Auswirkungen der Tags vor allem für Mapper, denen das Schema nicht vertraut ist, nicht erkennbar sind. Modelle mit mehr Geometrie dürften offensichtlicher sein und leichter als kaputt erkennbar, wenn einer dran gepfuscht hat.

Das sehe ich genauso. Mal abgesehen davon, das die Vertreter der Linienmodelle mir mal erklären sollen, wie sie die Geometrie und die Übergänge zwischen den verschiedenen Flächen detailiert darstellen wollen, wenn alles Linien sind. tongue


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#374 2012-11-21 07:37:58

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Routing / Spurmapping

War erst als Ende mit in http://forum.openstreetmap.org/viewtopi … 61#p291561 aber paßt hier besser her:

Naja, wenn man dann mal etwas dem neuen ISO TC 204 bzw. GDF 5.0 (ISO DIS 14825) hinterher googelt, findet man dann noch ganz interesante Sachen wie
http://www.etsi.org/website/document/te … 04_wg3.pdf (Naja, die "detailierten" Kreuzungen sind schon ein Fortschritt gegenüber den reinen Quadraten...)
http://i.csis.u-tokyo.ac.jp/event/20100 … kaiDoc.pdf (is JP nicht erschrecken, sondern die netten Bildchen zum Modell und den englischen Text ansehen..., So landet NDS bei der ISO.)
http://docbox.etsi.org/workshop/2012/20 … schade.pdf (zum Weitergoogeln und für die Gesamtübersicht der ganzen Standards, weil die ETSI ist natürlich auch mit dabei...)
http://docbox.etsi.org/workshop/2012/20 … SWORKSHOP/ (mehr Infos zu ITS)

Auf http://www.cvisproject.org/ gibts dann (z.B. http://www.cvisproject.org/download/ERT … 06_WEB.pdf ) anschaulichere Infos, wie das Ganze dann mal zusammengebaut funktionieren soll.
Dabei kümmert sich die dort gelikten Subprojekte dann immer um Details, wie z.B. http://www.safespot-eu.org/ um die Api für die Sensordaten. Soll heißen, das Proposal zum dynamic_maxspeed kann man sich eigentlich sparen, weil neben der Erkennung von Falschfahrern wird es dann bestimmt bald automatische Strafzettel für nicht gesetzte Blinker, unangeschnalltes Fahren und jede einzelne Geschwindigkeitsüberschreitung (wer dachte die Mautbrücken sind da schlimm, hat falsch gedacht...) geben. Naja und immerhin gibt man sich Mühe bei der Sicherheit, aber früher oder später holt dann jemand doch den Masterkey aus dem HSM und das Ganze verkommt spätestens dann zum weiteren Spielplatz für Nerds. smile


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#375 2012-11-21 08:53:54

marek kleciak
Member
Registered: 2010-10-11
Posts: 8,421

Re: Routing / Spurmapping

Hallo Fabi2, danke für die interessanten Links. Ich kann nur ander User ermuntern dies zu lesen..

Offline

Board footer

Powered by FluxBB