[Talk-de] tracer2 NRW-Atlas - ALK umgezogen

[tabris]

Nabend,
ich hab mich gerade mal mit dem Mono-Debugger durch den Tracer2Server
gewuselt... einerseits um zu gucken wie der generelle Ablauf ist, sprich
wo man da einen "Hier gibt es keine Hausnummern zu sehen"-Hack
reinbasteln könnte und andererseits wieso der mit dem ALKIS-Layer beim
Download auf die Nase fällt.

Das Download-Problem war trivial... Im Server-Request fand sich: "WIDTH
is greater than the configured limit. Request rejected." :D
Nachdem ich die Tile-Größe angepasst habe funzte es. Mit Hausnummern
hatte ich jetzt auch keine Probleme. Bei meinem Test hatte ich gerade
nur ein Problem gefunden: Mehrere Garagen die aneinander klebten hatte
er nicht sauber getrennt.
Um Tracer2 mit ALKIS ans laufen zu bekommen ist keine Änderung der
Software nötig (wobei es vielleicht Sinn macht die Vorlage gleich zu
ändern...)

Wie folgt vorgehen:
- In JOSM: Bearbeiten/Einstellungen
- In den Tracer2-Tab wechseln
- Häckchen bei "Germany - NRW - Building" entfernen oder gleich ganz
löschen... das ist die alte kaputte ALK-Konfiguration.
- "Neu hinzufügen"
- Name: "ALKIS" o.Ä.
- Adresse:
wms:http://www.wms.nrw.de/geobasis/wms_nw_alkis?FORMAT=image/png&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=adv_alkis_gebaeude&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}
- Kachelgröße: 0.0002
- Auflösung: 1024 (darf nicht >=2048 sonst weigert sich der WMS-Server)
- Modus: boundary
- Schwellwert: 1
- Rest nach belieben
- "OK"
- Sicherstellen das die neue Konfiguration aktiv ist.
- Tracer2Server starten
- Tracen

Ob die Kachelgröße gut oder schlecht ist, weiß ich nicht. In ALK waren
es 0.0004. Habe es auf 0.0002 geändert, damit nach der Änderung der
Bildgröße von 2048 auf 1024 die effektive Auflösung gleich bleibt
(zumindest soweit ich die Bedeutung der Kachelgröße verstanden habe. Da
ich mir da aber nicht weiter mit beschäftigt habe will ich da nicht
ausschließen, dass ich da doch was falsch verstanden habe)
Mit Hausnummern habe ich jetzt keine Probleme feststellen können. Da die
Gebäudelinien ohne Anti-Aliasing gezeichnet sind, sind die Schwarz
(0,0,0) während die Hausnummern durch das Anti-Aliasing diverse
Graustufen haben. Darum scheint man das wunderbar mit der Schwelle von 1
erschlagen zu können. Vereinzelt habe ich mal den Wert 0,0,0 in
Hausnummern gesehen. Kann sein das er da reinrennt. Das müsste sich aber
recht einfach umgehen lassen: Auf der Suche nach dem Rand tastet sich
der Tracer von der Klick-Position aus nach Norden vor. Dann einfach
vermeiden, dass da die Hausnummer im Weg ist. Das mit dem nach Norden
vortasten sieht man ja auch schön wenn man versehentlich daneben klickt:
Er findet dann immer irgendwas im Norden, falls er nicht gerade aus den
Suchbereich rennt.

Ihr könnt das gerne auf talk-de zitieren. Nur darum will ich mich jetzt
da nicht anmelden.

Gruß,
Andreas

