[Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)

Do Feb 3 23:28:48 UTC 2011

Ich verstehe jetzt bei dieser Relevanz/Grundsatz-Diskussion beide
"Seiten" nicht ganz, weil sich drüben im Thread "Koennen wir die
TMC-Daten rauswerfen?" ja eine Lösung (Frederik nannte es
"Kompromiss") abzeichnete.

Am 3. Februar 2011 16:10 antwortete Frederik:
> Hallo,
>
> On 02/03/2011 02:59 PM, Sven Anders wrote:
>>
>> Du vermutest Probleme, wenn jemand eine Schema ändert etc. aber bislang
>> sagst du nicht ich will das und das ändern und das beißt sich mit TMC.
>
> Ich moechte, dass OSM nach Moeglichkeit auch weiterhin ohne Fuehrerschein
> "bedienbar" ist. Dass man sich ein bisschen reinfuchsen muss in die Art, wie
> OSM tickt - was sind Tags, was sind Ways usw., laesst sich nicht vermeiden.
> Aber dass man sich dazu noch - je nachdem, was man gerade editiert - in
> verschiedene "Fachdatenwelten" hineinfuchsen muss, dass missfaellt mir.
...
> Ich mag auch einige andere Sachen nicht, es gibt z.B. eine ganze Anzahl von
> Relationen nach dem neuen OePNV-Schema, an denen gross eine Warnung dran
> steht "Bitte nicht aendern, bevor Du nicht die Seite XYZ gelesen hast".

Dann fällt also das OePNV-Schema als Beispiel in
http://wiki.openstreetmap.org/wiki/DE:Nutzung_von_OSM_durch_FIS weg?

Ich habe übrigens manchmal den Eindruck, dass viele Mapper
grundsätzlich nicht gerne lesen (insbesondere Wiki-Seiten) :->

> Ein bisschen muss TMC hier als Stellvertreter fuer viele andere aehnliche
> Situationen herhalten, die noch kommen werden - aber, auch das wurde gesagt,
> Marcus hatte ja angeblich mit dem TMC-Import auch vor, in gewisser Weise
> "richtungsweisend" zu sein. Und da muss ich sagen, in *diese* Richtung -
> naemlich mehr und mehr unverstaendliche Spezialtags, die dem Mapper jede
> Sicherheit rauben - moechte ich nur sehr ungern gehen. Ich habe die ernste
> Befuerchtung, dass das unserem Projekt die "Basisdemokratie" raubt, dieses
> "jeder kann ganz einfach mitmachen". Das finde ich aber elementar wichtig.

Da das scheint mir auch wichtig.

>> Es wäre doch toll, wenn alle nur noch OSM benutzen, wenn z.B. die
>> Telekom an jeder Telefonzelle gleich erfassen würde, ob diese gerade
>> geht, oder defekt ist, wäre das doch ein Vorteil für alle die OSM Daten
>> benutzen.
>
> Nein, das sehe ich ganz anders, zumindest ist unsere Technologie fuer sowas
> nicht ausgelegt - dann muessten wir viel mehr filtern koennen und z.B.
> dafuer sorgen koennen, dass ein Tileserver nicht saemtliche
> Telefonzellen-Stoerungsmeldungen gefuettert bekommt und so weiter.

Hier muss ich Sven zustimmen: OSM soll weiterhin Platz bieten aktuelle
Informationen (= aktuell verglichen mit dem maximal
Halbjahres-Rhythmus "offizieller" Geodatenquellen). Ich möchte da
nochmals aufs Beispiel Haiti hinweisen mit den Strassen, die von einem
Tag auf den andern unpassierbar waren.

Ein interessanter Hinweis steckt in der Antwort oben: Der
Hauptrenderer soll tatsächlich möglichst wenig Ballast erhalten.

=> Kann dies nicht geregelt (oder einfach implementiert und
kommuiziert) werden, indem Präfix-Tags *nicht* per default
weiterverarbeitet werden - insbesondere nicht zum Hauptrenderer?

