Christoph Eckert schrieb:
> Heiko hat seine Finger in die Brücke gesteckt, und dabei - zumindest aus
> seiner Sicht - eine Verbesserung vorgenommen.
Genau! Vieeeel besser nun! *flöt* ;-)
> Auch wenn wir jetzt darum
> streiten, finde ich seine Vorgehensweise richtig. Denn auf eine Änderung, die
> andere dann für nicht so gelungen halten, kommen 99 andere, die zu einer
> Verbesserung führen. Das ist IMO wesentlich besser als 5 vorher umständlich
> abgestimmte Änderungen.
Im 99%-Normalfall ja.
>> Dinge lange abzustimmen kann dann, wenn etwas einen hohen Grad der
>> Entwicklung erreicht hat sehr sinnvoll sein!
>
> Die Karlsruher Rheinbrücke war mitnichten hoch entwickelt :) .
Jetzt weiß ich endlich, warum die auf die Idee kommen, unbedingt eine
zweite daneben bauen zu wollen:
Sie haben in OSM gesehen, wie baufällig die wohl sein muss! ;-)
Zur Ausgangsfrage des threads "Topologie oder StVO":
Je nachdem, wie man die "Topologie" definiert, ob man da eher
zum gemeinsamen "Gesamtstraßenkunstwerk" oder zur "Straßenatomisierung"
neigt, ist die Topologie je nach Standpunkt nun besser oder schlechter.
Letztlich gehört beides in die Daten.
Zur Nebenfrage in diesem thread "Aenderungen erschweren":
Es gibt potentielle Daten mit hoher Qualität, wie z.B. importierte
Grenzen, oder Daten, wo es auf korrekte Geometrie ankommt, wie
Seezeichen, wo wir es auch schon mal von diesem Thema hatten.
Diese Daten könnten die Geometrie doppelt bekommen:
Das normale, für alle veränderbare lat und lon, und mind.
3 weitere tags
auth-lon, auth-lat und auth-id
Die API dürfte auth-* nur lesend rausgeben, nicht schreibbar oder
endgültig löschbar machen im Normalfall.
auth-id verweist auf einen Datensatz, indem Hintergrundinfos liegen
wie der Grund, warum hier autentifizierte Daten vorhanden sind (auth-desc
oder so), was bei der von Frederik vorgeschlagenen Warnung eingeblendet
wird (auth-warn:de etc.), wer die Daten angelegt hat (auth-creator),
wer bei Änderungen benachrichtigt wird (auth-users) und wer die
auth-Daten verändern darf (auth-authors).
Für Grenzen bräuchte es wohl auch noch was für die Verwaltung der
Integrität der ways und Relationen. Im Zweifel ist der Datensatz
mit der auth-id eine spezielle Relation, in der auch noch die ways
und Relationen mit drin sind.
Wege sollten noch mit rein wegen möglicher Veränderungen, neben
Löschungen und Verlängerungen auch Unterteilungen und einfügen von
Knoten, bei Grenzen das Anbinden niederrangiger Grenzen oder
(meist unfreiwillig bei Straßen *), freiwillg bei landuses, ...)
anderer Objekte.
Hier sollte als Koordinate des Punktes per Default eine genau
reingerechnete Koordinate genommen werden. Evtl. noch ein tag
auth-interpolated, dann kann man ihn als verschiebbar auf
der Linie definieren.
Für die Seezeichen bräuchte es wohl auch was passendes für
autentifizierte tags.
Die aufpoppende Warnmeldung könnte ein Eingabefeld haben, wo man
bei Änderungen was an die auth-users reinschreiben kann ("Kreisgrenze
wird hier ersetzt durch genaueren Import der Gemeindegrenze X")
Die auth-users, die die Meldung bekommen, können dann entscheiden
- Änderung übernehmen (auth-lat wird auf lat gesetzt etc. ...)
- alten Zustand wieder herstellen
- Knoten/Weg aus Autentifizierung rausnehmen
- ...
Beliebige Anwendungen können sich dann entscheiden, ob sie
lat oder auth-lat etc. verwenden mit und ohne Meldungen etc.
Die Integrität der Grenzen wird ja auch immer wichtiger, wenn
Anwendungen drauf aufbauen.
Für den Fall verschollener auth-authors sollte man jeder ein
auth-doubtful oder so dran hängen können.
Wenn sich dann 4 Wochen kein auth-author drum kümmert und das entfernt,
verfällt die ganze auth-Sache oder so ...
*) Aufpoppende Meldungen wären im übrigen auch praktisch für
den Fall, dass ich highway=* in eine boundary reinhängen will
statt des nächsten drunter oder knapp daneben liegenden highways.
Weiß nicht, was JOSM da macht als alter potlatcher, aber der hängt
überall rein...
Gruß Heiko "Mueck" Jacobs
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
