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
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de