Am 02.06.2015 um 19:06 schrieb tabris:
> Am 01.06.2015 um 21:59 schrieb Florian Lohoff:
>> On Mon, Jun 01, 2015 at 09:38:54PM +0200, tabris wrote:
>>> Am 01.06.2015 um 20:34 schrieb Florian Lohoff:
>>>> Hi,
>>>>
>>>> On Mon, Jun 01, 2015 at 08:21:54PM +0200, tabris wrote:
>>>>> Hallo,
>>>>> hat eigentlich schon jemand verstanden weshalb der Tracer2 jetzt auf die
>>>>> Nase fällt?
>>>> 1. WMS URL existiert nicht mehr - Die hat der Tracer hard kodiert.
>>> Echt hartcodiert? ôO
>>> Das würde mich aus zwei Gründen wundern:
>>> 1. Die URL lässt sich ja im tracer2-Konfigurationsdialog ändern.
>>> 2. Ich hatte die auch mal geändert auf die Gemarkungen/Fluren-Karte, als
>>> ich da mal testweise versucht hatte mit dem tracer2 ein paar
>>> Stadtgrenzen abzuzeichnen und das hatte eigentlich problemlos geklappt.
>>> Ausschließen will ich jetzt aber nicht das da irgendwo noch was hart
>>> kodiert drin ist und der trotzdem da noch auf der alten URL rumfuscht.
>>> Hab mir den Sourcecode nie angeguckt.
>> Ich meine das gefunden zu haben - Der kriegt einen teil der
>> informationen vom JOSM und dann rät der rum ... Es gibt einen config
>> dialog? Der muss bei mir unter linux immer weg gewesen sein ... das
>> dingen mag nichtmal wenn ich den debug knopf anfasse.
> Der Config-Dialog gehört zum Tracer 2 Plugin und nicht zum Server. Der
> ist im normalen Einstellungsdialog von JOSM. Da ist ein eigener Reiter
> für tracer2 und da lässt sich das dann konfigurieren. Zumindest bei mir
> und ich bin hier auch mir Linux unterwegs.
>>> Gut, bis gerade war mir gar nicht bewusst, dass der im ALK einen Layer
>>> ohne die Hausnummern genutzt hatte... bzw. das es einen gab. Von daher
>>> war ich davon ausgegangen, dass der schon mit den Hausnummern klar
>>> kommt. Aber ja, wenn er das nie musste, dann ist mir durchaus klar, dass
>>> das auch noch ein Problem ist. Das Problem was ich angesprochen hatte
>>> bezog sich ja auch in erster Linie darauf, dass der scheinbar Probleme
>>> beim Laden hat.
>>> Die ganzen Probleme die die Hausnummern da verursachen können kann ich
>>> mir nur zu gut vorstellen. Wie geschrieben: Ich bin Bildverarbeiter...
>>> Mit sowas verdiene ich meine Brötchen.
>> Dann schreib doch mal neu ;) ich fands ja komisch das die das mit C#
>> gemacht haben und noch nen java plugin ;) Ich hätte ja vermutlich mit
>> C++ und OpenCV angefangen.
>>
>> Flo
> Wollen würde ich schon. Wegen dem Thema "Weitergabe von Firmen Know-How"
> bin ich da vorsichtig. Ein Kollege und ich hatten das Thema schonmal in
> Bezug auf blogging über Programmierung gegenüber der Geschäftsleitung
> zur Sprache gebracht und sind da nicht wirklich auf einen Nenner
> gekommen. Und das war schon unter Ausschluss von Bildverarbeitung.
> Tja... bleiben mir nur noch offensichtliche Sachen der ALKIS-Bilder:
> Homogene Bereiche haben Tracer 2 wohl nie gestört. Hausnummern und der
> Rand sind nicht homogen. Wäre doch cool wenn Hausnummern auch homogen
> wären weil dann der Tracer 2 wieder funzen würde. Bei den Gebäudelinien
> haben die sich das Antialiasing gespart. Gut zu erkennen an den wenigen
> unterschiedlichen Farben da. Die Hausnummern sind schön geglättet wie
> man an den vielen unterschiedlichen Farbwerten sehen kann. Einfach mal
> vom nahen angucken. Wenn man alles auf'n mal anguckt, dann sieht man die
> Details nicht.
> C# kann ich mir nur vorstellen, dass die das vielleicht besser konnten
> oder es schneller zu schreiben war. Für ernsthafte (Echtzeit)
> Bildverarbeitung ist C# aber echt zu lahm.
> Ich hätte wohl auch C++ + OpenCV genommen. Jedoch wäre bei mir das
> Java-Plugin für JOSM das Problem geworden: Ich HASSE Java... Einfach nur
> kaputt. xD
>
> Andreas
>
> _______________________________________________
> OSM mailing list
> OSM at gt.owl.de
> http://gt.owl.de/cgi-bin/mailman/listinfo/osm
>