Feedback an die Entwickler (vielleicht hilfts bei der Programmverbesserung):
Auch die installierte neue Version 1.2 stürzt nach Laden ab (WindowsXP, 1-Kern CPU, alle .NET-Pakete):
“Tracer2Sercer.exe hat ein Problem festgestellt und muss beendet werden.”
Das liegt nicht an Tracer2 sondern daran, wie ein Gebäudekomplex in ALK erfasst ist.
Wenn die Gebäudeteile z.B. zu unterschiedlichen Zeiten errichtet wurden, dann wurden sie jeweils einzeln vermessen und in ALK eingefügt.
Wenn man nach französischem Vorbild den Tracer2-Output blind übernimmt, dann passieren solche Dinge. In JOSM kann man solche Flächen mit SHIFT-J wieder zusammenfügen. Es ist die Frage an den Erfasser, sich ggfs. auch mal über die ALK hinwegzusetzen.
Das Gegenteil (fehlende Gebäude-Trennung) gibt es übrigens auch.
die Einzelflächen sind meistens im Umfang für eine Dachart und eine Gebäude-Etagenanzahl. Wenn Du die einzelnen Flächen mit building:part=yes setzest und zusätzlich eine gemeinsame Außenlinie erstellst mit building=yes, hast Du ein schönes Gebäude mit 3D-Tags.
Danke für den Tipp, die Teile in building:parts zu wandeln. Leider passt die ALK Aufteilung nur
bedingt zu dem was ich auf dem Luftfoto sehe. Werde das ganze nach vor Ort Besichtigung noch verbessern.
Ich kann mir nicht vorstellen, dass sich jemand diese Mühe gemacht hat. Die ganze Software zu installieren ist weniger aufwändig, als so eine Distri selbst zu bauen.
Ich nehme mal an, dass unter XP ohne installiertes IPv6-Protokoll nur 1 Eintrag für localhost zurückgeliefert wird (“127.0.0.1”) und das Ding mit host.AddressList[1] einfach knallt. Zur Erinnerung: der erste Eintrag wäre host.AddressList[0].
Juhu, ich glaube es einfach nicht. Auf meiner alten Windows XP Büchse lässt sich nun Tracer2Server ohne Probleme starten. Habe als erstes einfach mal Mono installiert, keine Veränderung. Danach einfach noch unter cmd den Befehl “ipv6 install” eingegeben. Und siehe da, Tracer2Server startet jetzt unter Windows XP bei mir. Werde nun mal schnell Tracer2Server testen.
Hat das schon jemand unter Linux probiert? Ich habe einen lokalen TMS eingetragen und es kommt nur “Exception: Can’t load Tile …”. Aus dem TMS-Serverlog ist ersichtlich, dass keine Kacheln angefordert werden. Keine Ahnung was der Tracer2Server macht, wenn er “Load tile …” in die Konsole schreibt. Jedenfalls keine Kacheln laden. Oder hat der irgendwo einen Cache? Wo?
Soweit es den NRW-Atlas betrifft, ist der ein WMS und kein TMS (=gekachelter Dienst). Als TMS angesprochen kann das also nicht funktionieren.
Falls du aus irgendeinem Grund auf Kacheln bestehen musst, bräuchtest du etwas wie einen lokalen MapProxy oder MapServer zum Umwandeln von WMS (NRW-Atlas) → TMS (lokal bei dir).
Ah, gut. Mit WMS geht es tatsächlich. Wobei gestern beim Testen mit Germany-NRW-Building auch nur Fehler kamen. Ich hatte nur “Adresse: … Kann aus WMS TMS / Gewählte Einträge / Bilddienst-URL übernommen werden” gelesen und dachte daher TMS geht.
Ist schon klar. Ich kenne nur jemanden der von einem anderen gehört hat, dass es auch andere Datenanbieter geben soll. Sogar welche die Luftbilder anbieten. Und die sind manchmal TMS. Bzw. sind sie bei mir TMS, weil sich das bequemer z.B. in JOSM integrieren lässt. Und da ich gerne mal mit neuen Dingen experimentiere, habe ich den Tracer2 gleich drauf angesetzt. Für mich ist es daher nur bedingt relevant, dass der NRW-Atlas WMS ist. Und bevor es Missverständnisse gibt: Ja, in diesem Posting ist Ironie enthalten.
Der Tracer und nun der Tracer2 sind auf Katasterkarten ausgelegt, das heißt insbesondere auf wenige Farben / Linienarten. Ob der bei einen Luftbild mit kontinuierlichen Farbverläufen funktioniert wäre die Frage. Aber ich kann nachvollziehen, dass du dies ausprobieren möchtest. Würde mich auch interessieren, da es viele Flächen mit einigermaßen gleichen Farben gibt, die so schneller erfassbar wären.
Naja, es geht nur bedingt mit Luftbildern. Zum einen braucht man einen guten Kontrast bzw. eine einheitliche Dachfarbe. Ein Schatten auf der einen Seite eines Spitzdaches stört schon. Meist läuft das Dach einfach nur aus, da die Wiese hinterm Haus oder der Hof vor dem Haus sich kaum von Dach unterscheiden (besonders bei Schatten). Die Erkennung dauert dann länger als zeichnen und es entstehen hunderte Punkte die nachbearbeitet werden müssen.
Zum anderen gibt es ein Problem, da man mehr zoomen kann als Auflösung da ist. Der Algorithmus modelliert dann schön jeden einzelnen Pixel der realen Auflösung. Alle Kanten bestehen aus einem sehr feinen Sägezahn mit extrem vielen Punkten.
Das kann man sicher alles noch optimieren, z.B. mit Bildbearbeitung zur Kontrasterhöhung. Wird sich aber nicht lohnen.
Für die Katasterdaten ist es dagegen ideal und die Kantenerkennung ist damit auch viel schneller.