es ist schon richtig, dass beim Transformieren bereits vorhandener Gebäude Punkte, wie z.B. Eingänge verloren gehen.
Das liegt daran, dass bei der Transformation des ways zunächst alle nodes gelöscht werden und neue Punkte in den bereits existierenden way an der korrekten Position eingefügt werden.
Dies ist leider nicht anders möglich.
Als anständiger Mapper hilft hier nur zunächst Punkte mit Eigenschaften, wie z.b. entrance=* vom Gebäude zu lösen, anschließend die Transformation durchzuführen und zu guter Letzt die Punkte wieder mit dem transformierten Gebäude zu verbinden.
Momentan ist der Tracer2 wirklich sehr kleinlich und bildet die kleinsten Ecken mit ab.
Bei kreisförmigen Gebäuden kann es so sehr schnell passieren, dass man >52 Punkte je Gebäude bekommt. Belecker hatte bereits eine Kreisbogen-Erkennung integriert, hat diese aber für die offizielle Version wieder entfernt, da der Code leider nicht komplett lizensfrei war. Wenn die letzten Lizensdetails geklärt sind, wird die Kreisbogenerkennung offizieller Bestandteil des Tracer2Server.
Weitere Vereinfachungen, wie von Edbert angeregt sind auf die ToDo-Liste mit aufgenommen.
Vorteil:
Mappt man z.B. ein Wohngebiet und klickt sich zunächst durch die Wohnhäuser (building=house), dann bekommen nach dem ersten house alle folgenden ebenfalls den gleichen tag, bis man es manuell ändert.
Nachteil:
Wird man unaufmerksam, dann mappt man plötzlich ein Dorf voller Kathedralen.
Ich verstehe EvanE so, dass es ihm nicht (nur) um Kreisbögen geht, sondern vor allem um Details unterhalb einer bestimmten Größe (1 m). Das können auch linearen Strukturen wie Minivorsprünge sein. Mit einem Parameter der Art “keine Linien kürzer als x m” wäre ihm schon geholfen. Die NRW-ALK ist schon sehr detailliert, viel mehr als man es eigentlich in OSM braucht. Wenn nicht jede kleinste Ecke reproduziert wird, wird auch dem Problem “OSM kopiert de facto die ALK” etwas Wind aus den Segeln genommen. Für viele Gebäude reichen vier Wände und von mir aus noch Lage des Einganges.
Das letztere, Hausnummer, PLZ usw. sind aber nicht im Fokus des Tools.
Genau das hast du richtig verstanden.
Ob die Schwelle nun 1.0m, 0.7m oder 1.6m ist, wäre eine Frage der Erfahrung, bzw. sollte irgendwann dann auch einstellbar sein.
Das wäre sicher ein Argument, dass diese Diskussion entschärfen könnte.
Auch wenn das in der Anleitung beschrieben ist (was ja immerhin schon als positiv zu anzusehen ist), so sollte man Punkte mit Taggs auf keinen Fall löschen, da damit Informationen (Eingang, Adresse, Geschäft, …) verloren gehen. Wenn es nicht anders geht, den Punkt zwar aus der Nodeliste des Weges entfernen aber an seiner bisherigen Position behalten. So ist dei Information noch vorhanden und kann leicht wieder an der richtigen Stelle integriert werden.
Ähnlich ist es mit Punkten, die mit anderen Wegen verbunden sind. Auch diese sollten als Teil des anderen Weges erhalten bleiben, sprich nur aus der Nodeliste des zu ändernden Weges entfernt werden. Klassisches Beispiel sind natürlich die Verbindung mit anderen Gebäuden.
Wichtiger sind jedoch Wege, die mit dem Gebäude verbunden sind. Die Endpunkte sollten an ihrer bisherigen Position erhalten bleiben, nur nicht mehr mit dem neuen Umriss verbunden sein. So bleibt ein Fußweg zum bisherigen Eingang erhalten, nur dass der Eingang eben nicht mehr mit dem Gebäude-Umriss verbunden ist. Diese Situation kann leichter korrigiert werden, als wenn der Knoten komplett weg ist.
Der Wunsch, solche Punkte an eine logisch sinnvolle Stelle wieder im Gebäude-Umriss einzufügen, ist verständlich aber dürfte in der Tat schwierig zu realisieren sein. Das fordere ich nicht. Aber solche Punkte sollten als freie Punkte erhalten bleiben, damit es einfacher bleibt die alten Verhältnisse (angepasst an den neuen Umriss) wieder herzustellen.
Schließlich gilt bekanntermaßen der Spruch: “Aus den Augen, aus dem Sinn”. Wenn die Punkte mit Zusatzinformationen (anderer Weg, Taggs) erhalten bleiben, wird nicht so schnell vergessen, dass da noch etwas nachzutragen/-arbeiten ist.
Übrigens denke ich, dass man die übrigen Punkte (ohne Taggs und Verbindung) eines alten Umriss durchaus als erste Punkte des neuen Umriss verwenden könnte. Aber das ist ein sekundäres Problem und dient vor allem der Datensparsamkeit.
Ich sag erstmal ehrlicherweise:
Ich hab das Plugin nicht genutzt, es klingt aber gut was die anderen hier schreiben.
Der letzte Satz ist doch Unsinn.
Du scheinst Programmierer zu sein. Du solltest das können.
Andere Plugins können das auch. Man kann vorhandene Punkte z.B. wiederverwenden und
denen andere lat/lon geben. Falls man die History behalten möchte.
Faulheit ist kein Grund.
Solche mit Tags, ja die sind schwieriger.
Da ist immer die Frage ob die an dem neuen Gebäudeumriss noch an der richtigen Stelle sind.
Vorschlag:
Bei Eingängen könnte man diese behalten, ausserhalb des way, und ein FIXME dranpappen,
kam schon mal in einem anderen Post.
Bei allen anderen Tags an nodes die nicht trivial sind (Josm hat da eine Liste),
das sollten meiner Erfahrung nach sehr sehr wenige sein. Wenn es was gibt sind
es entrance=* und building=entrance.
Lösung: Der Way wird einfach nicht transformiert. Fehlermeldung an den User er soll sich
das erst mal genauer ansehen.
Oder halt die Nodes mit Tags auf Nachfrage unabhängig des ways behalten, mit FIXME.
Mit so einer Sicherheit könnten die Nutzer fleißig das Plugin verwenden ohne immer
gucken zu müssen ob sie was kaputt machen.
Weitere Idee:
Ein Modus (oder was mit Shift/Ctrl/Alt… Klick) in dem ein Node mit Entrance nicht
verschoben wird, und im way behalten wird.
Dann kann der User zuerst den doch auffälligen Entrance dahin schieben wo er
vermutlich hingehört, das Plugin baut das Haus dann drumrum. Möglichst unter
Wiederverwendung der anderen alten Nodes.
User kann dann nochmal ‘Q’ drücken zum quadratisch machen wenn das passt.
Oder das Plugin schiebt seinen neuen way oder den entrance um paar cm so
hin das er auf einer geraden Linie liegt, wenn da eine zu sein scheint.
Als anständiger Entwickler baut man Werkzeuge die es den Usern einfach machen.
Keine Fallstricke auslegen. Werkzeuge sollten es nicht einfach machen Daten zu zerstören.
Es könnte nämlich Ärger erzeugen wenn Mapper fleissig Eingänge gemappt haben und
manische Abmaler die Arbeit mit dem Plugin einfach ausradieren.
Also ich finde - unabhängig vom gewählten Ton - die Vorschläge von peb12345 durchaus sinnvoll unter Berücksichtigung der Tatsache, dass teilweise mühsam gesammelte vorhandene Informationen erhaltenswert sind und OSM nicht zum “Malen nach Zahlen” verkommen darf.
Habe es gestern unter Ubuntu 12.04 installiert.
Wollte ab Punkt 7 die Änderungen machen habe dabei aber festgestellt, dass die Quellen inzwischen angepasst sind, da das OS abgefragt wird und die Anpassungen daher unnötig sind.
Bei mir läuft es toll und ich freue mich, dass es so etwas feines gibt.
Die Klötzchen von Hand malen dauert doch einiges länger und so bleibt mehr Zeit zum verifizieren in der Natur übrig.
Wege, die mit einem Gebäude verbunden sind bleiben mit allen Eigenschaften an ihrer ursprünglichen Position erhalten.
Ein Punkt mit Eigenschaften geht nur dann verloren, wenn er ausschließlich Bestandteil des zu transformierenden Gebäudes ist.
Du bekommst die Fehlermeldung, da Maps4BW eine Auflösungsbegrenzung hat.
Setzt man die Auflösung in den Tracer2-Plugin Einstellungen auf einen kleineren Wert, ist die Fehlermeldung zwar weg, aber zu brauchbaren Ergebnissen führt das trotzdem nicht.
Maps4BW ist für Tracer2 leider nicht geeignet, da:
die Karte zu grob aufgelöst ist und dadurch keine klaren Übergänge innen/aussen bestehen
Hausnummern im Gebäude sind, die ebenfalls die Erkennung schwierig machen
Wenn der Installer für Linux fertig ist, dann will sich Belecker mal ansehen, wie man so eine Funktion einbauen kann.
Ich sehe es so, dass mal abgesehen von der wahnsinnigen Geschwindigkeit, die man mit dem Tracer2 vorlegen kann, gibt es für mich keinen Unterschied, ob man mühsam von Hand jedes Detail der ALK erfasst, oder dies halbautomatisiert macht.
Es steht jedem Mapper frei Gebäude aus der ALK zu vereinfachen, aber man kann genau so gut jedes noch so kleinste Detail erfassen.
Ich wusste gar nicht, was für (meiner Meinung nach) Quatsch im Wiki steht.
Das, was da im Wiki steht, ist nämlich falsch! Alle Daten, die in OSM importiert werden, müssen mit den Contributor Terms kompatibel sein. Die CC-BY-SA ist das nicht. Das SA (Share-Alike) heißt nicht umsonst “Weitergabe unter gleichen Bedingungen”. Das tun wir mit der ODbL oder einer anderen Lizenz, die wir in Zukunft vielleicht haben werden, nicht. Daher bitte ich dich, keine weiteren Daten vom ORKA-Layer zu übernehmen.
Ich habe User !i!, der hier im Forum auch mitliest, schon eine Mail geschrieben.
Ich habe Tracer2&Zubehör (noch) nicht installiert, weil es hier keine damit nutzbare Daten gibt.
Zum Erhalt der history möchte ich trotzdem fragen, ob der Programmierer nicht einfach die Funktion “replace geometry” von utilsplugin2 verwenden könnte?
Ansonsten sehe ich keinen Nachteil darin, dass man Gebäude von einer amtlichen Quelle halbautomatisch abmalen kann. Das Abzeichnen von Luftbildern - besonders in engen Innenstädten - ist ungleich aufwendiger, zeitraubender und nicht unbedingt genauer. Dass man Gebäude erst nach Begehung und der dabei erfolgten Schätzung einträgt, dürfte als ungenaues und aufwendigstes Mittel zum größten Teil der Vergangenheit angehören, Neubauten ausgenommen.
Ich habe mir nun auch Tracer2 installiert. Dank der Anleitung von couchmapper aus Post #2 hat es super geklappt. Es wird doch einiges an Daten gezogen, welches nicht unerwähnt bleiben sollte (ist hiermit geschehen :D). Dank auch an Belecker (für das Plugin) und nicolaus1977 (für die Kommunikation).
Um nicht jedes Mal das Terminal, zum Starten von „MonoDevelop“ bemühen zu müssen, habe ich mir noch mit Arronax einen Starter angelegt.
Sollte man nicht, solange es noch keinen Linux-Installer gibt, die Anleitung von couchmapper mit ins Wiki überführen oder zumindest einen Link zu #2 setzten?
