[Talk-de] Unterscheidung (war Tiefenangabe alsName)

[Christian Wagner]

Am Samstag, den 21.08.2010, 03:47 +0200 schrieb Olaf Hannemann:
> Hallo Christian,
> 
> [...]
> 
> > > Das ist genau das was FT macht, wenn aus der privaten Datenbank
> > > gearbeitet wird und das laden in die OSM Daten Bank nur Alibi-Funktion
> > > hat. Denn sagt ja selbst: "Es wird entschieden was zu OSM geschickt
> > > wird."
> > 
> > Das Datenmodell das FT verwendet ist immerhin im Wiki als proposal zur
> > Diskussion gestellt worden und ist so wie es aussieht auch
> > mehrheitsfähig. Klar taggen wir irgendwann für den Renderer (keiner
> > würde statt highway=motorway ...=Autobahn schreiben)- wir wollen ja
> > auch irgendwann Mal eine Karte gerendert haben.
> 
> Und genau da ist ein Punkt, der mich damals enorm geärgert hat und eine 
> weitere Zusammenarbeit unmöglich gemacht hat. Um bei deinem highway Beispiel 
> zu bleiben:
> Es wurde über nacht das vorher gemeinsam genutze Modell seitens FT 
> angezweifelt und ein eigenes Datenmodell inclusive Proposal geschaffen. Kurz 
> darauf wurden alle highway=motorway Schlüssel in highway=street + 
> street=motorway umgewandelt. Keine Diskussion möglich.
> Anyway, das ist Schnee von gestern. Die Frage ist wie können wir jetzt mit der 
> Situation am besten umgehen.
> 
Ich habe die Diskussion damals nur unvollständig verfolgen können, da
ich erst später darauf aufmerksam wurde. Aber Du hast recht- das ist
Schnee von gestern. Wichtig ist wie wir von der aktuellen Situation aus
weitermachen.

> > Allerdings ist das, was
> > du da FT vorwirfst auch bei OSeaM der Fall. Da wurde der community
> > nicht nur der Renderer gebaut (dafür übrigens herzliche Dank- ganz
> > ehrlich), sondern auch gleich noch ein unvollständig/schlecht
> > dokumentiertes Tagingschema vor den Latz geknallt welches vom gemeinen
> > Mapper nicht mehr ohne OSeaM Editoren zu bewältigen ist. Einfach Mal in
> > Potlach eine Backbordboje mit Topzeichen reinzuhacken geht de facto
> > nicht mit eurem Tagingschema- dafür ist es einfach zu kompliziert.
> 
> seamark:type = buoy_lateral
> + seamark:buoy_lateral:category=starboard
> + seamark:topmark:colour=green (bzw red für IALA B)

Ist schon klar, allerdings ist ein

seamark=buoy
buoy=lateral_starboard
topmark=yes
color=green (falls IALA auf diese weise implementiert wird/ist)

IHMO kürzer, einfacher und von einem normalen Menschen irgendwie
machbarer. Die erste Zeile ist sogar redundant, aber vielleicht als
Signal für den Renderer gar nicht so verkehrt (sowas hat OSeaM ja auch
indem es vor jeden Tag seamark schreibt). Ich finde es eleganter- aber
seis drum- meine Meinung ist hier nicht wirklich maßgeblich. Welches
Tagingschema sich durchsetzt wird über die nächsten Jahre entschieden.

> > Schon allein die dauernde Redundanz der einzelnen tags und values (z.
> > B.seamark:buoy_lateral:colour_pattern=...) ist komplett am Bedarf eurer
> > Datenlieferanten- den Mappern- vorbei entwickelt.
> 
> Und wie möchtest du deutlich machen, dass "colour_pattern" sich auf den 
> Tonnenkörper und nicht auf das Topzeichen usw. bezieht?

Kenne jetzt kein Topzeichen mit color pattern. Du hattest ja auch Mal
geschrieben dass Ihr die Bedeutung der Seezeichen mappt, und nicht etwa
was sich wirklich dort wirklich befindet (also z. B. ein rotes
Topzeichen das wegen Möwenschiss weiss gesprenkelt ist). Somit ist dann
eigentlich klar dass sich color pattern auf den Seezeichenkörper
bezieht.

