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
