Hallo Jürgen,
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 
Ciao,
Frank
Hallo ajoessen, mobrob
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.
Edbert (EvanE)
@Evan… man kann beim Start von Java unter XP dem Programm automatisch mehr Speicher zur Verfügung stellen. Siehe z.b. JOSM: http://forum.openstreetmap.org/viewtopic.php?id=4790
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.
Gruß,
ajoessen
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.
ein 32bit OS kann insgesamt maximal nur etwas über 3GB adressieren. Unter Windows 32bit kann eine Anwendung maximal ~1,2GB bekommen.
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.
Edbert (EvanE)
Das ist ein ganz normaler java-Aufruf… java -Xmx2000M xyz.jar (für 2000 MB RAM) und hat mit Windows im speziellen nichts zu tun.
Was Fläche und Einwohner deutlich.
Ich schätze mal, dass allein das Ruhrgebiet bei den OSM-Daten so groß ist wie Gesamt-Hessen.
Um mal Zahlen in den Ring zu werfen die Größen der AIO Basemap vom 19.1.2011:
Hessen: 72 941 KB
NRW: 158 923 KB
Sprich rund doppelt so groß.
Edbert (EvanE)
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.
Edbert (EvanE)
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.
Im pbf-Rohdatenformat sogar 58:152.
Gruß,
ajoessen
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
Vor ein paar Tagen gabs eine Frage dazu auf talk-de, wo eine funktionierende Version raus kam. Evtl. hilft es dir weiter.
http://www.mail-archive.com/talk-de@openstreetmap.org/msg83024.html
Das auf talk-de war die Linuxversion.
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:
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.
Hi,
Du interpretierst hier den Bugreport (der schon ziemlich alt ist).
Während bei mir ein
~/protobuf-c-0.15$ ./configure
<snip>
checking google/protobuf/stubs/common.h usability... yes
checking google/protobuf/stubs/common.h presence... yes
checking for google/protobuf/stubs/common.h... yes
<snap>
~/protobuf-c-0.15$
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$
Ciao,
Frank
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.
Hi,
Nachdem ich
Das sieht der Autor wohl auch so
Ciao,
Frank