> 
> > Das ganze führt dann dazu daß Ihr z. B. bei Rügen eine Seekarte
> > anbietet die nur einen Bruchteil der vorhandenen Daten zeigt- was daran
> > jetzt qualitativ besser sein soll ist mir ehrlich gesagt schleierhaft.
> 
> Da in den Diskussionen immer wieder das Argument der meisten Schlüssel fällt, 
> möchte ich zur Zeit nicht automatisiert zu allen Seezeichen das OpenSeaMap 
> Schema hinzufügen. Dann hätten wir nämlich ein Unentschieden. Es reicht doch, 
> dass im Augenblick wieder massenhaft Schlüssel von einem einzigen User an die 
> bestehenden Knoten herangehängt werden. (siehe z.B. Changeset 5537834, 
> 5537760, 5530183)
> 
Das ist genau das Doppeltaging das ich die ganze Zeit "anprangere" und
im Prinzip eine Folge der Auswertung der Daten (rendern, Konvertierung
in Garminformate etc.) ist. Wenn alle die beiden, aktuell leider
existierenden Schemata, auswerten würden, dann wäre der Drang doppelt zu
tagen sicherlich geringer (ob das bei CBM aktuell der Grund ist sei
dahingestellt...). Wie gesagt, welches Schema sich durchsetzt wir nicht
nächste Woche entschieden (von wem denn), sondern wenn dann über die
nächsten Jahre. Jetzt da per Hand Fakten schaffen zu wollen ist
sicherlich nicht sinnvoll.

Wie schon in einem anderen post verlinkt, die Daten zwischen Rügen und
Hiddensee sind ja prinzipiell vorhanden, werden von OSeaM aber leider
nicht gerendert. Warum soll sich jetzt da einer drüber machen und node
für node nochmal redundante tags drüberlegen.

> > Im Prinzip habe ich euch da schon mehrfach drauf angesprochen, aber
> > eure ständige Weigerung die Seezeichen die nach dem proposal im wiki
> > getaggt sind zu rendern führt dann eben zu diesem Dilemma daß vieles
> > doppelt getagt ist.  
> 
> Wenn alles super funktionieren würde, könnte ich die Seezeichen die nach dem 
> proposal getaggt sind rendern und bräuchte kein "eigenes" Schema. ;-) Leider 
> habe ich mit dem proposal 2 bis 3 Probleme und da diese nicht verhandelbar 
> sind, muss ich etwas "eigenes" benutzen. Ich bin auch gerne bereit auf einer 
> größeren Ebene über diese Probleme zu diskutieren. Da ich zur Zeit leider nur 
> sehr wenig Zeit habe, werde ich anfang der Woche zu diesem Thema einen extra 
> Thread auf machen. Bitte habt bis dahin Geduld. Ich finde es wirklich blöd 
> eine Diskussion anzufangen und dann nicht mehr zu antworten.
> 
Erzähl doch Mal was dich aktuell am proposal stört.

> > Was an
> > diesem Kompromiss gut sein soll ist mir schleierhaft. Mir als Mapper
> > vergällt es die Sache ungemein da ich doppelte Arbeit habe. Einmal bei
> > der Dateneingabe und dann natürlich bei der Datenpflege. Langfristig
> > kommt da nur ein Kudelmuddel raus.
> 
> Du solltest dich einmalig für eins der beiden Systeme entscheiden und dann 
> nach diesem Schema arbeiten. KDE oder Gnome?

Das ist genau das was ich nicht kann- beide Projekte haben Vor- und
Nachteile, bzw. sind was die Nutzung der Daten angeht unterschiedlich
aufgestellt. 
Konkret: 
Die Garminkarte der Ostsee vom Januar z. B. ist traumhaft. Mittlerweile
leider veraltet (ich weis- kommt bald wieder eine Aktualisierung) und
leider stellt sie auch nur die Hälfte der damals vorhandenen Seezeichen
dar- FT Daten wurden eben nicht mitkonvertiert. Schade eigentlich- denn
vorhanden waren die Daten ja. Bei FT finde ich den Datenreichtum toll.
Insgesamt werden mehr Seezeichen erfasst (beacon white light z.B.). Und
auch bei FT ist eine Menge an Möglichkeiten zur Nutzung der Daten
vorhanden.

