Anfängerfrage: Strasse im Gezeitenwechsel

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

de_muur · 2010-06-11T10:10:47.000Z

tippeltappel:

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

Weil du fuer jede Hinderniss-Art einen anderen Parametersatz brauchst, damit die aus dem Hinderniss resultierende Einschraenkung abschaetzbar wird.
Wenn man die Folgen direkt eintraegt, dann kann man das fuer alle Arten von Hindernissen gleich machen.

Gruss
Torsten

tippeltappel · 2010-06-11T11:44:10.000Z

Du argumentierst sehr allgemein. Von welchen Hindernis-Arten schreibst Du?

Hier geht es um ein in Küstenlandschaften und Flußlandschaften bekanntes Problem: der temporären Überflutung von Wegen. Das ist kein Sonderfall. Da ich 20 Jahre lang in einem Hochwassergebiet gewohnt und protokolliert habe, wo man bei welchem Pegelstand noch durch kann bzw. das Wasser vor der Haustüre steht, weiß ich, von wie großem Interesse Karten sind, aus denen man in irgendeiner Form Überflutungszonen ablesen kann.

Gruß
tippeltappel

de_muur · 2010-06-11T12:50:05.000Z

tippeltappel:

Du argumentierst sehr allgemein. Von welchen Hindernis-Arten schreibst Du?

Hier im Thread wurde allgemein obstruction=* vorgeschlagen: fuer z.B. umgestuertzte Baueme, Baustellenverkehr, Jahrmaerkte usw.

Etwas ueber den Tellerand zu schauen ist sicherlich auch sinnvoll, man kann ja nicht fuer jeden Einzelfall ein eigenes Tagging-Schema entwickeln.

Und worum es hier mir die ganze Zeit geht, ist die Erkenntnis, dass es nichts bringt, die Ursache fuer jede Art von Hindernis moeglichst detailliert zu erfassen. Viel sinnvoller ist es, vorrangig die durch das Hindernisses verursachte Einschraenkung in die Datenbank aufzunehmen. Die Ursache fuer die Einschraenkung ist nur eine kleine Randnotiz.

Gruss
Torsten

tippeltappel · 2010-06-11T14:07:04.000Z

Nunja, es kommt drauf an, wie man das angeht.

obstruction=* nennt die Ursache für eine Verkehrsbehinderung, die gegebenenfalls mit einem entsprechenden Verkehrszeichen auf der Karte dargestellt werden kann.
Je nach Art der Behinderung lassen sich die Ereignisse gruppieren und dazu passende Schemata entwickeln. Dabei kann man ein einfaches Grundschema verfolgen.

(1) Bei Behinderungen durch öffentliche Veranstaltungen wie obstruction=Kirmes, Weihnachtsmarkt, Wochenmarkt, Flohmarkt, Karnevalszug etc würden Erweiterungen wie obstruction:time und obstruction:access= Sinn machen. Damit ließe sich darstellen, wann mit welchem Ereignis zu rechnen ist und welche access-Bestimmungen dann gelten.

(2) Bei Behinderungen durch temporär auftretende Gefahren wie obstruction=Wildwechsel/Schwerlastverkehr/Werksausfahrt/Viehtrieb wird angegeben, ob ein Zeitfenster für das Auftreten der Behinderung erkennbar ist oder nicht. Wenn ja, paßt auch hier wieder obstruction:time=* . obstruction:access=* ist bei solchen Verkehrsbehinderungen wohl eher überflüssig.

(3) Wird die Verkehrsbehinderung durch einen eine räumliche Beengung hervorrufenden Gegenstand oder ein den Verkehrsweg schädigendes Ereignis hervorgerufen, entfällt möglicherweise obstruction:time=. obstruction:access= könnte dagegen sinnvoll eingesetzt werden und weist wie in (1) auf eine der Sondersituation angepaßte Ausnahmeregelung hin.
Variante: Wird ein Verkehrsweg auf absehbare Zeit räumlich eingeengt z.B. obstruction=Baustelle macht obstruction:time=* wieder Sinn. Ob obstruction:access=* Sinn macht, hängt von der Situation vor Ort ab. obstruction:width_max=* , obstruction:height_max= * oder obstruction:max_speed könnten ebenfalls Sinn machen.

Das sind drei obstruction-Typen, die mit vielen Namen versehen werden können, aber letztlich alle mit ähnlichem Muster nach Bedarf getagt/beschrieben werden. Ich sehe da jetzt nicht das Problem eines endlos ausufernden Taggingschemas.

obstruction=tidal_water fällt aus diesem Schema heraus, wenn man die Problematik differenziert erfassen möchte. Welches oder welche der oben beschriebenen keys letztendlich sinnvoll eingesetzt werden können, muß der mapper entscheiden, der vor Ort die Daten erfaßt. Bei dieser Entscheidung hat er völlig freie Hand.

Als erste (wie heißt es so schön?) “unschädliche” Maßnahme schlage ich vor, bei zeitweise überspülten Straßen das Tag obstruction=tidal_water zu setzen. Das läßt sich problemlos in ein Overlay (z.B. blaue Querstriche) umsetzen.
Erweiterungen sind dann immer noch möglich.

Gruß
tippeltappel

de_muur · 2010-06-11T16:22:34.000Z

tippeltappel:

obstruction=tidal_water fällt aus diesem Schema heraus, wenn man die Problematik differenziert erfassen möchte.

Genau wie Bergpaesse, die im Winter nicht passierbar sind, und viele aehnlich Sachen.

Als erste (wie heißt es so schön?) “unschädliche” Maßnahme schlage ich vor, bei zeitweise überspülten Straßen das Tag obstruction=tidal_water zu setzen.

Das ist sicherlich unschaedlich und kann von mir aus gerne gemacht werden, in meinen Augen ist es allerdings aber auch voellig nutzlos, da nicht davon auszugehen ist, dass irgendeine Routinganwendung in absehbarer Zeit dies beruecksichtigen wird.

Wie ich viel weiter oben mal geschrieben habe, wuerde ich persoenlich erstmal ein access-Tag eintragen. Das ist dann zwar sicherlich noch nicht das letzte Wort in dieser Sache, aber es hilft als Ausrufezeichen schon mal deutlich weiter, weil viel eher auffaellt, dass die Strasse nicht normal nutzbar ist.

Gruss
Torsten

tippeltappel · 2010-06-11T16:42:18.000Z

Dieses Tagging ist ganz bestimmt nicht nutzlos.
Jeder, der möchte und in der Lage dazu ist, die entsprechenden Renderregeln zu schreiben, kann key obstruction=* sofort (!) differenziert auswerten. Es ist griffig, klar und eindeutig. Was auch immer “irgendwelche Routingandwendungen” sein mögen, ob sie es auswerten oder nicht, ist deren Problem. Es gibt Leute, die brauchen die nicht. Ich gehöre dazu. Mich interessiert eine lesbare Karte. Und die läßt sich mit diesem Tagschema um wertvolle Informationen erweitern.

Gruß
tippeltappel