[Talk-at] Grenzen

[Friedrich Volkmann]

On 27.05.2015 19:32, C K wrote:
> bei den is_in tags mit der Begründung "wir mappen nicht für die routing engine"

Die waren fürs Routing? Ich dachte, die waren als Hint für Suchfunktionen
gedacht?

Die is_in Tags haben den Nachteil, dass man sie auf so ziemlich alle Objekte
setzen müsste, die es in OSM überhaupt gibt, und das bläht nicht nur die
Datenbank gewaltig auf, sondern ist absolut unwartbar. Außerdem sind die
Bestandteile der is_in nicht definiert und somit gar nicht vernünftig
auswertbar, auch nicht für Router. Und last but not least enthalten die
is_in nur redundante Information, man kann sie in einer Anwendungsdatenbank
automatisch erzeugen, sie sind nicht in der zentralen OSM-Datenbank nötig.

Boundary-Multipolygone gibt es nicht so viele, hier sind weder Wartbarkeit
noch Platzbedarf ein Thema, und die Daten sind nicht ganz redundant.

>> > - warum sollen jetzt
>> > Daten so (unter Umständen entfremdet) gespeichert werden, damit sie der
>> > Renderer (besser) verarbeiten kann?
>>
>> Weil die Verarbeitung der einzige Zweck von Daten ist.
> 
> ist es dann nicht ein Fehler in der Verarbeitung bzw., in diesem konkreten
> Fall nicht unbedingt ein Fehler, eher eine Schwäche des Renderers. Die
> Argumentation, jeder "maßgeschneiderte" Renderer wird es richtig
> verarbeiten, nicht unbedingt mapnik, ist nachvollziehbar.

Kein Renderer kann Daten richtig verarbeiten, solang er sie nicht auf
standardisierte Weise zur Verfügung gestellt bekommt.

>> > Die Argumentation "damit man es im
>> > Renderer besser sehen/auseinanderhalten kann" ist daher für mich KEIN
>> > Entscheidungsgrund.
>>
>> Vielleicht weil du selber es nicht brauchst. Andere brauchen es.
> 
> Dann werden sie ihre speziellen Abfragen oder eigenen Renderer haben.

Sei mir nicht bös, aber wenn ich wissen will, in welcher Gemeinde etwas
liegt, will ich mir keinen eigenen Renderer schreiben müssen. Das ist eine
so grundlegende und alltägliche Anforderung, dass das mit der Standardkarte
gehen muss.

> Ich bleibe dabei, wenn der Grundsatz lautet: "wir mappen nicht für den
> Renderer" hat Gemeinde, Bezirk etc. nichts im Namen verloren.
> Für einen Renderer heißt das natürlich mehr Arbeit

Den Satz "wir mappen nicht für die Renderer" kann ich nicht mehr hören. Für
wen mappen wir denn? Für die Nutzer! Es bringt nichts sich auf die Renderer
auszureden, wenn die Nutzer den Schaden haben.

Viele Fundis unter den Mappern haben einen eingeschränkten Horizont, sie
sehen nur bis zur Datenbank, dort hört die Welt auf. Eine Datenbank steht
aber nur in der Mitte einer Toolchain, und wenn am Ende nichts rauskommt,
dann hat nicht nur der Renderer versagt, sondern das ganze System.

-- 
Friedrich K. Volkmann       http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria