[mkgmap-dev] [locator] What's next?

Mon Jun 6 20:12:51 BST 2011

I have read about the o5m format. It's interesting but at the moment 
there are some things that need to be solved before supporting o5m.
1. the format definition is not final and not approved by other 
implementors (only the o5mfilter guy implemented it and there may be 
some inherent bugs)
2. there is no existing toolchain for o5m (no geofabric dump, no 
splitter support etc.). mkgmap is the last tool in the chain.
3. the format description contains no hint how non latin characters are 
stored. All examples use ASCII characters.
4. I don't understand why this new format is faster than pbf. So there 
should be an independent confirmation about the speed advantages.

Unless these points are fixed I don't see any requirements to support o5m.

Anyhow it would be interesting if you can post the parameters one has to 
use to filter the boundaries and postal_codes using o5mfilter (or 
osmfilter).

WanMil

> Hi,
> there are tools like o5mfilter or osmfilter. They should be faster, but
> they can't write pbf, just o5m or osm-xml. The Format o5m is much better
> for filtering data, but there isn't any tool, which converts o5m to pbf.
> So maybe the the hole process wont be faster. Also o5m is faster then
> pbf, if you would update your local file with change-sets. I know that
> this isn't the task of locator-branch, but maybe reading o5m would be
> one of the next things for bnd-generation and splitter. :-)
>
> I will ask in german forum, how to use osmfilter for our filtering and
> compare it to osmosis.
>
> Henning
>
> Am 06.06.2011 20:33, schrieb WanMil:
>> bnd-file creation processes the whole input file. It does not filter for
>> boundary=administrative. The reason for this is that postal_codes are
>> also accepted.
>> The osmosis step is required because otherwise you probably will have
>> memory problems. If you use unfiltered data for the bnd-creation mkgmap
>> must first read *all* points and *all* ways from the input file. And if
>> you don't have a machine with tons of GB this will exhaust your memory.
>> Maybe someone can do some research if there is a better tool for
>> filtering the boundary data.
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev