
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