Hi Gerd, I don't know if your patch makes sense or not. But let's start thinking loud (the following thoughts might be completely wrong!!!): The LineMergeFilter should not modify routing at all. This is (should be?) catched by the rule that lines are merged only if resolution < 24 or the line is no road. That also means that merging is only a cosmetic and performance change. Cosmetic: the lines are getting longer and therefore they will be visible to resolutions with lower number because the subsequent filter work better with longer lines. Performance: fewer objects and smaller img size for the device to display. Merging of lines changes the behaviour of subsequent filters. You've found a good example with Minkos way and the DouglasPeuckerFilter. When having a look at this example I think the LineMergeFilter should not merge lines to closed ways (unless they are roundabouts). If a way is already closed it should not be merged any more. Despite the absence of detailed knowledge of the map format I think that the oneway flag should not matter in resolutions < 24. Overlays with oneway arrows depend on the fact that they use a typ file with specific images. Having two ways A (oneway=yes) and B (oneway=no) you will have three MapLine objects: Object 1 type 0x06 derived from A Object 2 type 0x1022 derived from A which paints the oneway arrows Object 3 type 0x06 derived from B You can merge 1 with 3 because 2 will remain and will still paint the oneway arrows. But 1 and 3 doesn't depend on being oneway or not. This is interesting only for the routing layer, isn't it? So from my point of view it should benefit more to have a look which operations in the filters modify the routing network and eliminate them. This might be performed by creating a textual output of the routing layer. The create an output before the filters are applied and a second output with filters applied. Both outputs should be identical. WanMil

Hi,

attached is a patch that should fix cosmetic issues with merge-lines and oneways.

The idea: 1) merge-lines should not merge two lines if one is a oneway and one is not 2) merge-lines should not merge two oneway lines if the angle between the two ways is too small (< 30°). Not sure what it does with roundabouts.

Please try this if your style creates overlays for oneways. I don't expect any changes in routing. Compiled version is here: |http://files.mkgmap.org.uk/download/123/mkgmap.jar|

@Steve: Please can you check if the implemented test reg. bearings makes sense?

Gerd

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi

2) merge-lines should not merge two oneway lines if the angle between the two ways is too small (< 30°). Not sure what it does with roundabouts.

I was not thinking about the angle between the lines, but rather just about how lines are joined that run in opposite directions from the join point. For a non-one way road you could join start to start or end to end and reverse the order of one of the lines, with a oneway street you can't do that and the only allowed join is end to start. So it looks like the code doesn't try to match both ends for any case, so it will not be a problem. Still I think it is worth making isSimilar() deal with all the cases, even if some of them are not possible for other reasons at the moment. ..Steve