> > Wenn schon von OSeaM Seite gefordert wird daß nicht
> > für den renderer getaggt werden soll, dann muß sich eben der Renderer
> > anpassen. Das kann man sehr gut an der Evolution von der Standard-
> > Mapnik Darstellung über die Jahre erkennen- ständig kamen neue
> > gerenderte Objekte hinzu und es wurden neue Renderregeln geschaffen die
> > sich der Evolution der jeweiligen Taggingschemata anpassten.
> 
> Siehe oben.
> 
> > Letztendlich wird OSeaM, ganz OSM untypisch, zu etwas "Proprietärem"
> > was nur mit den OSeaM Bordwerkzeugen bearbeitet werden kann.
> 
> Sehe ich anders. OpenSeaMap benutzt ein nachlesbares Schema. Dies ist nicht 
> komplizierter als das proposal. Nur der Namensraum seamark:* ist etwas 
> gewöhnungsbedürftig, aber durchaus sinnvoll.
> 
Auch siehe oben;).
> [...]
> 
> > > Was ist daran eine Diskriminierung? Die FT Daten sind immer so
> > > geblieben wie sie waren. Es kamen nur neue dazu, die auch manchmal
> > > Fehler hatten. Wo Menschen arbeiten gibt es nun einmal Fehler. Ich
> > > denke eine Koexistenz von den Seekartensystemen wird es nur geben wenn
> > > jeder sein taggingschema selbst   bestimmen darf.
> > 
> > Die Diskriminierung liegt darin, dass, wenn Ihr das Tagingschema aus
> > Proposal nicht rendert, es seltener benutzt wird. 
> 
> Ist doch egal, im laufe des Tages hängt cbm die tags schon an den Knoten.
> Übrigens, wenn es ansonsten selten benutzt wird, will auch dies etwas sagen.
> 
Das mit dem selten benutzt sehe ich anders- ohne nun aber genaue Daten
zu haben...

> > Damit setzt Ihr euch
> > über einige OSM- Gepflogenheiten hinweg. Parallelen zu einem
> > "Microsoftmäßigen lock- in" drängen sich mir da auf. Verboten ist das
> > zwar bei OSM nicht, lässt aber einiges an Höflichkeit gegenüber der
> > community vermissen. Ihr wisst schon- ohne Daten keine Karte oder?
> 
> Vom Prinzip her siehe oben. Zusätzlich sei gesagt, dass ich eine nicht 
> öffentliche Datenbank, die lediglich node-ids mit icon-ids verknüpft und 
> selber entscheidet wann was wie nach aussen geht, nicht als das beste 
> Gegenbeispiel akzeptieren kann.
> Alles was wir machen ist öffentlich zugänglich und enthält keinerlei Vendor-
> Lock-in. Immerhin kommen ungefähr die Hälfte aller Edits über Josm oder 
> Potlach.



> > >  >Dabei sind ausreichend Fehler gemacht worden,
> > >  >
> > > > die die ursprünglichen Daten für den uneingeweihten unbrauchbar machen,
> > > > da jetzt widersprüchliche Informationen enthalten sind. Da ich selbst
> > > > einen signifikanten Teil der Zeichen auf meinen Bootstouren der
> > > > letzten vier Jahre erfaßt habe, kann ich das wirklich gut einschätzen.
> > > 
> > > Und du konntest auch nicht verhindern das die fehlerhaften
> > > Eintragungen, wir Rote Tonne oder Gelbe Tonne, im "Namen:" gab.
> > 
> > Seit wann ist denn der Datenverwerter (OSeaM, FT, Reit- und
> > Wanderkarte, Cloudmade etc.) für den Inhalt verantwortlich in einem
> > Wikiprojekt? Ich schließe mich hier einem der Vorredner an- Rendert
> > erstmal, die Jungs die dann die Fehler ausmerzen werden schon kommen-
> > nur Geduld. Willkommen im Wiki.
> 
> Was nützt es uns, wenn die Fehler am nächsten Tag aus einer nicht öffentlichen 
> Datenbank wieder zurück geschrieben werden?
> Willkommen im wirklichen Leben!

Das geht natürlich nicht. Wenn ein user Daten über z. B. JOSM ändert,
weil er einen Fehler korrigiert, dann muß das umgekehrt laufen- die FT
Datenbank muß sich ändern. Ist sowas in letzter Zeit denn noch
vorgekommen?

> 
> > > Da gebe ich dir recht. Das Beste M.e. ist wir setzen uns zu einem
> > > kleinen Rundentisch zusammen und versuchen dafür eine Lösung zu finden
> > > und geben dann die Ergebnisse bekannt. Bis dahin...
> > 
> > Wie die Vorredner schon gesagt haben- der runde Tisch ist hier...
> 
> Der runde Tisch muss ersteinmal klären wer was wie und warum schreibt. Erst 
> wenn wir uns sicher sind, dass wir uns nicht mehr gegenseitig die Arbeit 
> kaputt machen, können wir das eigentliche Problem angehen.
> 
> 
> Beste Grüße
> 
> Olaf

Ebenfalls beste Grüße, Christian