[Talk-at] Ankündigung der Entfernung von landuse =farm im Standardstil

Mon Apr 3 10:27:40 UTC 2017

Ich habe Deinen Text angestrengt gelesen und nicht ganz verstanden was Du sagen willst.

Ich gehe davon aus, dass es anderen mit meinen Zeilen auch so passiert sein koennte. Also zur Klarstellung: Ich wollte mit den Bits und Bytes sagen, dass man sich manches nicht zu sehr zu Herzen nehmen soll. Auch mir wurden schon von mir surveyte Daten "ausgebessert". Und da hilft mir der Satz dann einfach gelassener zu bleiben.

Wie mit der Privatsphaere von Menschen umzugehen ist, ist sogar in der oester. Verfassung festgelegt. Aber jeder darf fuer sich selber entscheiden. Ich halte es fuer wirklich falsch, respektiere aber, dass Du gerne Deine Ausweise jedermann zur Verfuegung stellen willst. Unangenehm empfinde ich, wenn jemand dritter salopp darum bittet, seine Anonymitaet aufzugeben. Das finde ich nicht richtig.

In 10 Jahren wird man Deinen Aufsatz hier auch noch lesen koennen (mit Realnamen - vorausgesetzt er ist es) vielleicht hast Du Dich bis dahin ja in irgend einer Form veraendert. Sowie das von Dir beschriebene HTML. Bei mir wird das sicher so sein, und ich werde froh sein, dass nicht jeder meiner Erguesse, mit meinem echten Namen unterschrieben, zu lesen sein wird.

> Gesendet: Montag, 03. April 2017 um 11:47 Uhr
> Von: "Robin Däneke" <robin.daeneke at live.at>
> An: "OpenStreetMap AT" <talk-at at openstreetmap.org>
> Betreff: Re: [Talk-at] Ankündigung der Entfernung von landuse =farm im Standardstil
>
> > 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>