ich möchte am Ärmelkanal eine Auto-Straße auf eine (Halb-)Insel taggen. Bei Ebbe ist die Straße überspült, bei Flut nicht. (der Tidenhub ist dort 9 bis 11 m zweimal täglich). Es gibt eine lokale Internetseite, die täglich die Zugangszeiten nennt. Wie tagge ich soetwas und kann ich einen link sinnvoll auf diese Internetseite setzen?
moin,
ich hab mal ein “tidal=yes” irgendwo gesehen, weiss aber nicht ob das “offiziell” ist.
Kannst ja mal auf Tagwatch suchen.
Chris
Ü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.
Das ist auch so eine Strasse, die nur bei EBBE befahren werden kann (http://www.openstreetmap.org/browse/way/24369838). Hier wurde sie als waterway=tidal getaggt.
ääähhmm, Dank für das lesen und verstehen meines postings, ich tippe erst und lese danach (manchmal auch nicht 
), gut dass meine Frage trotzdem verständlich war und auch danke für die Antworten
Gruß Michelwald
Hmmm - waterway interpretiere ich als Element einer Wasserstraße im Sinne von Fluß und zugehörigen Bauten. Hier geht es aber doch um eine Straße, die zeitweise vom ansteigenden Wasser überflutet ist. Daher würde ich zunächst mal ein passendes highway-Tag anwenden und dann einen Zusatz wählen, der die zeitweilige Blockade durch das Wasser deutlich macht. Etwa so:
highway=primary (oder was auch immer paßt … unclassified )
barrier=water oder tidal_water
Das dürfte sich gut auswerten lassen, indem man zunächst die Straße dem Highway-Tag entsprechend darstellt und dann für barrier=tidal_water ein overlay z.B. aus blauen Querstrichen über die Linie setzt.
Gruß
tippeltappel
Nö 
Flut ist, wenn das Wasser kommt; Ebbe ist, wenn das Wasser geht.
Den Zustand mit wenig Wasser nennt man Niedrigwasser.
Weide
Was wäre mit:
highway=*irgendwas*
access=tidal
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
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
Hallo tippeltappel
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).
‘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)
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.
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
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
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.
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.
Deine Meinung sei Dir unbenommen. Deine Argumente überzeugen mich aber nicht.
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
Hallo tippeltappel
OK, die Bedeutungswolke von ‘obstruction’ reicht offensichtlich aus,
alle von dir gewünschten Bedeutungen abzudecken.
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.
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)
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.
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
Ob Dir persönlich etwas egal ist, ändert nichts an den Fakten.
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.
Bei dieser Argumentation übersiehst Du, daß eine derartige Erfassung von vornherein reine Interpretation ist. Die Interpretation der Situation durch den Mapper.
Gruß
tippeltappel