[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. Regards, Johann
- Previous message: [mkgmap-dev] Simplifying ways & rounding
- Next message: [mkgmap-dev] Simplifying ways & rounding
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list