[Talk-de] api-download bei semikon-getrennten-values

[Wolfgang]

Hallo,
Am Freitag 15 Oktober 2010 13:32:06 schrieb NopMap:

> 
> Wenn sie beim Import pauschal ausmultipliziert werden, entstehen mehrere
> sich überlagernde Objekte, die insgesamt sinnlos sind, das Renderergebnis
> ist Zufall aber jedes für sich sieht korrekt aus. Den Fehler findet man nur
> noch unter größten Schwierigkeiten.

Ich glaube, man muss hier verschiedene Dinge trennen, die zu häufig in einen 
Topf geworfen werden und nagel hier mal 7 Thesen an die Listentür ( :-) )

1. In der real existierenden Welt gibt es Dinge, die nicht nur eine 
Eigenschaft einer Gruppe haben.

Als einfaches Beispiel für Farben mag das Zebra herhalten, als sinnvolle Tags 
für OSM sehe ich hier den Wirt, der tatsächlich Speisen mehrerer Küchen 
zubereitet, häufige Beispiele dafür cucina=greek;italian oder greek;turkish; 
und es gibt Haltestellen, an denen - für den Fahrgast praktisch, für den 
geplagten OSM-Renderer-Schreiber ärgerlich - mehr als eine Linie des ÖPNV 
halten.

2. Diese Dinge dürfen für OSM nicht einfach, weil es der Renderer so will, 
unter den Tisch fallen.

Es ist für mich nicht akzeptabel, dass der Mapper sagt, hier gibt es zwar 
griechische und italienische Gerichte, aber ich esse lieber griechisch, also 
tagge ich nur greek (oder umgekehrt).

3. Diese Dinge können auf verschiedene Weise verwaltet werden. 

Beim ÖPNV werden die Linien und ihre Haltestellen in eine Relation gepackt. 
Das vermeidet das Semikolon an der Haltestelle.

Sieht wie eine prima Lösung aus. Leider ergibt sich aber beim Rendern der 
Haltestelle das gleiche Problem wie bei jedem anderen Modell - die Haltestelle 
gehört zu mehreren Relationen , zu mehreren Linien, und bei dieser Auswertung 
tauchen - schwupp - die verschiedenen Liniennummern (Eigenschaften) wieder 
auf. Damit will ich nicht kritisieren, dass hier Relationen benutzt werden, 
das ist beim ÖPNV sinnvoll. Ich will nur aufzeigen, dass dadurch die Anhäufung 
von Eigenschaften nicht verhindert wird, da sie fatalerweise in der 
Wirklichkeit existiert.

Folgerichtig wäre es zwar möglich, auf das Semikolon bei Gaststätten zu 
verzichten, indem eine Relation aller griechischen, italienischen,... 
Restaurants erzeugt wird. Bei Auswertung der einzelnen Gaststätte hat der 
Renderer aber wieder das gleiche Problem - 2 oder noch mehr Relationen, weil 
der verd. Koch sich einfach nicht auf eine Küche festlegen will. Gewissermaßen 
kocht er damit OSM-widrig. Leider sind wir noch nicht mächtig genug, um diesem 
Treiben ein Ende zu setzen ( :-) ) (für den, der Ironie nicht erkennt).

Daraus folgt, dass die Relation das Problem nicht löst, sondern versteckt. 
Mehr noch - sie ruft die Relations-Kritiker auf den Plan, die zwar keine 
Alternative wie z.B. eine Kollektion anbieten, sich aber jede Sammel-Relation 
verbieten.

Was mach jetzt der verzweifelte Mapper, der die Küche korrekt taggen will, die 
Relation nicht darf, das Semikolon nicht soll und die doppelte Küche sieht? 
Macht er 2 Nodes, eine für jede Küche, worauf alle Auswertungen mit 2 
Restaurants reagieren? Oder verbindet er die 2 Nodes mit dem Gebäude in einer 
Site-Relation?. Das wäre ein gangbarer Weg, der aber nichts daran ändert, dass 
der Renderer vor dem Problem steht, wie er jetzt das darstellen soll. 
Abgesehen davon, dass dieses Tagging sachlich falsch wäre, schließlich wird 
nicht in 2 Küchen in einem Gebäude, sondern in einer Küche gekocht.

4. Das Problem liegt in den Scheuklappen vieler Aktiven.