Um auf TMC zurückzukommen: TMC (Traffic Message Channel) ist
bekanntlich ein Staumeldesystem für Verkehrsradio, dann v.a. für
(Auto-)Navis. TMC ist keine Nischeninformation, bzw. genauso eine wie
viele andere. TMC ist höchstens ev. ein Fachinformationssystem (FIS)
mit zu kurzlebigen Daten. Wenn wir ein TMC-Schema finden, dass etwas
allgemeinverständlicher ist, können alle "mitreden". Ich sehe hier -
wie auch bei Vogelhäuschen und Fahrstühlen - eine wichtige Frage, die
sich sowohl FIS-Macher wie auch OSM-Gralshüter stellen müssen: Es muss
möglich sein, dass jedermann (natürlich möglichst korrekte) FIS-Daten
erfassen kann.

Für mich ist wünschenswert, dass (jeder-)mann Baustellen,
Vogelhäuschen und Fahrstuhl-Zustände mappen kann. Aber für Daten, die
"flüchtiger" als weniger als eine Stunde hat OSM vorläufig wohl (noch)
keine Ressourcen.

Daher meine Gretchenfrage an die TMC-Befürworter:
=> "Dürfen" alle - auch wir Nicht-Bots (:->) - TMC-Daten erfassen und verändern?
=> Wie "flüchtig" sind TMC-in-OSM-Daten?

Und an alle: Wie "flüchtig" dürfen OSM-Daten sein? Eine Woche? Ein
Tag? Zwei Stunden?

LG, S.

