Hello

Thank you for the quick reply
I will give it a try without the -u option not to use the UTF-8 sanitize and will let you know the results as soon as I have some

As far as other map files are concerned I have downloaded a few ones but this is the only one which I could unpack (have used pbzunzip2, bzip2, bunzip2) but all the time I have got corrupt archive messages. Also the MD5 sum of the downloaded file where not consistent with the md5 hash sum from the servers (I do not yet know the reason why)

I have downloaded the other day the latest planet file which is almost 17GB large and have started to unpack this morning with the following command
 pbunzip2 -d -k planet-latest.osm.bz2
pbzip2: *ERROR during decompression: -4

and the error have shown after 200GB is unpacked, but I can still see the process going on, despite for the error and now it is on 227 GB
Do you think this can impose a problem with the unpacked OSM file ?

On 6/13/2011 11:49 AM, M∡rtin Koppenhoefer wrote:
2011/6/13 Zolt Egete<xphreaks...@gmail.com>:
Are there any alternatives to osm2pgsql maybe something that ?

There are alternatives to osm2pgsql (e.g. imposm, osmosis) but they do
not do the same thing so it depends what you want to do with your
database (which scheme you want to have) which you should choose.

Actually osm2pgsql should work nonetheless, have you tried another
version of the planet or extract? Did you run md5 sum on your data
prior to importing it to verify if your file is OK?

./osm2pgsql -U postgres -s -u -S default.style -d gisa -C 2500
/home/zsolt/tmp/planet-100127.osm

Maybe the reason is the "-u" option? Looking at the help this should
not be needed since 2007 and maybe even can cause some harm:
"-u|--utf8-sanitize        Repair bad UTF8 input data (present in planet
dumps prior to August 2007). Adds about 10% overhead."


cheers,
Martin

_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Reply via email to