Hallo
Bei Brücken die nicht beschildert sind haben wir uns doch auf “maxheight=none” geeinigt?
Oder hab ich was verpasst
Gestern Borna wieder auf 4.0 m gesetzt bin durchgefahren mit 4 m beschildert aber mit 3.8 eingetragen gewesen?
Beste Grüße
Nein, Chenski hat’s vermutlich verpasst. Sollte man vielleicht im Wiki ergänzen.
Vergiss nicht noch oneway=no usw. Wenn es nur für die Auswertung in der Karte dient, werte das irgendwie über Schnittpunkte oder einen height an der Brücke aus. Aber die Wege jetzt auch noch für einen ohnehin per Default angenommen Wert noch weiter völlig sinnlos zu zerbröseln, macht doch absolut keinen Sinn. Wenn da keine Beschränkung steht ist das so, will ich die Durchfahrtshöhe wissen, muss ich die Höhe der Brücke auswerten.
Ich finde auch, Wege extra zu zerbrösen macht keinen Sinn.
Das durchschnittliche Stück primary in meiner Gegend ist aber sowieso nur 400m lang (secondary 480m). Da kann man ein Stück mit Brücke auch gut mit maxheigh=none beschriften, falls zwischen zwei maxspeed-Grenzen oder Abbiegebeschränkungen keine niedrigeren Brücken kommen.
Grüße, Max
Und warum da und den Rest der Straßen nicht? Wenn keine Brücke über der Straße ist, ist doch auch maxheight=none…wenn schon, dann konsequent oder eben gar nicht. 
Damit eine Auswertung “Ruhe” gibt? Evtl. sollte man dann besser die Auswertung verbessern, bspw. in dem man ihr sagen kann, die Brücke ist ok, musste nicht mehr anmeckern.
Wenn da sowieso schon alles zerhackt ist, kann man das gerne eintragen, auch wenn dieser Defaultwert genauso sinnvoll oder sinnlos wie oneway=no, layer=0, tunnel=no etc. ist. Für die Auswertung kann man wie schon geschrieben Schnittpunkt und min_height/height an der Brücke darüber auswerten. Das das es so funktioniert, haben schon vor Jahren die Checks von Garry gezeigt.
Aber es wäre jetzt absolut fatal alles noch mehr aufzuschneiden und z.B. die dazu gehörigen Relationen noch weiter sinnlos aufzublähen. Dieses zerstückeln ist an sich schon unglücklich genug, wäre schön, wenn man das mal irgendwann dynamisch mit from to über nodes und ohne schneiden machen könnte. Nur gehts im Moment noch nicht und da sollte man sich jeden vermeidbaren Cut sparen, wo der Fall hier definitiv dazu zählt.
Sollte ich so etwas finden, werde ich es auch definitiv wieder rückgängig machen. Denn das ist absolut keine wertvolle Information, da maxheight=none automatisch für alle highway=* per default angenommen wird. Das ist einzig taggen für bequemes auswerten.
Keine Ahnung wo das war, über zwei Jahre her wo ich das genutzt habe. Da gab es früher diverse Tools von u.a. eben Garry68, glaube Sven Anders, Flo Lohoff etc. die Schnittpunkte auf fehlende Layer usw. geprüft haben. Damals gab es da massenhaft Probleme mit, dank Potlatch. Hier gibt es doch glaube auch eine dev Liste, wo sich die Fachleute austauschen. Fragt doch da mal einfach mal nach.
Was für ein Beispiel? Nimm irgendeine Brücke deiner Wahl und trage daran die Höhe ein. Dann musst du diesen Schnittpunkt auswerten, wie das im Detail technisch geht , kann ich dir nicht beantworten, nur das es geht und so auch schon gab.
Dann beschreibe es bitte genauer was du dir vorstellst. Was ich mir vorstelle habe ich schon mehrmals geschrieben, Höheninformation an die Brücke und auswerten, maxheight=no ist default und man muss da gar nichts taggen. Also auch kein Beispiel wo es was zu sehen gäbe.
Das betrifft ja nicht nur Brücken. Das betrifft von Baumkronen im Lichtraum bis Mittelspannungsleitungen noch vieles anderes. Wie man es löst ist nicht meine Aufgabe, nur halte ich das aufsplitten für jeden dieser Fälle, das noch mit dem sowieso gegebenem Defaultwert, für absolut suboptimal.
Blöd nur, dass die Höhe einer Brücke eher veränderlich ist. Der Grund ist ja in der Regel keine ebene Fläche. Es ist etablierter Standard, die Einschränkung dort zu erfassen, wo sie auftritt.
Das Problem hier ist doch eher, dass die Anwendung fehlende max_heights sucht und man anscheinend Brückendurchfahrten ohne diese Eigenschaft nicht von unbekannten Unterscheiden kann. Bisher wird dazu der Default getaggt, was nicht unbedingt sinnvoll ist. Wenn die Auswertung hier verbessert werden soll, sodass man Brücken als erledigt markieren kann, ist das Thema doch durch…
http://wiki.openstreetmap.org/wiki/DE:Key:bridge
Höhe über Grund soll mit height bereits schon heute erfasst werden. Jetzt kann man das noch meinetwegen mit min_height für lichte Höhe zwischen Grund und Tragswerksunterkannte ergänzen. Das sollte für eine Auswertung reichen.
Ja, Straßen haben in Kurven eine Querneigung etc. alles Zukunftsmusik die an diversen Stellen Probleme machen und die wir in OSM bisher nur schwer bis gar nicht darstellen können. Für den Fall reicht es aber erst einmal wenigstens einen Wert zum Auswerten dahin zu bekommen, ob nun erst einmal der kleinste, oder vorerst ein Schnitt ist, muss man sehen. Und klar sollte man die Einschränkung da taggen wo sie ist, nur in dem Fall ist da ja keine Einschränkung an sich, die eine weitere Cutorgie rechtfertigt.
wenn ihr maxheight unbedingt an die Brücke obendrüber schreiben wollt, sollte maxwidth auch gleich mit geändert werden. Bisher wird das an den Weg getaggt. Analog zur Maxheight Änderung müsste das dann rechts und/oder links vom Weg erfasst werden
Darum geht es ja eben nicht, es sollten jetzt nur nicht generell alle Straßen unter Brücken ohne ausgeschilderte Beschränkung gesplittet und mit dem defaultwert no versehen werden, was einzig zur Befriedigung einer Anwendung dient. Wo tatsächlich eine Beschränkung existiert, ist der Cut doch gerechtfertigt.
Ok, und wenn wir das mit dem Kommentar von Henning verbinden, sprich genau diese Stellen in der Auswertung als ‘false-positive’ (oder hier gibt’s keine Beschränkung) zu markieren, ist doch eigentlich alles gut… Wie gesagt, mal schauen, wie schnell das realisierbar ist.
Und was ist mit meinem Vorschlag, maxheight einfach an einen Node unter* der Brücke zu pappen? Kein Zerstückeln von Straßen nötig, aber genauso wirksam.
Man muss den Wert aber auch nicht an die Brücke selbst pappen - und ihn dann für jede Anwendung von der Brücke “pflücken” (die man ersteinmal noch finden muss).
Das Problem, ausgehend von einer Brücke den zugehörigen Node mit maxheight zu finden, hat man eigentlich nur an einer Stelle: der Auswertung auf fehlende maxheight-Tags. Ich hab bisher noch nicht mit postgis gearbeitet, aber es gibt da meines Wissens die Möglichkeit, buffer rings um Objekte zu definieren, um diese Suche zu vereinfachen.
Die Router interessieren sich nur für die Nodes, die Brücke dazu ignorieren sie. Renderern ist das auch egal, ob maxheight jetzt an einem node oder way hängt, ein Symbol können sie so oder so unterbringen. Hab ich was wichtiges vergessen?
Für die ganz extremen Fälle kann man ja auch weiterhin problemlos den Straßen-Way mit maxheight taggen. Stellen wie diese: http://osm.org/go/0DmUhdCd7
*unter = idealerweise sehr nahe, also ~0-1m vom Brücken-way entfernt. Bei breiten Brücken mit mehreren Fahrspuren oder “Brückenbündeln” müsste man da evtl. etwas mehr nehmen, evtl. ~10m. Müsste man testen.
Wenn du das so lösen kannst, alles geritzt.
Trotzdem sollte man sich da generell mal langfristig einen Kopf beim Thema splitten für Eigenschaften machen. Die Möglichkeiten für Eigenschaftsbeschreibung wachsen, nur werden die Straßenabschnitte immer kleiner und kleiner, Relationen dafür länger und länger.
Das findet durchaus auch Niederschlag in der Beschilderung.
In Königswinter z.B. gibt es eine Straße unter der B42 (Oberweingartenweg), die (in Fahrtrichtung bergauf) auf der rechten Spur mit 3.5m ausgeschildert ist, auf der linken Spur jedoch mit 4m. Ob das an der leichten Steigung der Brücke liegt oder an einer Querneigung der Straße weiß ich nicht genau. Aus meiner Erinerung war es eine Kombination von beidem. Übrigens hat nur die östliche Richtungsfahrbahn der B42 eine Höhenbeschränkung, die westliche keine (der Oberweingartenweg führt bergauf).
Die Angabe von maxheight=none macht meiner Meinung nach durchaus Sinn, da es einen Unterschied ist, ob ich sage ich habe das angesehen/geprüft und es gibt keine Höhenbeschränkung im Rahmen der StVO oder ob da einfach kein Wert steht (=unknown). Das machen wir bei maxspeed ja auch so.
Es gibt meines Erachtens keinen Grund, wegen maxheight=none eine Straße zu splitten. Wenn maxheight=none unter der Brücke gilt, dann gilt das auch für den Rest der Straße, wo freier Luftraum ist.
Edbert (EvanE)
Das Problem am height-Ansatz ist das man nicht unbedingt davon ausgehen kann, das dort wo height getaggt ist auch maxheight an der unteren Straße getaggt ist. Das heißt man kann evtl. einige Brücken über x Meter aussortieren, aber es ist keine Gesamtlösung. (ganz davon abgesehen das der Aufwand an einen height-Wert zu kommen oft schwieriger ist, als an den maxheight)
Das Problem an der Extra-DB-Lösung: sie nützt nur einer Anwendung, falls diese Anwendung eines Tages nicht mehr weiter angeboten werden kann, sind die Daten evtl. verloren.
Gruß
BBO
Das meinte ich noch nicht mal. Stell dir einfach eine Brücke vor, die über eine Straße und einen Kanal verläuft und auf der anderen Kanalseite ist hinter und auf einem Deich noch ein Feldweg. Jedes, die Brücke querende Objekt hat eine andere lichte Höhe im Bezug zur Brücke. Es ist doch wohl kaum sinnvoll, die Brücke dann in 4 bis 6 Teile zu teilen, nur damit die Höhe über jedem Objekt stimmt.
Btw. wird doch egtl. in height die Höhe einer Brücke über NN eingetragen und nicht über den darunter befindlichen Grund. Wie soll das zur Bestimmung der Höhe über Grund helfen?
Hi !
warum Gedanken machen über das zerstückeln - wenn ich mir LANES ansehe dann besteht eine Strasse irgendwann nur noch aus zwei-Punkt-ways !
Jan