[Talk-de] Unterscheidung (war Tiefenangabe alsName)

[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.

> 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)

> 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?

> 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)

> 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.

> 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?

> 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.

[...]

> > 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.

> 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!

> > 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