Am 3. Februar 2011 19:46 schrieb Frederik Ramm <frederik at remote.org>:
> Hallo,
>
> Sven Anders wrote:
>>
>> Ich erinnere mich an eine Diskussion mit Sven Sommerkamp, der mir
>> verbieten wollte straßenbegleitende Radwege in OSM als extra Way anzulegen,
>> weil ansonsten sein Garmin nicht mehr in Hamburg routen konnte[1]. Das kann
>> doch kein ernst zu nehmendes Argument sein. Ich will jetzt nicht die
>> Dikssion über straßenbegleitende Radwege weider aufwecken. Ich finde die
>> Diskussion hat ähnlichen Character.
>
> Ich finde, es geht um etwas grundsaetzlich verschiedenes.
>
>> Die Wheelmap-Leute haben einen echten Mehrwert, wenn sie wissen, ob ein
>> Fahrstuhl funktioniert, okay ist nicht die Telefonzelle, aber genau so eine
>> Information. Mache Fahrstühle gehen in Hamburg über 6 Monate nicht. Da ist
>> dann überhaupt die Frage ob man den Fahrstuhl nicht löschen sollte.
>
> Im Idealfall gibt es eine externe Datenbank mit Informationen zu
> Fahrstuehlen - z.B. vom Fahrstuhlbetreiber -, der man entnehmen kann, ob ein
> Fahrstuhl gerade geht oder nicht, wann die naechste Wartung geplant ist,
> welches die Notfallrufnummer fuer diesen Fahrstuhl ist und so weiter. Haben
> wir vielleicht heute noch nicht, aber "Open Government" ist in aller Munde,
> und solche Sachen wird es mehr und mehr geben.
>
> Dann wuensche ich mir eine halbwegs verlaessliche Art - unter Umstaenden mit
> einem Tag, der auf die Aufzug-ID in der betr. Datenbank verweist -, wie man
> OSM-Daten und die nicht-OSM-Welt verknuepfen kann.
>
> Dass man solche Daten *in* OSM direkt erfasst, das kann man als Notloesung
> machen, solange es noch keine solche frei zugaengliche Aufzugsdatenbank
> gibt.
>
> Du aber hoerst Dich gerade so an, als ob Du selbst dann, wenn eine solche
> Datenbank verfuegbar waere, lieber einen Bot schriebest, der einmal pro
> Stunde den Aufzugsstatus aus der Datenbank abfragt und ihn in OSM
> aktualisiert - nach dem Motto "ist doch praktisch".
>
> OSM kann und will aber nicht der Sammelpott fuer alle irgendwo frei
> erhaeltlichen Daten sein - dafuer gibt es einfach zu viel davon, und ich bin
> bei weitem nicht der einzige, der jede Art von Import kritisch beaeugt.
>
>>> Ich
>>> sehe generell mit Besorgnis, was Leute alles in OSM stopfen moechten -
>>> meistens aus Faulheit oder Inkompetenz: Ich habe hier diesen Datensatz
>>> mit Vogelbeobachtungen, aber weil ich nicht in der Lage bin, eine Karte
>>> zu rendern, auf der diese Vogelbeobachtungen ueber einen OSM-Hintergrund
>>> eingezeichnet werden, will ich lieber die Vogelbeobachtungen zu OSM
>>> hochladen, dann kann ich das komfortabel in meinem Renderer einstellen.
>>
>> Und jeder kann eigene Vorgelbeobachtungen hinzufügen und man kann es
>> gemeinsam auswerten. Ist doch prima. Ich finde daran erstmal nichts
>> inkompetent. Und Faulheit ist doch auch gut, ich bin gerne Faul.
>
> Es gibt freie Datensaetze aller Art, z.B. mit Temperaturentwicklungen oder
> so, die ganz OSM vom Datenvolumen her locker in den Schatten stellen. Wenn
> Du moechtest, starte ich mal ein kleines historisches Wetterprojekt in
> Hamburg, und weil ich gerne faul bin und es zugleich doch spitze ist, wenn
> andere auch an diese Wetterdaten herankommen, lade ich die gleich zu OSM
> hoch. Jeder Download, den Du von da an in Hamburg machst, ist 4x so gross
> wie vorher, die Tiles rendern gar nicht mehr und im Editor siehst Du nur
> noch Wettermesspunkte ;) also im Ernst, da muss man schon ein bisschen auf
> dem Boden bleiben, und sowas muss ganz klar extern mit OSM verknuepft statt
> in OSM hineingekippt werden.
>
> Wir fuehren normalerweise keine Relevanzdiskussion, weil die meisten von uns
> sich einig sind, dass alles, was Menschen vor Ort selber mappen, auch einen
> Platz in OSM hat. Auch das Vogelhaeuschen. Das koennen wir uns leisten - ein
> einzelner Mensch kann nur eine begrenzte Menge an Unsinn selber mappen, also
> brauchen wir uns nicht um die Definition zu pruegeln, was Unsinn ist und was
> nicht. Aber das heisst nicht, dass wir jedem erlauben koennen, alles zu
> importieren - denn da kann man mehr Unsinn machen.
>
> (Konkret an den TMC-Tags hat mich aber nicht die Menge an sich gestoert,
> sondern, dass sie die Huerde fuer Mapper m.E. unnoetig erhoehen, wie ich
> hoffe, im vorigen Posting dargelegt zu haben.)
>
>> Ich hab gerade den Eindruck das du dich zuviel um Tileserver/OSM
>> verarbeitende Jobs kümmerst und deshalb dich das Ansteigen der OSM-Daten
>> nervt
>
> Nein; wenn das mein Grund gewesen waere, dann haette ich das auch gesagt und
> nicht irgendwelche Ausreden erfunden. 175000 TMC-Tags - das sind insgesamt
> *halb so viele*, wie der OSM-Datenbank jeden Tag neu hinzugefuegt werden.
> Wenn ich jetzt alle TMC-Tags loesche, dann ist die Datenmenge nach 12
> Stunden wieder so gross wie davor.
>
> Mein Hauptproblem mit TMC ist, dass ich diese Daten als "invasiv" empfinde;
> sie behindern in meinen Augen die Arbeit mit den Kerndaten. Das ist was
> andres als wenn jemand einen Hundekottuetenspender irgendwo hinmappt, finde
> ich.
>
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>