|
Hello List, I have installed PostGRES 9.2 and PostGIS on windows server OS and I am having issues using the import tools to import OSM data to PostGRES. Just to start, I do not have an option of running any flavor of linux at all, virtual or not. I wanted to use osm2pgsql to import the pbf files of the whole planet into the PostGRES database, but the program keeps crashing in slim mode '--slim'. When I switch to osmosis, I just can't get it to setup correctly at all. When I call the program from the .bat file, it say C:\program isn't a valid path, which it isn't. So I moved the program to the root and placed it in c:\osmosis\bin. I still cannot get the osmosis to work. Are there database tuning options I need to set in PostGRES? Thank you A
showing 5 of 12
show 7 more comments
|
|
I was able to setup PostgreSQL (APIDB and PostGIS) loaded PostgreSQL (APIDB) it with the full planet file, and set it up to be updated from the hourly diffs. Using Windows Professional 7 x64. Not Windows Server 2008R2, but not too different... To be able to run osmosis, the PATH variable must contain the directory for the Java runtime (JRE). In my case it is "C:\Program Files (x86)\Java\jre7\bin" (was able to run it using the 64-bit JRE, but this is another history). It'll be different for you, likely. The command I used to load the planet file was: Most likely you'll want to change the --fast-read-xml to --read-pbf. That "xml" speaks for itself, it was done when the main form of the planet file was XML... Also, you may try to add a --tee and the appropriate command to save it to the PostGIS database at the same time. If you try to load the full planet file, osmosis (and very likely osmtopgsql as well) will fail with an PostgreSQL error stating that it cannot process transactions with more than 2^32 commands in it. For this problem the only workaround I found was to (temporarily!) disable transaction support of osmosis, altering its source code directly. More details about the changes can be found here (Note: In portuguese) As far as I could find, this is a limitation of PostgreSQL, and may be fixed in the future. It arose about September/2012 when the planet file grew too large. For updating from the hourly diffs, I use the following osmosis command: In this case you also can use --tee to save changes to PostGIS at the same time. Anyway, the process took (i7 3770, 32GB RAM, PostgreSQL 9.2 64-bit, tables and index spread over 6 tablespaces on 7 physical disks) about 1.5 weeks. Make sure you have plenty of free disk space (the APIDB is now 1.5TB, PostGIS probably will grow to about 800GB). The temp files also grow very large, I prefer to unpack the planet file before loading it. Please contact me again if your trouble persists. |
Can you please post the crash log os osm2pgsql?
where is the crash report located?
When iii says "post the crash log", he means "post it to a text sharing site like Pastebin and post the URL here".
I was asking where the log file lives on the system so I can post it. I looked in the osm2pgsql folders and didn't find it. So i was wondering if it's placed in the appdata folders etc... To be clear on the crashing, the process crashed on windows server, so there might not be a log file.
Unless anyone has tried this on W2K8R2 (which I doubt) it's quite possible that no-one knows where the log's going to end up. It's also possible (given that it's Windows) that the program might be failing because it can't open a logfile (or any other output file). To try and work around that, try installing away from root and away from "program files" etc. (which it sounds like your're doing) and run from a command prompt so that you can see any errors written to stdout.
You say that it's "crashing", but what error message do you see that tells you that?
Not an answer, but may contain some hints - it might be worth trying to hunt down video / slides for this SOTM presentation?
Crash log is here: http://pastebin.com/RZLa8cgE
That's not a log from osm2pgsql as such, just Windows saying that it failed. Try running from a command prompt to see if you can get anything more meaningful out of it.
No error message was spit out from osm2pgsql
So what is the actual problem? Can you please provide us the command line you use to invoke the import?
Normally postgres log files are put in the data subdirectory of the postgres installation. I generally install postgres in a location with no spaces in directory names. You may wish to change the degree of logging for postgres, which you can do through an option in PgAdmin 3.
However, before doing any of these things, it is important to know which version of each piece of software you are using and basic info about the configuration of your box (amount of RAM..).
Try importing Liechtenstein, if it works come back here, else read the docs more closely.
OK, so I was wrong - at least one other person uses osm2pgsl on Windows :-)