> Irgend jemand hat hier mal sinngemaess geschrieben: Es sind nur Bits und > Bytes in einer Datenbank. An dieses Prinzip versuche ich mich so
> gut es geht zu halten (gelingt eh nicht immer). Eine normale DB ist im Endeffekt echt nur eine Sammlung von digitalen Daten, und *kann* als irgendein Modell dargestellt werden, muss aber nicht. Die OSM, als GEOgraphischeDatenBank ist da anders. Du wirst die Datenstruktur der OSM nicht als (Binär)baum oder als Zeitdiagramm beschreiben können, aber auch wirst du nicht drum rum kommen, für die einzelnen Datensätze eine Projektion auf eine Karte anzunehmen. Die Datenbank hat eine festgelegte Sprache (die Tags/Positionen) und die sind darauf ausgelegt, dass im Endeffekt die Daten(auswertung) auf einem geographisch festlegbaren Ort sind. Insofern ist die OSM-DB Bits und Bytes mit Position auf einer Karte. Man soll natürlich nicht für einen gewissen Render mappen, aber stell dir vor, wir hätten Zugang zu einem nicht geografischen Editor, und laden ein Changeset ohne Ort hoch. Das wäre dann aufgrund der Sprache ein Syntax oder Semantikerror. Insofern ist die Datenbank nur als Karte in einer Projektion gebrauchbar. Das Mappen ohne diesen Aspekt im Hinterkopf zu haben geht einfach nicht. Aber wenn ich grad am Schreiben bin noch was zur Diskussion: Sprachen verändern sich. HTTP 2.0 statt 1.1, HTML 5.0, auch deutsch kam seit althochdeutsch einen langen Weg, über "Ich saz ûf eime Steine" zu "Hearst, oida!". Und genau so werden die Tags in der OSM sich lexikalisch, und semantisch auch immer wieder verändern. Und wenn es einen Tag gibt, der genauer Spezifiziert wird/werden soll, als ein anderer, der genau, oder eben ungenau das selbe aussagt, dann ist es naheliegend, den ungenaueren nicht mehr zu verwenden. Und gleich ein Kommentar zum DB-Spring-Cleaning nach Topf: Da ich mich selbst darüber noch nicht informiert habe, hab ich keine gebildete Meinung dazu, aber meine ungebildete Meinung ist: Gut, dass da wer mal nicht nur sagt, dass da was passieren muss, sondern das gleich, mit offenbar viel Unterstützung, auch macht. Ich weiß ja nicht wie das ankommen würde, aber wenn man dem OSM-Server ein Script geben würde, das nicht ganz korrekte Changes (MultiPolygone) ohne outer Rollen, Kaffeehäuser und Kebabstandeln in Öffirelationen, Ways die sowohl oneway=yes als auch lanes:backward (ohne Erwähnung von psv/bicycle/Ausnahmen) haben, usw. einfach ablehnt. Also einen Filter einbauen. Da die Sprache im Zusammenhang genau definierbar ist, wäre das sicher eine Variante gegen einige Fehler. Sowohl von Anfängern, als auch verwirrten oder dem Tagging nicht zu 100% zugeneigten Mapmeistern. Neue Tags wären noch erlaubt, aber sobald sie angenommen wurden (in der Wiki), und eine fixe Definition haben, kommen sie so in den Filter. Würde zwar gegen das KISS-Prinzip gehen, dass man bei Webservern verfolgt, aber würde der Qualität zur Gute kommen. Auch könnten/sollten manche Prozesse (auch wenn das hier nicht gern gehört wird) automatisiert werden. Tippfehler in Tags etwa, sollte alle paar Monate eine Routine ausbessern. Nur in dem Skope: Da es vermutlich nie einen Tag namens emegency oder einen Wert namens fire_hidrant geben wird. Auch solche sachen wie power=substation und power=sub_station.Ist das selbe, nur einmal falsch. Für sowas wären Automatismen nicht schlecht. Meiner Ansicht nach. Mit freundlichen Grüßen Robin Däneke (emergency99) PS: Will jemand meine 4 anderen Vornamen auch noch haben, mit Passkopie, Studentenausweiß und Name der Nachbarskatze? [😃] Sorry, musste sein. Danke für so einige Popcorn-reife Momente in der Liste.
_______________________________________________ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
