[Talk-de] Konzept für Daten, Karte und Renderer

Peter Wendorff wendorff at uni-paderborn.de
Sa Mai 28 07:33:41 UTC 2011


Am 27.05.2011 19:46, schrieb Heiko Jacobs:
> Am 27.05.2011 14:07, schrieb Peter Wendorff:
>> Am 27.05.2011 12:20, schrieb Markus:
>>> Ich könnte mir das so vorstellen:
>>>
>>> Mapper > E-Verarbeitungsschicht > DB > ...
>> Da hast du mich falsch verstanden!
>> Ich bin für Mapper > DB > ...
>
>>> Die Daten des Mappers (1)
>>>
>>> werden von einem intelligenten Editor entgegengenommen
> >> und vorverarbeitet und in die Eingangs-Verarbeitungsschicht 
> gespeichert (2).
>> so intelligent kann die Schicht nicht sein, dass dadurch keine
>> Informationen verloren gehen.
>> Außerdem ist einiges in dem Bereich nicht sinnvollerweise
>> bei jedem Upload durchzuführen.
>
> Ich wäre auch vorsichtig, allzu viel in die E-Schicht zu packen.
> Eins jedoch sollten Editoren -- oder wenn die es nicht machen --
> die Eingangschicht der DB machen:
> Splits und Vereinigungen erkennen und eine saubere Historie
> auch für diese erzeugen. Das ist nicht nur DER Knackpunkt
> der Relizenzierung (ohne saubere Historie auch bei Splits
> und Vereinigungen ist die rechtlich angreifbar), sondern
> auch ganz generell lästig, wenn man die Entstehungsgeschichte
> eines Objekts verfolgen möchte, wann und von wem und warum bspw.
> Tag X drangehängt wurde an die Y-Straße ...
+10!
Ja, ganz klar - das fehlt bisher in API und Editoren völlig.

Allerdings hilft das auch nur zum Teil: Bei der Beobachtung mancher 
Mapper (und etlicher Changesets) ist mir aufgefallen, dass oft eben 
nicht gelöscht + neu angelegt wird, sondern mal eben wiederverwendet, 
verschoben und "umgewidmet" wird.
Da soll eine Wiese gelöscht und ein Gebäude hinzugefügt werden - dann 
nimmt man den way der Wiese, arrangiert die Nodes des way neu und 
vergibt neue Tags - das kann beim besten Willen kein Editor als neues 
Objekt erkennen.

Gruß
Peter




Mehr Informationen über die Mailingliste Talk-de