wie Robert oben schon schrieb könnte es sein, dass es nur (noch) unter IE & Silverlight funktioniert, Bing hat das Design ihrer (Karten-)Startseite Ende letzten Jahres mal geändert.
Mittlerweile habe ich moonlight von meinem Linux-Hobel entfernt, so dass ich eh nicht mehr in den “Genuss” komme
JAVA bekommt unter XP nur eine begrenzte Menge Speicher.
Das kann man ausdehnen, indem man der Auslagerungsdatei mehr Plattenplatz zuteilt.
Sollte man vielleicht als Hinweis in die Dokumentation/Kurzanleitung schreiben.
Wie bei allen großen Programmen gilt:
Hauptspeicher ist durch nichts zu ersetzen außer durch mehr Hauptspeicher.
Schon. Aber osm2pgsql ist der Meinung, dass man unter XP maximal 3GB an RAM nutzen kann. Wenn das nicht reicht, hat man Pech gehabt. Man kann natürlich auf Windows 7 umsteigen…
Ich hab mich bislang erst einmal an einem Deutschland-Extrakt versucht, und der ist nach 40 Stunden abgebrochen. War allerdings ein Cloudemade-Extrakt.
ja o.k., mehr als 3 GB geht bei 32bit nicht. das ist schon so. da müsste man auf 64bit wechseln. Dann sollte auch osm2pgsql mit mehr RAM arbeiten können.
Ist NRW so viel größer als Hessen? Das hatte ich nämlich gestern mal testweise aus dem osm.bz2-Format importiert in eine nicht-optimierte Postgres-Datenbank und dauerte nur ca 30 Minuten. Das neue Binärformat soll ja angeblich schneller beim Import sein.
Mit Mapnik die Tiles zu rendern und sie dann in MOBAC zu laden erscheint mir nicht sinnvoll. Die Regions-Auswahl sollte in MOBAC stattfinden und nur die Tiles werden daraufhin gerendert, die benötigt werden. Gibt es denn für Mapnik eigentlich keine Java-Bindings - für Python gibt es das ja aber ganz ehrlich was will ich mit einer Sprache, bei der die Einrückung relevant ist…
Danke für den Hinweis.
Auf dem Mac nützt mir das eher wenig.
Aber dennoch mal wieder etwas aus den Tiefen von Windows gelernt.
Dass so eine Funktion in den Ordneroptionen versteckt ist, wundert mich bei Windows nur ein wenig.
Auf der anderen Seite scheint mir, eine kleine Batchdatei mit dem Aufruf zu erstellen, nicht so aufwändig.
So habe ich das auf meinem Mac und dem virtuellen WinXP gelöst.
Der Parameter “-Xmx123M” gehört klar zu Java, soweit hast du Recht.
Die im verlinkten Thread vorgestellte Methode die Speichergröße für jeden Java-Aufruf bei WinXP zu setzen, ist spezifisch für Windows. Darauf habe ich mich bezogen.
Soweit ich weis, kann man zumindest manchen Windowsversionen ja auch PAE beibringen. Ja, das ist nichts tolles, sondern erinnert eher an EMS zu DOS-Zeiten, aber man kann auf mehr Speicher zugreifen. Fragt mich jetzt nicht, wie man das aktiviert, ich habe unter Linux 64 das Problem nicht mehr.
Ich habe mich mal durch MinGW und osm2pgsql gekämpft. Das Compilieren von osm2pgsql und der benötigten Bibliotheken ist echt ein Krampf!
Ein hauptproblem konnte ich noch nicht lösen: Google’s protobuf-c lässt sich nicht unter MinGW compilieren. Damit steht die protobuf nicht zur Verfügung udn so weit ich das mitbekommen habe hängt an dieser Bibliothek die Unterstützung für PBF-Dateien.
Das Problem ist schon ziemlich lange bekannt: http://code.google.com/p/protobuf-c/issues/detail?id=17
keine Ahnung wie man das umgehen/beheben kann - deshalb sieht es düster aus mit PBF-Unterstützung für Windows.
Wer trotzdem sich mal die neu compilierte Version ansehen will: http://www.datafilehost.com/download-c460d5b2.html
Sie verwendet folgende Versionen: osm2pgsql (SVN 2011-03-24), libxml2-2.7.8, proj-4.7.0, libpq-8.4.7, geos-3.2.2, zlib-1.2.5
Naja, ein Teil der Fixes steht ja schon in dem Bugreport drin, gut die sind unter Windows leicht anders und ich kenne mich mit minGW auch nicht aus, aber etwas mit C unter Linux:
Die include-Datei malloc.h nach alloca.h kopieren (im Orginalposting wird ein Symlink erstellt).
Der 2. Fix von der Liste:
bedeutet, das “-no-undefined” als Option für das Linken bei minGW angeben werden muß. Ich weis aber nicht ob es eine Shellemulation bei minGW gibt, so das das configure-Script läuft, wenn ja, dann ist es analog zu oben, ansonsten muß man an den Linkoptionen im Makefile schrauben.
3. Anstatt von #include <sys/poll.h> ist der offizielle richtige Pfad für die poll()-Funktion unter Linux normalerweise #include <poll.h>. Also mal ändern und versuchen.
So das war aus dem Bugreport mehr oder weniger passend geraten, wenn es schief geht, stell mal die kompletten Fehlerausgaben vom Bauversuch auch noch mit online. Nicht das ich hier ewig ohne wirklich Zeit und Lust im Moment den Fehler im Code suchen möchte, aber wenn du die Fehlerausgaben mit online stellst, sind die Chancen höher, das jemand das Problem findet.
und ein anschließendes “make” (für den Linux-build) durchläuft,
komm’ ich mit mingw (für den Windows-cross-compile) gar nicht so weit:
~/protobuf-c-0.15$ ./configure --host=i586-mingw32msvc
<snip>
checking google/protobuf/stubs/common.h usability... no
checking google/protobuf/stubs/common.h presence... no
checking for google/protobuf/stubs/common.h... no
configure: error:
ERROR: protobuf headers are required.
<snap>
~/protobuf-c-0.15$
Dass dass configure von protobuf-c nicht durchäuft liegt daran, dass man von Hand noch das passende Include-und Lib-Verzeichnis angeben muss.
Wenn man das behebt kommt zumindestens bei “common.h usability” ein yes, der rest ist so weit ich das gesehen habe ein fehlerhaftes Configure script.
Das eigentliche Problem ist, dass es unter Windows/MinGW kein poll.h gibt - wie ja auch erwähnt in dem Bugreport, den ich verlinkt hatte (die anderen Probleme in dem report sind nicht mehr relevant).
Nach http://lists.zerezo.com/mingw-users/msg05987.html lässt sich das Nur durch Anpassungen der Anwendung beheben.
Gibt die Windows API keine Funktion her, die annährend mit poll() (http://linux.die.net/man/3/poll) vergleichbar ist? Die müssen da doch auch irgendwie Abfragen bzw. reagieren können, wenn es neue Daten zum z.B. Lesen auf einem Filedescriptor gibt?
Edit: Notfalls kann man auch die betreffenden Dateidescriptoren auf non-blocking I/O umstellen (z.B O_NONBLOCK bei open() oder mit fcntl()) und dann macht man eben das Polling ob es neue Daten gibt manuell mit 'ner Schleife, das belastet eben nur die CPU, was der Grund ist, warum es poll() und select() gibt.
protobuf-2.4.0a cross-compiliert (ging auch nur teilweise)
davon libprotobuf.a/libprotoc.a und das google-Verz. in die entspr. /usr/i586-mingw32msvc-Verz. kopiert und
pthread aus dem configure-script entfernt
habe, ging auch ein
./configure --prefix=/usr/i586-mingw32msvc --host=i586-mingw32msvc --with-endianness=little
dass anschließende ‘make’ natürlich nicht, denn