Falk, bei der Tagfindung werden ja auch andere Quellen genutzt. Das ist auch völlig ok, dann wird drüber diskutiert und am Ende landet das “Ergebnis” im wiki und das sollte dann für unsere Zwecke “bindend” sein.
Simples Beispiel ele: Hier sollte man die Höhe des Ortes ab Meeresspiegel eintragen. Nun findet sich aber bestimmt eine Quelle, die unter der Höhe des Berges die Höhe ab Erdmittelpunkt versteht. Was nun?
Ähnlich bei culvert. Wenn WIR der Meinung sind, culvert ist nicht nur der Durchlass unter der Straße, sondern allgemein ein fließendes Gewässer in einer Röhre, dann sei dem so. Zu nahezu jeder Sache findet man unterschiedliche Quellen. Da ist es nicht hilfreich zu argumentieren im Brockhaus steht A und der andere Argumentiert mit der Wikipedia und da steht B und das dann bei jedem Eintragen des Objektes.
Dann ist es in Ordnung. Prüfen müssen wir unser Wiki aber dennoch. kann ja sein, dass der/die Wikiersteller nicht sorgfältig gearbeitet haben. Dann muss man schauen, was für einen Schaden es anrichten würde das gerade zu biegen. Läuft dann auf eine klassische Abwägung der Vor- und Nachteile hinaus.
Im vorliegenden Fall will mir aber die Definition über die Länge nicht so richtig einleuchten. Mir fällt gerade kein Objekt ein, dass seine Eigenschaft verändert, nur weil es länger wird. Die entscheidende Frage ist also: gibt es jemanden außerhalb des OSM-Universums, der mit vernünftigen Gründen sagt, ein culvert ist max. 100 m lang. Bei >100 m ist das eine Röhre oder was auch immer (die 100 m sind beispielhaft gemeint).
Apropos Höhe vom Meeresspiegel aus. Da messen die einzelnen Länder auch mit unterschiedlichen Bezugssystemen. Ah, ich sehe gerade unser Wiki empfiehlt vorbildlich ein bestimmtes Bezugssystem (WGS84)
Wäre es nicht einfacher, dem Mapnik-Stil beizubringen, tunnelnde Flüsse etwas deutlicher wässrig zu malen? Der kann ja schon auch unterirdische Strassen und Flüsse unterscheiden, nur ist der blaue Rand halt anscheinend etwas undeutlich. Bei stream und canal ist er deutlicher. (alle drei Beispiele mit waterway=XY, tunnel=yes, layer=-n im zoom 18)
Die Frage, wie etwas in einem Renderer dargestellt wird hat doch aber nichts damit zutun, wie man es erfasst…Wenn ich eine Karte mache, auf der ich unterirdische Wasserläufe knallrot darstellen möchte, dann kann ich das machen.
Dann bleibt aber trotzdem das Problem, dass durch eure Definition mit tunnel=yes der Renderer falsch agiert, da er bei tunnel=yes automatisch von highway ausgeht und das ist dann falsch. Bei culvert würde er es als Wasserlauf darstellen - zwar auch nicht ganz richtig, da er es nicht strichliert darstellt - aber immerhin nicht als Weg/Straße - und das hat definitiv nichts mit taggen für den Renderer zu tun, sondern einfach damit, dass ein Bachlauf nicht als Straße dargestellt werden sollte.
Edit. Ortogravieh[/quote]
Ich bin nicht ein befürworter von tunnel=yes, sondern wollte eine Lösung dafür, dass tunnel=culvert nicht korrekt ist.
Wikipedia eignet sich aber auch hervorragend zum Übersetzen von Wörtern, welche keine eindeutige 1:1 Übersetzung haben. (Seit ich mich mit ADR beschäftige, weiß ich was das heißt!)
Aber zurück zur osm-wiki:
[quote]tunnel=* is used for roads, railway line, canals etc that run underground.
…
Where the water from a smaller stream, drain or even cattle crossing passes under under a structure or building consider using tunnel=culvert in place of the tunnel=yes used for larger tunnels for roads or railways or canals. [/quote]
Wenn ein render damit automatisch einen highway implementiert, dann ist das ein Fehler des Renders.
Mal eine blöde Zwischenfrage von einem Praktiker: Wie erfasst man den Verlauf von unterirdisch verlaufenden Gewässern? Ich habe da so einen hier, weiß wo der in den Untergrund geht und wo er wieder rauskommt. Aber der geht unterirdisch nicht geradeaus.
[Ironie]
Und ohne mich in die theoretische Diskussion einmischen zu wollen…mir wäre auch als Auswerter von unterirdischen Wasserwegen bestimmt eingefallen, dass waterway=* + tunnel=yes zu berücksichtigen wäre. An 100 andere Möglichkeiten, die laut Taginfo ganze 47 Mal benutzt werden, denkte natürlich auch jeder auch
[/ironie]
Wie wäre es mit einem etablierten Tag + dem genauen Tag wie culvert=yes
Thomas, als Auswerter sollte man bei yes/no-Keys egtl. immer auf !=no prüfen und nicht auf =yes. Evtl. vorher noch false, 0 und no normalisieren. Wenn man dann genauer aufdröseln möchte, kann man das dann nach bedarf tun, in dem man vorher die interessanten Werte abfragt.
So war das mit building auch mal. Jetzt kannst Du maschinell nicht mehr prüfen, obs ein building gibt. Ich meine, früher gabs building=yes/no. Jetzt gibts building=residential, garage, house aber eben auch collapsed, ruins, construction, proposed. Das Problem ist jetzt nicht riesig, aber wer weiß was mal draus wird. Daher finde ich den Ansatz, bspw building=yes, building:type=house mit building=house abzukürzen generell falsch, bei jedem Objekt.
Abfragen muss ich jetzt buildings allerdings auch so wie Du schreibst, da ich nicht mit sich stetig veränderten Ausschlußlisten arbeiten will.
Nachdem in Österreich (und wohl auch in anderen Ländern Europas) ca. 1/3 der kleineren Wasserläufe verrohrt sind, sollte es bei OSM schon eine eindeutige Interpretation geben.
Aber das ist ein anderes Thema.
![http://commons.wikimedia.org/wiki/File%3AWienfluss_von_der_Schoenbrunner_Bruecke_Juni_2009.jpg[/url]](http://commons.wikimedia.org/wiki/File%3AWienfluss_von_der_Schoenbrunner_Bruecke_Juni_2009.jpg%5B/url%5D){kind=link}