Anfängerfrage: Strasse im Gezeitenwechsel

tippeltappel · 2010-06-10T00:15:49.000Z

EvanE:

errt:

Bloß doof, dass man sich damit dass access-Tag blockiert, dass man vielleicht noch für seinen eigentlichen Zweck braucht. tidal=yes scheint mir bis jetzt noch am sinnvollsten von den genannten Möglichkeiten. Klare Aussage und ohne Zweckentfremdung anderer Tags.

Es gibt natural=wetland als Approved Feature
Dort gibt es wetland=tidalflat und auch tidal=yes.

Man sollte in so einer Situation möglichst auch die Fläche mappen.
So wird klar, dass der Weg in einem Gezeitengebiet liegt.

Edbert (EvanE)

(1)
Das access-Tag würde ich aus genanntem Grund auch nicht verwenden.

(2)
Daraus, daß der Weg durchs Meer führt, kann man aber nicht schließen, daß er zeitweise überflutet ist. Es gibt ja auch “hochgebockte” Wege.

Da das Wasser Ursache für eine eingeschränkte Nutzung ist, könnte man auch ein Tag wie curtailing/reduction/restaint/**obstruction=tidal_water ** kreieren. Das ist eindeutig und gut in ein Overlay umsetzbar.

obstruction würde mir am besten gefallen.

Wenn weitere Erscheinungsformen temporärer Einschränkungen definiert werden müssen, lassen die sich mit diesem Tag ebenfalls fassen. Wenn z.B. eine Straße regelmäßig durch Viehtrieb blockiert wird: obstruction=cattle_drive. Werks- oder Baustellenverkehr obstruction=van_traffic

Was ist noch denkbar/sinnvoll?

Das Tag obstruction=* könnte von einem Routingprogramm dahingehend ausgewertet werden, daß es eine alternative Streckenführung ohne Behinderung bevorzugt.

Gruß
tippeltappel

de_muur · 2010-06-10T05:28:44.000Z

errt:

Bloß doof, dass man sich damit dass access-Tag blockiert, dass man vielleicht noch für seinen eigentlichen Zweck braucht.

Wieso das? Man benutzt das =tidal einfach an Stelle von =yes bei den verschiedenen access Werten. Das sollte doch dann meist ohne Probleme passen.

z.B.

access=tidal
bicycle=no

oder

access=no
foot=tidal

Das haette dann gleichzeitig den Vorzug, dass das beim Routing automatisch als nichtverstandenes access-Tag ausgewertet wird. D.h. auch eine Anwendung, die nicht im Detail versteht, was da eigentlich los ist, sieht immerhin, dass die Strasse nicht beliebig nutzbar ist.

Was einem so erstmal verloren geht sind Kombinationen wie access=private und access=tidal gleichzeitig.

a) Gibt es sowas ueberhaupt? Wahrscheinlich schon, die OSM Erfahrung zeigt: Es gibt eigentlich nichts, was es nicht gibt.

b) Geht da signifikannte Information verloren, wenn man sich auf das staerker einschraenkende Tag beschraenkt? im obigen Beispiel koennte man z.B. einfach nur access=privat setzen. Wer zur Nutzung soeiner Strecke ueberhaupt berechtigt ist, wird schon selebr wissen, dass er da mit Gezeitenproblemen zu rechnen hat.

c) Auch beim access-Tag kann man ja ruhig Aufzaehlungen machen: “access=private;tidal”. Das versteht dann zwar erstmal keine automatische Auswertung mehr richtig, aber immerhin erkennt sie noch, dass da eine ihr unbekannte Zugangsbeschraenkung vorliegt. da solche Faelle extrem selten sein duerften, duerften auch in Zukunft nur die wenigsten Anwendungen explizite Routing-Regeln dafuer vorsehen.

Gruss
Torsten

tippeltappel · 2010-06-10T08:22:10.000Z

de_muur:

errt:

Bloß doof, dass man sich damit dass access-Tag blockiert, dass man vielleicht noch für seinen eigentlichen Zweck braucht.

Wieso das? Man benutzt das =tidal einfach an Stelle von =yes bei den verschiedenen access Werten. Das sollte doch dann meist ohne Probleme passen.

z.B.

access=tidal
bicycle=no

oder

access=no
foot=tidal

Das haette dann gleichzeitig den Vorzug, dass das beim Routing automatisch als nichtverstandenes access-Tag ausgewertet wird. D.h. auch eine Anwendung, die nicht im Detail versteht, was da eigentlich los ist, sieht immerhin, dass die Strasse nicht beliebig nutzbar ist.

Was einem so erstmal verloren geht sind Kombinationen wie access=private und access=tidal gleichzeitig.

a) Gibt es sowas ueberhaupt? Wahrscheinlich schon, die OSM Erfahrung zeigt: Es gibt eigentlich nichts, was es nicht gibt.

b) Geht da signifikannte Information verloren, wenn man sich auf das staerker einschraenkende Tag beschraenkt? im obigen Beispiel koennte man z.B. einfach nur access=privat setzen. Wer zur Nutzung soeiner Strecke ueberhaupt berechtigt ist, wird schon selebr wissen, dass er da mit Gezeitenproblemen zu rechnen hat.

c) Auch beim access-Tag kann man ja ruhig Aufzaehlungen machen: “access=private;tidal”. Das versteht dann zwar erstmal keine automatische Auswertung mehr richtig, aber immerhin erkennt sie noch, dass da eine ihr unbekannte Zugangsbeschraenkung vorliegt. da solche Faelle extrem selten sein duerften, duerften auch in Zukunft nur die wenigsten Anwendungen explizite Routing-Regeln dafuer vorsehen.

Gruss
Torsten

Die Argumentation finde ich nicht schlüssig. Die Problematik deutest Du bereits selber an.

Das access-Tag steht (so verstehe ich das Wiki) für verschiedene Formen von erlaubt und nicht erlaubt. (vereinfacht ausgedrückt) Darum geht es aber nicht. Es geht um die Erfassung einer mehr oder weniger häufig auftretenden Nutzungseinschränkung.

Für die Einführung von obstruction=* für Nutzungseinschränkungen spricht, daß es

ein Tag dieser Art noch nicht zu geben scheint.
ein ausbaufähiges System ist.

So könnte man z.B. differenzieren und statt tidal_water auch spring_tide benutzen, um darauf hinzuweisen, daß der Weg nur bei extrem hohen Wasserständen überflutet ist. In Hochwassergebieten könnte der key mit values kombiniert werden, die anzeigen, ab welcher Hochwassermarke ein Weg oder eine Fläche überflutet ist.

Da bieten sich eine Menge sinnvoller Auswertungsmöglichkeiten.

Vorhandene Renderregeln verbiegen, damit sich ein träger Kartenrenderer die Einarbeitung einer neuen key/value-Kombination ersparen kann, ist nicht akzeptabel.

Gruß
tippeltappel

EvanE · 2010-06-10T11:36:19.000Z

Hallo tippeltappel

tippeltappel:

EvanE:

…
Man sollte in so einer Situation möglichst auch die Fläche mappen.
So wird klar, dass der Weg in einem Gezeitengebiet liegt.

…
Daraus, daß der Weg durchs Meer führt, kann man aber nicht schließen, daß er zeitweise überflutet ist. Es gibt ja auch “hochgebockte” Wege.

Eigentlich schon, da in OSM ein Weg per-se auf dem Ground-Level liegt.
Wenn dem nicht so ist, sollte das mit embankment=yes oder bridge=yes
gekennzeichnet sein. Ausserdem hindert einen ja niemand die regelmäßige
Überflutung mit tidal=yes, water=tidal oder deinem Vorschlag am Weg
zusätzlich zu kennzeichnen (was wegen der Eindeutigkeit wünschenswert ist).

tippeltappel:

Da das Wasser Ursache für eine eingeschränkte Nutzung ist, könnte man auch ein Tag wie curtailing/reduction/restaint/**obstruction=tidal_water ** kreieren. Das ist eindeutig und gut in ein Overlay umsetzbar.

obstruction würde mir am besten gefallen.

Wenn weitere Erscheinungsformen temporärer Einschränkungen definiert werden müssen, lassen die sich mit diesem Tag ebenfalls fassen. Wenn z.B. eine Straße regelmäßig durch Viehtrieb blockiert wird: obstruction=cattle_drive. Werks- oder Baustellenverkehr obstruction=van_traffic

Was ist noch denkbar/sinnvoll?

Das Tag obstruction=* könnte von einem Routingprogramm dahingehend ausgewertet werden, daß es eine alternative Streckenführung ohne Behinderung bevorzugt.

‘obstruction’ klingt für mich eher nach einem dauerhaften Hindernis.

Aber sei das mal hintangestellt. Allerdings bitte je nach Situation
obstruction=goods_traffic/hgv_traffic verwenden, um die in OSM
eingeführten Fahrzeugarten goods (Lieferwagen) resp. hgv (Heavy
Goods Vehicle = LKW) zu benutzen.

Es gibt allerdings bereits das (zugegeben wenig benutzte) hazard=*
aus irgendeinem Proposal, das diesen Zweck auch erfüllen könnte.

Andere Hindernisse wären z.B. obstruction=log (Baumstamm)

Edit: Für eine Baustelle ohne Vollsperrung wäre noch
obstruction=construction sinnvoll.
Das konnten wir bisher nicht abbilden.

Edbert (EvanE)

de_muur · 2010-06-10T11:56:02.000Z

tippeltappel:

Das access-Tag steht (so verstehe ich das Wiki) für verschiedene Formen von erlaubt und nicht erlaubt.

Ist das so? Werden die verschiedenen access-Tags nicht auch benutzt, um eine grundsaetzliche Nutzungsmoeglichkeit auszudruecken. Also nicht nur ob etwas erlaubt ist, sondern auch ob etwas moeglich ist?

z.B. werden doch barrier-Hindernisse gerne mit einem motorcar=no oder einem bicycle=yes versehen. Damit wird dann ja nicht unbedingt der legale Zustand sondern die faktische Einschraenkung erfasst.

Für die Einführung von obstruction=* für Nutzungseinschränkungen spricht, daß es

ein Tag dieser Art noch nicht zu geben scheint.

ein ausbaufähiges System ist.

Was mich an dem Vorschlag stoert ist, dass

es ein neues Tag ist, was mir nicht wirklich noetig erscheint,

und

hierbei gerade die entscheidende Information faehlt, naemlich in wie weit die Nutzung eingeschraenkt ist.

Wenn eine Strasse bei Flut ueberspuelt ist, dann ist sie komplett nicht benutzbar. Wenn man irgendwo mit Baustellenverkehr zu rechnen hat, dann muss man zwar sein Tempo anpassen, kann da aber immer noch lang.

Dein Vorschlag beschreibt zwar die Ursache fuer eine Stoerung, dafuer fehlt ihm jegliche Beschreibung der Wirkung.

Gruss
Torsten

Michelwald · 2010-06-10T13:00:22.000Z

ich danke Euch für diese konstruktive Diskussion, die ich interessiert verfolge.

Nochmal folgende Ergänzungsfrage:

Diese spezielle Straße in meinem Fall ist zweimal täglich/nächtlich für ein Zeitfenster von 4 bis 6 Stunden offen, sonst überflutet. Die “offenen Zeiten” findet man auf einer Internetseite eines Anliegers, sie darf verlinkt werden (s.u. natürlich kein leicht übernehmbares Format, aber da kann man ja noch dran arbeiten). Wie kann ich soetwas sinnvoll einbauen, damit vielleicht in ferner Zukunft eine Navisystem mit online-internetanschluß die offenen Zeiten zur Navigation kennt bzw. auf dem Bildschirm darstellt?

http://ilecallot.free.fr/index.html

Michelwald

tippeltappel · 2010-06-10T13:39:09.000Z

de_muur:

tippeltappel:

Das access-Tag steht (so verstehe ich das Wiki) für verschiedene Formen von erlaubt und nicht erlaubt.

Ist das so? Werden die verschiedenen access-Tags nicht auch benutzt, um eine grundsaetzliche Nutzungsmoeglichkeit auszudruecken. Also nicht nur ob etwas erlaubt ist, sondern auch ob etwas moeglich ist?

Genau diese Art der Nutzung macht das access-Tag mehrdeutig und unbrauchbar. Es ist eben ein Unterschied ob ein Weg de facto verboten oder aufgrund der Meinung eines einzelnen Mappers für irgendwen als nicht benutzbar eingestuft wird. Es nervt total, wenn z.B. Reitverbotschilder auf der Karte auftauchen, wo es gar kein Reitverbot gibt! Wie soll ein Renderer erkennen, wann auf einem mit horse=no getagten Weg reiten verboten ist und wann der Weg nach Meinung eines Nichtreiters zum Reiten “ungeeignet” ist? Aber egal. Mach es, wie Du meinst. Die Diskussion um die Verwendung des access-Tag braucht man nicht mehr führen. Das wurde schon ausreichend abgehandelt.

de_muur:

z.B. werden doch barrier-Hindernisse gerne mit einem motorcar=no oder einem bicycle=yes versehen. Damit wird dann ja nicht unbedingt der legale Zustand sondern die faktische Einschraenkung erfasst.

Wenn im Zusammenhang mit barrier=*** xyz=no getaggt wird, wird das access-Tag genau betrachtet gar nicht benutzt. Mag sein, daß viele es gedanklich damit in Verbindung bringen. Doch hier wird lediglich ausgedrückt, wer genau das Hindernis nicht passieren kann. Nicht mehr und nicht weniger.

Für Wege gelten jedoch gesetzlich geregelte Nutzungsrechte, die auf einer Karte zum Ausdruck gebracht werden können müssen. Dafür ist das access-Tag das einzige brauchbare Werkzeug.

de_muur:

Für die Einführung von obstruction=* für Nutzungseinschränkungen spricht, daß es

ein Tag dieser Art noch nicht zu geben scheint.

ein ausbaufähiges System ist.

Was mich an dem Vorschlag stoert ist, dass

es ein neues Tag ist, was mir nicht wirklich noetig erscheint,

Deine Meinung sei Dir unbenommen. Deine Argumente überzeugen mich aber nicht.

de_muur:

und

hierbei gerade die entscheidende Information faehlt, naemlich in wie weit die Nutzung eingeschraenkt ist.

Wenn eine Strasse bei Flut ueberspuelt ist, dann ist sie komplett nicht benutzbar. Wenn man irgendwo mit Baustellenverkehr zu rechnen hat, dann muss man zwar sein Tempo anpassen, kann da aber immer noch lang.

Dein Vorschlag beschreibt zwar die Ursache fuer eine Stoerung, dafuer fehlt ihm jegliche Beschreibung der Wirkung.

Gruss
Torsten

Das ist so meines Erachtens nicht zuende gedacht. Wenn Value eindeutig gewählt wird, können daraus für die Wirkung der Behinderung eindeutige Schlüsse gezogen werden.
Des weiteren ist es jedem freigestellt ein weiteres key anzuhängen:
obstruction:time= *
und damit wie bei der Erfassung von Öffnungszeiten anzugeben, in welcher Zeit mit Verkehrsbehinderungen zu rechnen ist.
Für den Fall, daß es keine erfaßbaren Zeiten gibt, jedoch der Zeitfaktor wie beim Tidenhub von Bedeutung ist, die nächste Idee:
Ins Obstraction-Schema würde auch noch obstraction:info=*** oder so etwas ähnliches passen. Value könnte eine Telefonnummer oder eine Webseite sein, wo man Informationen z.B. über den Tidenhub oder Hochwasserstände abrufen kann.

Die keys url=* und wikipedia=* gibt es ja schon. Dort könnte man dann zusätzlich allgemeine Informationen über die Straße, oder das Gelände um die/das es gerade geht finden, bzw. sie zuvor selbst hinterlegen.

@ Michelwald
Das könnte auch eine Antwort auf Deine Frage sein.

@ EvanE
Im Gegensatz zu Deiner persönlichen Interpretation des key-Wortes obstruction findet man hier
http://dict.leo.org/?lp=ende&from=fx3&search=obstruction
den Begriff in der Kombination
obstruction of traffic = Verkehrsbehinderung
Da keys und values gerne mit verkürzten Begriffen arbeiten, wird man aber wohl kaum als key “obstraction of traffic” benutzen. Außerdem würde das eine Einschränkung für die Verwendung darstellen.

Gerade weil der Begriff obstraction in vielen weiteren Kombinationen gebräuchlich ist, scheint er mir bestens als key-Wort geeignet. Mit Hilfe der values können dann in den unterschiedlichsten Zusammenhängen sowohl temporäre als auch für längere Zeit andauernde Nutzungseinschränkungen jedweder Art an Wegen und Flächen ausgedrückt werden. Denkbar wäre auch, an einer Straße oder einem Parkplatz jährlich wiederkehrende Ereignisse zu mappen, die eine Verkehrsbehinderung darstellen. Z.B. obstraction=Weihnachtsmarkt obstraction:time=Dezember usw.

Deine Vorschläge sollte man in die Value-Liste aufnehmen, so daß mit diesen Begriffen die Ursache z.B. für die Verkehrsbehinderung bzw. Nutzungseinschränkung differenziert erfaßt und nach Belieben von den Renderern ausgewertet werden kann.

Das System, wird es logisch durchdacht, läßt sich in verschiedene Richtungen erarbeiten.

hazard=xyz
Ist ein Node-Tag und wird benutzt, um besondere Gefahrenstellen zu beschreiben.
Auf der Wander-Reit-Karte wird der als Value eingegebene Text auf der Karte ausgegeben, damit der Anwender erkennen kann, was da los ist:
http://topo.openstreetmap.de/?lon=6.4977&lat=50.5769&zoom=17
http://topo.openstreetmap.de/?lon=6.5411&lat=50.5392&zoom=18

Als way-Tag ist das nur geeignet, wenn von einem Weg eine besondere Gefahr ausgeht. Im Fall der Überflutungsgefahr mag das zusätzlich passen. Ich würde es aber nicht so allgemein für jeden Weg nutzen, der von Zeit zu Zeit überschwemmt wird, sondern es besonderen für Ortsunkundige nicht offensichtliche Gefahren nutzen. Angebracht fände ich ein hazard-Tag z.B. an Stellen im Watt, wo man als Ortsunkundiger unbemerkt von der Flut eingeschlossen werden kann. Beispiel:
hazard=Rückweg zum Festland ist xxmin nach Flutbeginn abgeschnitten
Dann ist man gewarnt und weiß, daß man sich sputen muß, wenn in den Prilen das Wasser wieder Richtung Land fließt.

Gruß
tippeltappel

EvanE · 2010-06-10T14:48:03.000Z

Hallo tippeltappel

tippeltappel:

@ EvanE
Im Gegensatz zu Deiner persönlichen Interpretation des key-Wortes obstruction findet man hier
http://dict.leo.org/?lp=ende&from=fx3&search=obstruction den Begriff in der Kombination
obstruction of traffic = Verkehrsbehinderung …

OK, die Bedeutungswolke von ‘obstruction’ reicht offensichtlich aus,
alle von dir gewünschten Bedeutungen abzudecken.

tippeltappel:

Gerade weil der Begriff obstraction in vielen weiteren Kombinationen gebräuchlich ist, scheint er mir bestens als key-Wort geeignet. … Denkbar wäre auch, an einer Straße oder einem Parkplatz jährlich wiederkehrende Ereignisse zu mappen, die eine Verkehrsbehinderung darstellen. Z.B. obstraction=Weihnachtsmarkt obstraction:time=Dezember usw.
…
Das System, wird es logisch durchdacht, läßt sich in verschiedene Richtungen erarbeiten.

Die Tatsache, dass man mit obstruction* viele bisher schlecht abbildbare
Behinderungen (Baustellen ohne Komplett-Sperrung, Weihnachtsmarkt/Kirmes, …)
darstellen kann, lässt mich deinen Vorschlag sehr positiv einschätzen.

tippeltappel:

hazard=xyz
Ist ein Node-Tag und wird benutzt, um besondere Gefahrenstellen zu beschreiben.
Auf der Wander-Reit-Karte wird der als Value eingegebene Text auf der Karte ausgegeben, damit der Anwender erkennen kann, was da los ist:
http://topo.openstreetmap.de/?lon=6.4977&lat=50.5769&zoom=17
http://topo.openstreetmap.de/?lon=6.5411&lat=50.5392&zoom=18

…

Dann wären von den bisherigen Beispielen nur Werks-/Baustellenausfahrten für
hazard passend. Allerdings kann es auch den Weg bis zur nächsten größeren
Kreuzung betreffen. Von daher passt obstruction=hgv_traffic genauso gut/besser.

Edbert (EvanE)

de_muur · 2010-06-10T15:56:38.000Z

tippeltappel:

Es ist eben ein Unterschied ob ein Weg de facto verboten oder aufgrund der Meinung eines einzelnen Mappers für irgendwen als nicht benutzbar eingestuft wird.

Das wiederum ist deine Meinung, die ich nicht teile. Es ist mir egal, ob ich irgendwo nicht lang darf oder ob ich irgendwo nicht lang kann. Das Resultat ist ja letztendlich das selbe.

Das ist so meines Erachtens nicht zuende gedacht. Wenn Value eindeutig gewählt wird, können daraus für die Wirkung der Behinderung eindeutige Schlüsse gezogen werden.

Damit verlaesst man sich aber wieder auf reine Interpretation, d.h. jede Auswertung wird aus einer bestimmten Behinderung andere Konsequenzen ziehen. Da ist es doch viel klarer, wenn man direkt erfasst, wer in welcher Weise behindert wird. Von mir aus kann man auch gerne ZUSAETZLICH den Grund der Behinderung erfassen. Dabei darf man halt nur nicht das Wichtigste aus den Augen verlieren.

Gruss
Torsten

tippeltappel · 2010-06-10T17:01:56.000Z

de_muur:

tippeltappel:

Es ist eben ein Unterschied ob ein Weg de facto verboten oder aufgrund der Meinung eines einzelnen Mappers für irgendwen als nicht benutzbar eingestuft wird.

Das wiederum ist deine Meinung, die ich nicht teile. Es ist mir egal, ob ich irgendwo nicht lang darf oder ob ich irgendwo nicht lang kann. Das Resultat ist ja letztendlich das selbe.

Ob Dir persönlich etwas egal ist, ändert nichts an den Fakten.

de_muur:

Das ist so meines Erachtens nicht zuende gedacht. Wenn Value eindeutig gewählt wird, können daraus für die Wirkung der Behinderung eindeutige Schlüsse gezogen werden.

Damit verlaesst man sich aber wieder auf reine Interpretation, d.h. jede Auswertung wird aus einer bestimmten Behinderung andere Konsequenzen ziehen.

Korrekt. So muß es sein. So entstehen sogenannte Themenkarten, die den Bedürfnisse der Endnutzer angepaßt sind. Deshalb sieht eine Karte für Rollstuhlfahrer anders aus, als eine Karte für Mtbiker, Sonntagsradler, Familien mit Bollerwagen Kinderwagen … , Wanderer oder Reiter. Was den einen nicht juckt, kann für den anderen ein Riesenproblem darstellen. Und die Problemstellen erkennt man am besten, wenn Fakten in neutraler Form beschrieben/zusammengetragen werden, die sich anschließend nach unterschiedlichen Gesichtspunkten auswerten lassen.

de_muur:

Da ist es doch viel klarer, wenn man direkt erfasst, wer in welcher Weise behindert wird. Von mir aus kann man auch gerne ZUSAETZLICH den Grund der Behinderung erfassen. Dabei darf man halt nur nicht das Wichtigste aus den Augen verlieren.

Gruss
Torsten

Bei dieser Argumentation übersiehst Du, daß eine derartige Erfassung von vornherein reine Interpretation ist. Die Interpretation der Situation durch den Mapper.

Gruß
tippeltappel

de_muur · 2010-06-10T17:56:53.000Z

tippeltappel:

Ob Dir persönlich etwas egal ist, ändert nichts an den Fakten.

Lass es mich anders formulieren: Es ist nicht mir egal, sondern es ist fuer jeden Kartennutzer egal. Denn ohne Ortskenntnisse kann er aus einer Unterscheidung zwischen nicht erlaubt und nicht moeglich sowieso keinen Nutzen ziehen. Beides basiert auf der Einschaetzung des Mappers, und der Nutzer kann entweder darauf vertrauen oder es bleiben lassen.

Korrekt. So muß es sein. So entstehen sogenannte Themenkarten, die den Bedürfnisse der Endnutzer angepaßt sind. Deshalb sieht eine Karte für Rollstuhlfahrer anders aus, als eine Karte für Mtbiker, Sonntagsradler, Familien mit Bollerwagen Kinderwagen … , Wanderer oder Reiter. Was den einen nicht juckt, kann für den anderen ein Riesenproblem darstellen. Und die Problemstellen erkennt man am besten, wenn Fakten in neutraler Form beschrieben/zusammengetragen werden, die sich anschließend nach unterschiedlichen Gesichtspunkten auswerten lassen.

Nein. Unterschiedliche Tehmenkarten wuerde auch herauskommen, wenn man klar die Einschraenkungen der Nutzung erfassen wuerde und nicht einfach nur die Ursache.
Was bei deinem Vorschlag rauskommt, sind fuer ein und den selben Endnutzer verschiedene Karten, je nachdem, wer die Karte gebaut hat.

Bei dieser Argumentation übersiehst Du, daß eine derartige Erfassung von vornherein reine Interpretation ist. Die Interpretation der Situation durch den Mapper.

Ja. Aber der Mapper ist der einzige, der die Lage vor Ort kennt. Der Kartenbauer und der Kartennutzer koennen dagegen nur noch raten.
Und genau darauf baut das Prinzip von OSM ja auch auf: Der Mapper vor Ort entscheidet, welcher Kategorie einem Weg/einer Strasse zugewiesen wird. Was du hier vorschlaegst wuerde bedeuten, dass man auch nicht mehr highway=motorway eintragen sollte, sondern stattdessen nur die Anzahl der Fahrspuren, die Oberflaechenbeschaffenheit und das Tempolimit und daraus sollen alle dann schon selber schliessen, dass es sich wohl wahrscheinlich um eine Autobahn handelt.

Gruss
Torsten

tippeltappel · 2010-06-10T18:02:06.000Z

Die Argumentation hat mit der Ausgangsfrage nun wirklich nichts mehr zu tun.
Und da geht es um das Problem, eine regelmäßig wiederkehrende temporäre Überflutung einer Straße darzustellen.

de_muur · 2010-06-10T18:13:15.000Z

tippeltappel:

Und da geht es um das Problem, eine regelmäßig wiederkehrende temporäre Überflutung einer Straße darzustellen.

Oder geht es darum, eine regelmaessig wiederkehrende Nichtnutzbarkeit einer Strasse darzustellen?

Ist die Strasse nur vom Wasser ueberspuelt? Wie hoch steht dann das Wasser? Kommt da eine Gelaendewagen noch lang?
Oder steht da auch noch ein Schild, dass waehrend Hochwasser die Strasse gesperrt ist? Wuerde das einen Unterschied machen?

Gruss
Torsten

aighes · 2010-06-10T20:12:39.000Z

Haben wir denn Accesstaggs, die zwischen sportlichem Jüngling und Oppa mit Krückstock unterscheiden? Ich kann über einen umgefallenen Baumstamm drüber “klettern” oder mich drunter her mogeln. Daher würde ich dafür kein foot=no taggen. Der Oppa scheitert an dem Baum.

Ähnliches Thema wird auch im Parallelthread Treppe mit Schiebegelegenheit diskutiert.

Es ist besser, wenn der Renderer/Router entscheidet, wie er mit dem Hindernis/Problem umgeht. Denn dieser kennt die Zielgruppe und kann dementsprechend das Hindernis/Problem berücksichtigen.

Basstoelpel · 2010-06-10T20:55:53.000Z

Weide:

aighes:

Überdenk nochmal Ebbe und Flut…Flut ist wenn viel Wasser da ist. Da wäre es komisch, wenn die Straße bei Flut passierbar ist und bei Ebbe nicht.

Nö
Flut ist, wenn das Wasser kommt; Ebbe ist, wenn das Wasser geht.

Weide

Ebenfalls nö. Das nennt sich Flut läuft.

Baßtölpel

tippeltappel · 2010-06-10T22:11:26.000Z

de_muur:

tippeltappel:

Und da geht es um das Problem, eine regelmäßig wiederkehrende temporäre Überflutung einer Straße darzustellen.

Oder geht es darum, eine regelmaessig wiederkehrende Nichtnutzbarkeit einer Strasse darzustellen?

Ist die Strasse nur vom Wasser ueberspuelt? Wie hoch steht dann das Wasser? Kommt da eine Gelaendewagen noch lang?
Oder steht da auch noch ein Schild, dass waehrend Hochwasser die Strasse gesperrt ist? Wuerde das einen Unterschied machen?

Gruss
Torsten

Die wiederkehrende temporäre Überflutung ist Fakt. Die Nichtnutzbarkeit ist Interpretationssache und abhängig von Faktoren, die der Mapper nicht in jedem Fall kennen oder berücksichtigen kann.

Wird eine Karte für eine bestimmte Zielgruppe gerendert, kann die Karte mit Hinweisen versehen werden, wann die Straße von dieser Gruppe noch nutzbar ist und wann nicht. Eine neutrale Karte gibt diese Entscheidung an den Nutzer der Karte weiter, indem sie einfach nur die 3 maximalen Wassertiefen (Nippflut/Flut/Springflut) anzeigt.

Voraussetzung für derartige Angaben ist, daß mit Hilfe von Schlüsselpaaren, die maximale Wassertiefe bei Nippflut / Normalflut / Springflut ablesbar ist. Die kann ein Renderer auslesen und in irgendeiner Form an die Straße setzen. Wenn es mehrere sich deutlich unterscheidende “Tiefenzonen” gibt, könnte man die Strecke auch aufteilen, damit man besser erkennen kann, wo einen das Wasser am ersten “erwischt”.

Vorschläge für keywords:
neap=Nippflut http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=&search=Nippflut
springtide=Springflut http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=&search=Springflut
tide=normaleFlut

und für die verschiedenen Wasserstände daraus abgeleitet:
neap:head:max=
springtide:head:max=
tide:head:max=

Für Hochwasserzonen an Flüssen ist das System abzuwandeln:
An regelmäßig von Hochwasser gefährdeten Wegen bietet sich die Angabe der Wassertiefe für den tiefsten Punkt mit Bezug auf Hochwasserstufen an. Das sind amtlich festgelegte Werte. Was da wie beim Taggen am praktikabelsten ist, müßte man noch herausfinden. Ein einheitliches Tagschema mit Bezug auf eine recherchierbare Größe ist wichtig. Kennt man den aktuellen Pegelstand, kann man sich ausrechnen, wie tief der Grund unter Wasser liegt.
flood:grade1=(Wassertiefe bei Hochwasserstufe 1)
flood:grade2=(Wassertiefe bei Hochwasserstufe 2)
usw.
Ein farbiges Schild könnte die Hochwasserstufe anzeigen, ab der der Weg überflutet wird und eine Zahl die Wassertiefe, die bei Erreichen der angezeigten Hochwassermarke herrscht. Fehlt eine Maßangabe, wäre das auch nicht schlimm. Dann markiert das Schildchen einfach nur mit Farbe und der Aufschrift HW1 / HW2 etc die Hochwasserzone. An den verschiedenen Farben erkennt man dann leicht die verschiedenen vom Hochwasser gefährdeten Gebiete.

siehe auch:
http://www.elwis.de/gewaesserkunde/Wasserstaende/Wasserstaende_start.php?target=1&pegelId=2730010
http://www.steb-koeln.de/warnstufen.html?&L=qcudsytzuoh
http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=flood&trestr=0x8001
http://www.hw-karten.de/koeln/ (Hochwassergefahrenkarte)

Gruß
tippeltappel

de_muur · 2010-06-11T05:20:38.000Z

tippeltappel:

Die Nichtnutzbarkeit ist Interpretationssache und abhängig von Faktoren, die der Mapper nicht in jedem Fall kennen oder berücksichtigen kann.

Er ist und bleibt aber der einzige, der ueberhaupt eine ahnung von der Lage vor Ort hat.

Voraussetzung für derartige Angaben ist, daß mit Hilfe von Schlüsselpaaren, die maximale Wassertiefe bei Nippflut / Normalflut / Springflut ablesbar ist. Die kann ein Renderer auslesen und in irgendeiner Form an die Straße setzen. Wenn es mehrere sich deutlich unterscheidende “Tiefenzonen” gibt, könnte man die Strecke auch aufteilen, damit man besser erkennen kann, wo einen das Wasser am ersten “erwischt”.

Damit baust du ein unheimlich kompliziertes System fuer genau einen einzigen Sonderfall. Fuer jeden anderen Sonderfall muesstest du auch andere Parameter zusaetzlich erfassen, damit die Behinderung interpretierbar wird.

Meinst du, dass sowas Eingang in die Router findet?

Wieviel einfacher zu realisiseren waere da ein System, bei dem der Mapper in erster Linie die Auswirkung der Behinderung erfasst und die Ursache nur erlaeuternd hinzufuegt? Das wuerde dem Renderer immer noch hinreichend Interpretationsraum fuer verschiedene Routing-Anwendungen geben.

Nochmal: Das gesammte OSM-System beruht bislang darauf, dass der Mapper vor Ort die Wirklichkeit interpretiert, kategorisiert und in die Datenbank eintraegt. Die Auswertung entscheidet eigentlich nur, in wie weit diese Eintragungen fuer sie von Belang sind. Es ist nicht die Idee, das die Auswertung noch gross rum raet, was denn der Mapper mit seinen Eintragungen gemeint haben koennte.

Gruss
Torsten

aighes · 2010-06-11T07:32:14.000Z

Meiner Meinung nach sollte der Mapper vor Ort nicht interpretieren, sondern die Wirklichkeit erfassen.

Also er soll eintragen, dass da ein Baum liegt und nicht access=no. Anhand der Tatsache, dass da ein Baum liegt kann dann der Auswerter entscheiden wie er den Fall bewertet.

Du trägst doch sicher auch highway=steps ein und nicht highway=path|footway und vehicle=no

de_muur · 2010-06-11T09:35:58.000Z

aighes:

Meiner Meinung nach sollte der Mapper vor Ort nicht interpretieren, sondern die Wirklichkeit erfassen.

Eine Karte ist eine interpretation/Abstraktion der Wirklichkeit. Wenn man nicht interpetiert/abstrahiert, dann landet man nicht bei einer Karte sondern bei einer Kopie der Wirklichkeit.

Also er soll eintragen, dass da ein Baum liegt und nicht access=no. Anhand der Tatsache, dass da ein Baum liegt kann dann der Auswerter entscheiden wie er den Fall bewertet.

Der Mapper vor Ort kann entscheiden, ob durch den Baum die Strasse komplett fuer alle Verkehrsteilnehmer unpassierbar geworden ist oder ob man da zu Fuss oder mit dem Rad noch durch kommt oder die Strasse durch den umgestuerzten Baum vielleicht nur stark eingeengt ist, so dass jeder noch durch kommt, man nur das Tempo anpassen muss, oder was weiss ich nicht noch alles.
Dieses Wissen fehlt dem Auswerter, wenn er einfach nur weiss, dass da ein Baum-Hindernis ist, und deshalb kann er den Fall auch nicht selber bewerten.

Du trägst doch sicher auch highway=steps ein und nicht highway=path|footway und vehicle=no

Das verstehe ich nicht. Je nach Gegebenheit trage ich das eine oder das andere ein und es gibt auch Grenzfaelle, wo es mir schwer faellt, zwischen beiden Varianten zu unterscheiden. Aber was soll mir dein Beispiel sagen?

Fehlt dir beim highway=steps nach meiner Argumentation ein zusaetzliches vehicle=no? Es gibt auch Leute, die das machen, auf der Mailingliste ist gerade ein recht ausfuehrlicher Thread ueber ein horse=no bei highway=motorway.

Gruss
Torsten

tippeltappel · 2010-06-11T09:47:33.000Z

de_muur:

tippeltappel:

… Voraussetzung für derartige Angaben ist, daß mit Hilfe von Schlüsselpaaren, die maximale Wassertiefe bei Nippflut / Normalflut / Springflut ablesbar ist. Die kann ein Renderer auslesen und in irgendeiner Form an die Straße setzen. Wenn es mehrere sich deutlich unterscheidende “Tiefenzonen” gibt, könnte man die Strecke auch aufteilen, damit man besser erkennen kann, wo einen das Wasser am ersten “erwischt”.

Damit baust du ein unheimlich kompliziertes System fuer genau einen einzigen Sonderfall. Fuer jeden anderen Sonderfall muesstest du auch andere Parameter zusaetzlich erfassen, damit die Behinderung interpretierbar wird.
…

Gruss
Torsten

Was ist daran kompliziert? Und inwiefern ist das ein Sonderfall?

neap:head:max=
springtide:head:max=
tide:head:max=

erfordert die Eintragung von 3 verschiedenen Zahlen. Vielleicht gibt es wie für Hochwassergebiete (Beispiel Köln) amtliche Statistiken, aus denen sich diese Zahlen für die Pegelstände heraus lesen lassen. Relevant für die Eintragung ist die maximale Wassertiefe eines klar definierten Streckenabschnittes, die sich auf den mittleren Pegelwert von Nippflut, normaler Flut und Springflut bezieht.

Der Renderer macht aus diesen Angaben eine Wegbeschriftung, die etwa so gestaltet sein könnte [nh=-200/th=+100/sth+500] und hängt sie an den Straßennamen.

Ob nun ein Router diese Sollwerte mit Istwerten abgleichen kann, steht nicht zur Debatte. Wer wissen will, ob die Straße passierbar ist, guckt sich auf der Pegelanzeige im Internet den Istwert an, errechnet die Differenz zum Mittelwert, addiert oder subtrahiert ihn mit der an der Straße angegebenen Zahl und trifft dann seine Entscheidung.

Geht der Kartenersteller davon aus, daß das für seine Kunden zu kompliziert ist, nimmt er ihnen die Entscheidung ab und errechnet für den worst case die Passierbarkeit. Beispiel: wenn Wasserstand kleiner +10 dann passable / wenn Wasserstand größer +10 und kleiner +100 dann special_vehicle / wenn Wasserstand größer +100 dann impassable

Die Zahlen sind beliebig austauschbar und die Scala kann vom Kartenersteller beliebig erweitert werden.

Daraus läßt sich eine “Ampelanzeige” konstruieren: [grün/gelb/rot]
Die je nach Lage des Weges auch [grün/rot/rot] oder [grün/grün/rot] oder [grün/grün/gelb] aussehen kann.

Durch Einbeziehung anderer Symbole oder Farben ließe sich die “Ampelanzeige” variieren.

Stehen keine Zahlen zur Verfügung stehen, muß das Erfassungssystem vereinfacht werden. Statt der Zahlen trägt man direkt
*=passable (für jedes Fahrzeug auch Fahrrad und Fußgänger passierbar)
*=special_vehicle (nur für Spezialfahrzeuge passierbar)
*=impassable

Damit wird dem Renderer aber die Möglichkeit genommen, Sonderkarten zu erstellen, die für Nutzer, deren Fahrzeuge nicht der allgemeinen Norm entsprechen, exakt berechnen, ob eine Passage an neuralgischen Punkten noch möglich ist, oder nicht.

Für Router macht vermutlich ein anderes System mehr Sinn:
unabhängig von diesen Kartendaten an Pegelstationen abrufen, ob eine von Überflutungsgefahr betroffene Straße gesperrt ist oder nicht.

Gruß
tippeltappel