On 02.11.2010 00:28, Steve Ratcliffe wrote:
Which file is this in? If so would changing this to
if (mergeLines&& res< 22) { LineMergeFilter merger = new LineMergeFilter(); lines = merger.merge(lines); }
work out for me? Or do I run into problems on further lines? (I do think Yes that should be all thats needed.
I can apply that to trunk too.
Currently it does apply at every resolution separately, but I think that is likely the problem. It is also not done to the road definitions which can't be right. What do you mean by this? In my eyes any road type (e.g. 0x01) could be Oh I meant internally, there is a class that keeps track of all the roads for routing, separately from the lines that get drawn. So a road is held within mkgmap in two places but only one is merged.
Roads at different levels are linked together via NET and well I'd have to look at it again to be sure, but it feels like that would cause a problem to me.
the same, that would only apply for resolution=24 (or resolution=23 if you produce maps without 24 - but mkgmap is severly broken in that regard anyhow. You currently cannot get a map to work that has resolution=23 as routing and most detailed resolution without big problems (at least 6 month ago when I tried this)). It would be nice to get routing working at r=23, it may not be that broken, I remember seeing a few pieces of code that assume 24 it may work if they were fixed.
Oh well, would be quite nice. I think that maybe long distance routing could be improved a lot, as all Garmin maps that are working well for autorouting, actually start with resolution 23. then one could move all POI to a seperate layer, so that most only appear at resolution 24 cause 23 would mean that one has to kick many more out ...
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev