Habe gestern anhand der Landsatbilder ein wenig am Wald gebastelt (besser gesagt versuchtâŠ). Ergebnis ist das heute ein Teil nicht mehr angezeigt wird. Hatte versucht unter anderem 2 âWĂ€lderâ zu verbinden. Habe gerade eben nochmal dran gebastelt, evtl. funktioniert es jetzt. Kann ich noch nicht genau sagen.
In Sachen Relationen bin ich ânewbâ und habe die Anwendung in JOSM noch nicht ganz verstanden. Gibt es irgendwo eine gute Anleitung wie man diese in JOSM bĂ€ndigt ?
Dazu kommt das mein aktueller Rechner bei einem Gebiet dieser GröĂe aus dem letzten Loch pfeift und eine Bearbeitung in der GröĂe zum Krampf wird. Arbeite deswegen eigentlich immer in Abschnitten. Bei Wegen etc. geht das. Aber beim Wald sehr 'unĂŒbersichtlichâHĂ€tte jemand Zeit und Lust in dem Gebiet anhand der landsatbilder (relativ grob) den Wald etwas zu âverfeinernâ? Also den Teil ausserhalb der Ortschaften ( da ist zum Teil schon recht genau weil abgelaufen / GPS.
ich habe mir einen Teil der WĂ€lder angesehen und sie sehen mir OK aus. Das sie nicht in der Karte erscheinen hĂ€ngt vermute ich damit zusammen, das die Server die die Daten an die Renderer ausliefern momentan fehlerhafte Daten ausliefern und dadurch die Renderer nichts vernĂŒnftiges darstellen können.
Wenn Du Problemen mit einem Bestimmtes Element hast, ist es ĂŒbrigens sinnvoller die ID von dem Element anzugeben, als einen Kartenausschnitt.
Muss ich heute abend mal ausprobieren. Das mit der Uhrzeigergeschichte bei einem multipolygon ist zwischenzeitlich egal, oder muss das noch im Uhrzeigersinn sein? Habe ich irgendwo mal was zu gelesen meine ich. (Bzw. meint das Sieb zwischen den Ohren. )
da ich gerade sehr viel mit Multipolygonen (insbesondere WaldflÀchen, hier im Harz) arbeite, meine Erfahrungen dazu:
Erstellung:
Ich lege, wie empfohlen, das AuĂenpolygon immer im Uhrzeigersinn und Innenpolygone gegen den Uhrzeigersinn an. Zumindest bei den Innenpolygonen ist das wohl nicht mehr notwendig, aber warum soll man es nicht weiterhin einheitlich so machen. WasserflĂ€chen mĂŒssen sich natĂŒrlich immer im Uhrzeigersinnn drehen (falls eine derartige mal aus irgendwelchen GrĂŒnden ein Innenpolygon sein sollte).
Rendern:
Wichtig! Mapnik berĂŒcksichtigt bei der schnellen Aktualisierung Multipolygone nicht bzw. nur eingeschrĂ€nkt. Nur bei dem wöchentlichen vollstĂ€ndigen Rendervorgang werden diese komplett gerendert. Das heiĂt, ein neu erstelltes Multipoygon ist ggf. erst nach einer Woche zu sehen, auch wenn es korrekt erstellt wurde. VerĂ€ndert man ein schon vorhandenes Multipolygon auch nur leicht, verschwindet dieses in der Mapnik-Karte erst einmal und taucht dann nach maximal einer Woche âwie aus dem nichtsâ plötzlich wieder auf.
Bei Osmarender passiert dies nicht. Ggf. daher unter âhttp://www.informationfreeway.org/â manuell ein âRerenderingâ in Osmarender auslösen, um das neue oder verĂ€nderte Multipolygon zu sehen.
Beim Export in Garmin-Karten mit Mkgmap fehlen Multipolygone prinzipbedingt, es sei denn die Kartengrenze verlÀuft auch durch den Rand des Innenpoylgons. Dies muss man in Kauf nehmen.
Sonstiges:
Das von Dir erstellte Multipolygon sieht jetzt so ok aus.
Zur Zeit gibt es, wie schon genannt, Probleme bei der Datenweitergabe an die Renderer, daher ggf. abwartenâŠ
Das ist fuer mich ein deutliches Indiz dafuer, dass das Objekt zu gross ist. Genau wie bei den Wegen spricht auch bei den Flaechen nichts dagegen, dass man sie in handhabbare Stuecke unterteilt. Soweit moeglich kann man dazu die Schnittkanten entlang von Strassen oder Wegen legen, dann faellt das auch nicht weiter auf, wenn ein Renderer meint, die Flaechen einzeln umranden zu muessen. (Was ich eigentlich als Renderer-Fehler ansehe, aber das ist sicherlich auch eine Geschmacksfrage).
Dass die Multipolygone auf den Garmin-Karten prinzipbedingt nicht funktionieren, spricht in meinen Augen auch nicht sonderlich fuer diese Konstrukte, die eigentlich immer wieder zu Problemen fuehren. Das kann man natuerlich in Kauf nehmen, man kann aber auch auf den Einsatz von Multipolygonen verzichten. Nicht alles, was bei OSM definiert ist, ist auch gut und sinnvoll.
Also in mapnik ist es zumindest in verschiedenen Zoomstufen und verschiedenen Kacheln schon neu gerendert.
@ de_muur
Es ist halt ein relativ groĂes zusammenhĂ€ngendes Waldgebiet. Und Wege habe ich gerne auch etwas detailierter, eben der vorh. topographie angepasst wie sie eben sind.
Wie macht man das Teilen eines Waldes am besten ? Bitte jetzt keinen Husqvarna oder Stihl Witz.
Hatte es vorher so, das sich 2 nodes jeweils den gleichen Punkt âteiltenâ. Das fĂŒhrte aber dazu das in mapnik eine feine weisse Linie gerendert wurde genau da wo sozusagen die Trennungslinie verlief. Also wo die zwei multipolygone an/aufeinander grenzten. Deswegen hatte ich es wieder verbunden weil ich dachte das war nicht so ganz im Sinne des Erfinders.
Wir haben hier auch unendlich viel Wald, mit Lichtungen, Moor, Wiesen, Heide und Seen darin.
Ich versuche dann immer die âouterâ-Line des multi entlang einer Strasse, Feldweg oder dergl. zu fĂŒhren. Diese Linie âverstecktâ sich dann unter der Strasse und ist beim Rendern dann nicht mehr zu sehen. Trotzdem bleibt immer die Ăberlegung, ob das multi nicht zu groĂ geraten ist und von anderen Mappern möglicherweise nicht erkannt wird. Weil dann schon mal das eine oder andere Gebiet verhunzt worden ist.
FĂŒr die feinen weiĂen Linien habe ich bisher auch noch keine Lösung gefunden. Eine Aufteilung an Wegen als Alternative fĂŒhrt zu Polygonen mit ziemlich vielen Punkten. Daher nehme ich momentan die weiĂen Linien in Kauf, weiĂ aber wie Du auch nicht so rechtâŠ
Ein AMD 2000+ sollte an sich aber doch noch keine Probleme bei âDeinemâ Polygon haben. Auf meinem AMD Athlon XP 2400+ mit 1 GByte RAM geht das alles flĂŒssig (nur bei Verwendung von WMS-Layern wie LandSat wird es langsam). Hast Du JOSM ausreichend Arbeitspeicher zugewiesen? Das macht einiges aus. Falls nicht, geht mit:
Unter Windows, Pfade entsprechend anpassen, hier 512 MByte fĂŒr JOSM:
C:\Programme\Java\jre6\bin\javaw.exe -jar -Xmx512M josm-tested.jar
Bei Dir sollte auch 1 GByte fĂŒr JOSM noch locker gehen:
C:\Programme\Java\jre6\bin\javaw.exe -jar -Xmx1024M josm-tested.jar
Vor einigen Wochen hatte ich mal im Forum und anderswo nachgeforscht, was der empfohlene Höchstwert von Punkten je Weg/Polygon/Grenze/⊠ist. Erst mehr als 1000 Punkten gelten als zu viele. Ich persönlich teile Polygone, je nachdem wie es passt, allerdings schon ab 100 bis 200 Punkten auf.
Dann nehme ich das mit den weiĂen Linien erstmal als âRenderproblemâ hin. So viel Wald ist es ja nicht was ich unterteilen wĂŒrde. Wobei der HunsrĂŒck ein noch nahezu weisser Fleck ist was Wald betrifft. Wenn man da anfĂ€ngt, dann artet das wohl wirklich in âArbeitâ aus. Irgendwie bike ich lieber und erfasse so Wege etc. âŠ:rolleyes:
Habe josm jetzt mal so aufgerufen wie von dir vorgeschlagen in dem ich mir ein .bat erstellt habe. (Nutze win2000) Eben gab es wĂ€hrend der Nutzung die Meldung mit 63MB ram und âstrange things may happenâ usw.
Der Speicher wird trotzdem dynamisch bis zu dieser maximalen GröĂe belegt (z.B. bis 1024MB) (von javaw.exe?), oder sollte das fix sein ?
Das landsat wms scheint mir allerdings wie du auch schreibst der gröĂte Bremser zu sein. Wobei das unabhĂ€ngig davon ziemlich nervt da es immer nur Teilbereiche lĂ€d und ganze Kacheln entweder rot und mit dem Text âFehlerâ versieht, oder diese ganz schwarz bleiben. Trotz 10x neu laden und verschiedenen zoomstufen Ă€ndert sich nix. So verbringe ich 8 von 10min mit warten.
Wenn die Auflösung der landsataufnahmen wenigstens noch ein StĂŒckchen höher wĂ€re. seufz. Naja besser als nix.
Ja, LandSat ist so ein bisschen âirgendwo da hört eventuell der Wald aufâ.
Das mit den fehlenden hintergrundfarbenen LandSat-Tiles nervt ziemlich. Jemand hat auch einen Bug-Eintrag bei JOSM gemacht. Momentan kann man nur in den Ordner â\Anwendungsdaten\JOSM\plugins\wmsplugin\cacheâ gehen, dort die fehlerhaften Tiles (alle mit einer GröĂe von nur ca. 1 KByte) löschen, danach in JOSM âFehlerkacheln neu ladenâ aufrufen, ggf. wieder die fehlerhaften Tiles in obigem Ordner löschen, usw. ⊠bis irgendwann alle da sind.
Die Meldung mit den 63M hatte ich seit dem Setzten von -Xmx512M (nach OSM-Wiki) niemals mehr, vorher hĂ€ufiger. Der Speicher wird dynamisch bis zu dieser Grenze belegt. Trotz Zuweisung von 512 MByte belegt JOSM bei mir dennoch zumeist nur um die 80 MByte. Wieviel Speicher JOSM maximal zur VerfĂŒgung steht, zeigt es unter Hilfe â StatusĂŒbersicht anzeigen.
Die feine weiĂe Linie wĂŒrde ich jetzt nicht als Rendererproblem sehen. Das kann bei aneinanderhĂ€ngenden FlĂ€chen durchaus gewollt sein. Dass man den Wald in mehrere FlĂ€chen unterteilen muss ist aber leider erstmal nicht zu vermeiden, aber keine Dauerlösung.
Ich gehe mal davon aus, dass spĂ€ter mal die Relation selber getaggt werden kann, dann brauch man kein riesieges geschlossenes Polygon. Quasi so, wie es bei Landesgrenzen bereits gemacht wirdâŠ
)