Es ist letztlich egal, ob einer der heutigen Renderer eine Sache richtig 
darstellt. Ich wiederhole es nochmal: Wir taggen nicht für irgendeine 
Anwendung, sondern ausschließlich die Realität, und zwar so gut, wie es uns 
zur Zeit möglich ist. Das bedeutet nicht, dass man jetzt unbedingt 
cucina=kretian taggen muss, wenn der Wirt hauptsächlich Gerichte aus Kreta 
anbietet. Greek ist auch dafür sachlich richtig (gehört ja dazu) und für alle 
Anwendungen leichter auswertbar. Kretian ist andererseits aber auch nicht 
falsch - ein Ermessensfall, in dem ich Sympathie für die Bezeichnung greek 
hätte (abgesehen davon, dass ich die Unterschiede in verschiedenen 
griechischen Küchen einfach unterstelle, ohne sie zu kennen). In Bezug auf die 
deutsche Küche gilt ähnliches: bavarian, bremian, hamburgian, rhinian - 
Stopp!! Vielleicht für ein Subtag. Der Ausländer wird german taggen und 
Schweinebraten mit Ködel (und Sauerkraut!!) darunter verstehen.

5. OSM ist eine überholte Bezeichnung.

Das Projekt wurde von Steve Cost mal Openstreetmap getauft, weil er sich 
damals eine offene Straßenkarte vorstellte. Das hätte vermutlich jeder am 
Anfang so gesehen. Inzwischen ist das Projekt aber mutiert zu einer offenen 
Geodatensammlung. Es werden viele Dinge gemappt, die kein Renderer darstellt 
oder kein Renderer darstellen kann. Einkaufszentren in 3D zu mappen ist zur 
Zeit - betrachtet aus Sicht der Renderer - sinnfrei. Es ist aber 
nichtsdestotrotz sachlich richtig und wird auch gemacht.

6. Der Lizenzwechsel ist nur die logische Antwort auf die Wandlung des 
Projektes.

In Zukunft werden die grafischen Abbilder der Datenbank nicht mehr 
zwangsläufig frei sein. Sie können in der Nutzung beliebig beschränkt werden. 
Frei dagegen wird der Zugriff und die Auswertung der Daten sein. Das wird kaum 
bedeuten (können), dass Mapnik oder Osmarender jetzt für die Mapper 
kostenpflichtig werden, beide sind Opensource und damit jederzeit auf einem 
anderen Server wieder für alle einsetzbar. Aber es wird deutlich, dass der 
Zweck des Projektes eben nicht darin liegt, Karten zu erzeugen, sondern 
Geodaten zu ermitteln und frei zugängig zu machen.

(Konsequenter weise müsste das Projekt sich eigentlich umbenennen. Das würde 
ich aber nicht empfehlen, da der Name OSM gerade beginnt, ein wenig bekannter 
zu werden.)

Freie Zugängigkeit der Daten bedeutet nicht nur für die Erstellung von 
Landkarten. Eine weitere Auswertung ist das Routing, deren Vertreter ebenfalls 
häufig versuchen, ein ihnen angenehmes Tagging zu erreichen. Frei zugängig 
bedeutet aber auch die Auswertung in Statistiken, wissenschaftlichen 
Untersuchungen und vieles mehr. Gerade damit heben wir uns ab von den anderen 
geografischen Datensammlern, deren Augenmerk zur Zeit ausschließlich auf der 
wirtschaftlichen Erstellung von mehr oder weniger genauen Karten für den 
Massenmarkt (Verkauf) liegt.

Fangen wir aber jetzt an, den Renderern zuliebe die Wirklichkeit zu verbiegen, 
um ein "schönes" Bild zu erzeugen, machen wir uns selbst überflüssig. Wir sind 
dann nicht besser als der Hersteller dieser grauenhaft fehlerhaften Karten für 
Google.

7. Es bleibt die Diskussion über das Semikolon. 

Mich hat die Implementation 5 Minuten und 3 Programmzeilen gekostet. Das ist 
zugegebenermaßen nicht ganz fair. da die App neu ist. Wer eine bessere 
Möglichkeit weiß, multiple Eigenschaften in den Daten so abzubilden, dass es 
für den Mapper einfach anzuwenden ist, melde sich bitte. Aber nicht mit dem 
üblichen Semikolon - Protest - Geheul, sondern konstruktiv.

Das einfache Verbieten oder Ignorieren von Dingen, die es real gibt, nur weil 
es sich zur Zeit (oder nie) von einem Renderer darstellen lässt, widerspricht 
jedem Grundsatz von OSM und ist für mich nicht akzeptabel.

Vielen Dank denen, die bis hier gelesen haben.

Gruß, Wolfgang

ps. Nop: Das geht nicht gegen dich. Ich habe hier einfach auf das (bei mir) 
letzte Posting geantwortet. Ich meine aber, diese Meinung passt in diesen 
Thread. 

lg, d.o.