logo separator

[mkgmap-dev] Simplifying ways & rounding

From Johann Gail johann.gail at gmx.de on Sun Nov 29 16:44:24 GMT 2009

>>> That's a shame but the upside of only merging within a subdivision is
>>> that it's really quick.
>> Would it be possible to merge lines across more subdivisions or is this 
>> a natural limit?
> I can't be 100% sure without some study but I think it should be
> possible to merge across a whole tile. Somewhere like makeMapAreas() is
> about right because there it's looping through the resolutions and
> driving the subdivision creation. I think the merging needs to happen
> around there before the subdivisions are created.
> What would be very nice is to keep your existing merging within
> subdivision as the default behaviour and then have a merge within tile
> option for those with CPU to burn. Something like:
> --merge-lines    merge in subdiv
> --merge-lines=1  ditto
> --merge-lines=2  merge in tile
The merge lines patch is designed from start for high line numbers. It 
uses internal hashlists for performance reasons. I would expect the 
runtime to raise n*log(n), not n². So I do not expect it to burn cpu, 
but would need a test to proove it.

But I'm not sure, if merging across tiles would improve the whole thing. 
As far as I understand, a line could not go across multiple 
subdivisions. So it has to be splitted anyway at its bounds. I expect no 
usefull effects from merging before.

What I really would like, is to apply the merge filter before any 
creating of routing data. This would be the most reasonable place with 
the most effect, even to routing quality.

But one step after the other....
And I'm sorry, I could not spend that much time to the mkgamp project.


More information about the mkgmap-dev mailing list