I don't use Geofabrik extracts but my own ones. I keep country.o5m files
that are updated with osmupdate as a first step for map updates.
El 10/11/21 a las 22:59, Felix Hartmann escribió:
O5m is always faster, but needs more disk space. Converting geofabrik
osm.pbf to o5m makes sense however
O5m is always faster, but needs more disk space. Converting geofabrik
osm.pbf to o5m makes sense however (especially if you can write to Ramdisk
or slow Harddisk)
On Wed, 10 Nov 2021, 17:38 Carlos Dávila
wrote:
> I'm aware of the supposed advantages of pbf, but I did some tests in the
> past
Only as input for splitter it changes a lot. As input for mkgmap it's very
little difference.
On Wed, 10 Nov 2021, 17:38 Carlos Dávila
wrote:
> I'm aware of the supposed advantages of pbf, but I did some tests in the
> past and I found o5m to be quite faster than pbf, but I'll test again.
>
>
I'm aware of the supposed advantages of pbf, but I did some tests in the
past and I found o5m to be quite faster than pbf, but I'll test again.
El 10/11/21 a las 9:43, Gerd Petermann escribió:
Hi Carlos,
I'll try to debug this.
BTW: I see you use *.o5m for the tiles (output from splitter). I
Hi devs,
the problem occurs with node https://www.osm.org/node/5692472121
name=키타가키 고로케
Google translate says the name is Korean. The (utf8) name cannot be translated
into code-page 932 (japanese) and thus mkgmap converts the internal utf16
representation of the name to bytes. This happens in
Hi Carlos,
I'll try to debug this.
BTW: I see you use *.o5m for the tiles (output from splitter). I think this is
no longer a good choice, pbf is a lot smaller and almost as fast. Esp. when it
comes to the goal of reducing disk I/O (as with --gmapi-minimal)
Gerd
