Sorry, at the moment it is absolutely not possible for me to contiue development of this patch. I'he seen Steve has checked in parts of it, but haven't tested so far. (By the way, why doesn't there appear any commit mails?) Some thoughts to the last posts:
Although drawing performance was definitely improved, a lot of routing issues cropped up when I tried this in the field.
Thank you for trying out and reporting the errors.
- The routing issues seem similar to those which occurred before Mark Burton committed the MAX_POINTS_IN_WAY = 200 patch. Could it be that merging the highways pushes the number of nodes above this limit?
Yes, could be the lines gets to long by merging. I for myself haven't seen any errors. In the file LineSplitterFilter.java there is a line private static final int MAX_POINTS_IN_LINE = 250; which cuts the lines after symplifiing again into smaller segments. (Line was existing before my modifications.) Maybe this value should be reduced to 200 too.
- I also noticed frequent recalculations while driving. I have the sensitivity patch applied. Is it possible that the smoothing algorithm causes the ways to diverge enough from the actual route to trigger a recalculation? (I set the --reduce-point-density option to the default.)
- There was also a lot of weirdness in roundabouts. I was often routed the wrong way, or back and forth on the roundabout. Perhaps the merging is sometimes overzealous? Would it be a good idea to exclude roundabouts from smoothing and merging?
Maybe we should introduce a small change to the filter. It should not touch any lines at zoom level 0, where routing takes place. This was the behaviour of the previous LineSmoothingFilter. This will loss some of the optimisations, but should avoid the routing problems.