oh sorry, no I got confused. We don't need that difference based on level. It's one list where we add all types that in the typfile lead to being impossible to change direction and then of course any routable line can be merged also at level 0 if it is not on that list and has no oneway attribute. For level 1 and higher it is only about the list and those types which could not be merged because of oneway attribute can now also be merged. On Wed, 5 May 2021 at 09:42, Felix Hartmann <extremecarver@gmail.com> wrote:

I think the simplify 4 patch had some more improvements for contourlines - but then I played around all the time with the DP values so it's hard to compare. I do know that simplify v4 versus 3 back then was an improvement. I think merging lines of different directions would be good too - with the caveat that we would need an additional instruction in the lines style-file to tell for lines not to merge (maybe make this a list - because then it's not needed each occurrence in the lines file, but once per type. I feel this is only important for any type that is either off center (e.g. I have MTB routes on the right side of the center line, hiking routes on the left - so you can see both if on the same way) or that have an arrow or similar in the typ-file (i.e. I have arrows on my rivers so you can see the direction of water flow). Oh and not sure if this is would be merged also at level 0 or only >0. That would make a big difference in how many line types I put on that list. I mean there are many types also at level 0 where I don't care about the direction. Of course any line with oneway that is routable could not be merged too. On the other hand even quite a few routable lines could be merged - but not all. If this also applies to level 0, then that file needs to have one command for level 0, and one command for level 1 and higher. At level 1 and onwards it only depends on the typfile if merging is possible or not. At level 0 it depends on both typfile and oneway attribute.

On Mon, 3 May 2021 at 23:28, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:

...

Hi all,

as a result of the thread about raster problems I've started this new branch.

First commit implements experimental options to specify values for --reducePointError and --reducePointErrorPolygon for each resolution Options are --simplify-filter-line-errors as replacement for --reducePointError and --simplify-filter-polygon-errors as replacement for --reducePointErrorPolygon. If --simplify-filter-line-errors is given and ----simplify-filter-polygon-errors is not given the values for lines are also used for polygons. Meaning is similar to the --polygon-size-limits option, values are given in pairs <resolution,reduce-value> Note that in resolution 24 the filter is not used. Sample usage: --x-simplify-filter-line-errors=23:1.3,22:2.6,20:4,18:6 --x-simplify-filter-polygon-errors=23:1.3,22:2.6,20:4 The old options are still supported, --reducePointErrorPolygon=1.3 is treated like --x-simplify-filter-line-errors=23:1.3

If none of the options is used the default is 2.6 for all resolutions.

There are a few more things to change: - simplify4.patch with special code to improve rendering of contour lines - more-merge.patch to allow merging of roads at level > 0 - Line merger could merge more lines if direction of the lines doesn't matter - maybe I find a way to merge dual-carriage ways into one line (again, if direction doesn't matter) - the --housenumber option should probably not assign numbers to trunk roads (similar to motorways), this can add lables to these roads and thus prohibit merging.

None of these changes should change routing results. They can reduce img size and improve rendering.

Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- Felix Hartman - Openmtbmap.org & VeloMap.org

-- Felix Hartman - Openmtbmap.org & VeloMap.org

well a waterway can be merged if it's displayed without arrows so it should not have special handling. A cliff cannot be merged, because it should have a direction (well yes problem with basecamp vs gps device being opposite, but that's another problem maybe solved one day by garmin). my routes cannot be merged because they would overlap otherwise more often and so on. it's complicated and mainly depends on the typfile. Even oneway ways can be merged from level 1 onwards, if not direction dependant in the typfile. The reason I proposed a separate file, is that maybe types like a route or waterway you will have 10-20 lines in your lines file (e.g. depending on width or importance you show something earlier, but you still use the same type). Yes possible also in lines file itself, just for some styles it would be much cleaner in a separate file. And I'm not sure how much saving potential there is for roads, but merging a second time for level 1 until overview map may make quite a big change (because of oneway) and not only merge for level 0. On Wed, 5 May 2021 at 13:14, Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:

Hi Felix,

yes, I have similar results. I am playing with an implementation that first only merges lines in the given direction and then tries again to merge with reversed order, but only if the way has no specific direction. The img format has a flag for "has a direction", and another one for "is oneway". With the current code you can only use the oneway=* tag to tell mkgmap that a way has a direction. It turned out that it looks wrong to merge waterways with a direction, so I added (waterway=river | waterway=stream | waterway=rapids | waterway=waterfall) {add oneway=yes}

I think a new tag mkgmap:has-direction=1" would be the better alternative. A list of types would be another alternative, but I think the style is the right place to do that (and much easier to implement and document)

Roads are handled earlier by the RoadMerger, and further merging is only possible in the overview map where there is no NET file so far.

Now, most of the ways which are merged in reversed order are boundaries. Probably because we have incomplete type=boundary relations and thus the members of those relations are not joined to single closed ways. Looking at this now, maybe it is better to use the joined way instead of the fragments.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Mittwoch, 5. Mai 2021 03:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters

oh sorry, no I got confused. We don't need that difference based on level. It's one list where we add all types that in the typfile lead to being impossible to change direction and then of course any routable line can be merged also at level 0 if it is not on that list and has no oneway attribute. For level 1 and higher it is only about the list and those types which could not be merged because of oneway attribute can now also be merged.

On Wed, 5 May 2021 at 09:42, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: I think the simplify 4 patch had some more improvements for contourlines - but then I played around all the time with the DP values so it's hard to compare. I do know that simplify v4 versus 3 back then was an improvement. I think merging lines of different directions would be good too - with the caveat that we would need an additional instruction in the lines style-file to tell for lines not to merge (maybe make this a list - because then it's not needed each occurrence in the lines file, but once per type. I feel this is only important for any type that is either off center (e.g. I have MTB routes on the right side of the center line, hiking routes on the left - so you can see both if on the same way) or that have an arrow or similar in the typ-file (i.e. I have arrows on my rivers so you can see the direction of water flow). Oh and not sure if this is would be merged also at level 0 or only >0. That would make a big difference in how many line types I put on that list. I mean there are many types also at level 0 where I don't care about the direction. Of course any line with oneway that is routable could not be merged too. On the other hand even quite a few routable lines could be merged - but not a ll. If this also applies to level 0, then that file needs to have one command for level 0, and one command for level 1 and higher. At level 1 and onwards it only depends on the typfile if merging is possible or not. At level 0 it depends on both typfile and oneway attribute.

On Mon, 3 May 2021 at 23:28, Gerd Petermann < GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi all,

as a result of the thread about raster problems I've started this new branch.

First commit implements experimental options to specify values for --reducePointError and --reducePointErrorPolygon for each resolution Options are --simplify-filter-line-errors as replacement for --reducePointError and --simplify-filter-polygon-errors as replacement for --reducePointErrorPolygon. If --simplify-filter-line-errors is given and ----simplify-filter-polygon-errors is not given the values for lines are also used for polygons. Meaning is similar to the --polygon-size-limits option, values are given in pairs <resolution,reduce-value> Note that in resolution 24 the filter is not used. Sample usage: --x-simplify-filter-line-errors=23:1.3,22:2.6,20:4,18:6 --x-simplify-filter-polygon-errors=23:1.3,22:2.6,20:4 The old options are still supported, --reducePointErrorPolygon=1.3 is treated like --x-simplify-filter-line-errors=23:1.3

If none of the options is used the default is 2.6 for all resolutions.

There are a few more things to change: - simplify4.patch with special code to improve rendering of contour lines - more-merge.patch to allow merging of roads at level > 0 - Line merger could merge more lines if direction of the lines doesn't matter - maybe I find a way to merge dual-carriage ways into one line (again, if direction doesn't matter) - the --housenumber option should probably not assign numbers to trunk roads (similar to motorways), this can add lables to these roads and thus prohibit merging.

None of these changes should change routing results. They can reduce img size and improve rendering.

Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- Felix Hartman - Openmtbmap.org & VeloMap.org

-- Felix Hartman - Openmtbmap.org & VeloMap.org

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

-- Felix Hartman - Openmtbmap.org & VeloMap.org

Hi Gerd, why does a road have pointers to lines in any level except 0? Is there really any routing in levels>0 ? As for rivers - yes they will show wrong direction than in gpsmapedit, but who cares? If the map is shown correctly in garmin tools, that should be enough. If you need the right direction then add the exception as for other lines that should not direction reversed. I always thought only level 0 is responsible for routing - whatever is in higher levels only matters for visual purposes. So yes with very high DP values and lots of simplification if you plan a car route over highways, at some point it will look a bit strange. But again, very few people use Garmin maps for car routing nowadays, and even less car routing based on OSM data. On Wed, 5 May 2021 at 14:29, Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:

Hi Felix,

I don't think that it only depends on the typ file. Programs like GpsMapEdit also show wrong merges.

Reg. roads: Seems RoadMerger also doesn't reverse points, I didn't notice that before. So, I have two methods to improve. It's quite difficult to understand the effects because we - merge roads with equal attributes - possibly split those roads again to avoid loops or too long roads or too complex roads (too many connections) or other limits in IMG format (this is needed for routable maps, maybe not for others) - possibly merge again at levels > 0

I have to think about this again. Maybe there is no problem with the NET file changes when this last step is done. The NET file contains "pointers" to the RGN file for each level in which the road is rendered. So, if a road is rendered at level 1 the data in NET allows to show all the road labels. Maybe that's all and there is no further effect (esp. not on routing), but maybe the info is also used when you create route in Basecamp. I guess it's not. I have no idea what Garmin software does when a road has pointers to lines at levels 0, 1, and 3 but not at level 2. I found no such case in Garmin demo maps. I think that could happen when I don't add code to prevent it. Probably it doesn't matter much when RoadMerger is allowed to reverse so that we have fewer parts which could be merged later.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Mittwoch, 5. Mai 2021 07:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters

well a waterway can be merged if it's displayed without arrows so it should not have special handling. A cliff cannot be merged, because it should have a direction (well yes problem with basecamp vs gps device being opposite, but that's another problem maybe solved one day by garmin). my routes cannot be merged because they would overlap otherwise more often

and so on. it's complicated and mainly depends on the typfile. Even oneway ways can be merged from level 1 onwards, if not direction dependant in the typfile.

The reason I proposed a separate file, is that maybe types like a route or waterway you will have 10-20 lines in your lines file (e.g. depending on width or importance you show something earlier, but you still use the same type). Yes possible also in lines file itself, just for some styles it would be much cleaner in a separate file.

And I'm not sure how much saving potential there is for roads, but merging a second time for level 1 until overview map may make quite a big change (because of oneway) and not only merge for level 0.

On Wed, 5 May 2021 at 13:14, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,

yes, I have similar results. I am playing with an implementation that first only merges lines in the given direction and then tries again to merge with reversed order, but only if the way has no specific direction. The img format has a flag for "has a direction", and another one for "is oneway". With the current code you can only use the oneway=* tag to tell mkgmap that a way has a direction. It turned out that it looks wrong to merge waterways with a direction, so I added (waterway=river | waterway=stream | waterway=rapids | waterway=waterfall) {add oneway=yes}

I think a new tag mkgmap:has-direction=1" would be the better alternative. A list of types would be another alternative, but I think the style is the right place to do that (and much easier to implement and document)

Roads are handled earlier by the RoadMerger, and further merging is only possible in the overview map where there is no NET file so far.

Now, most of the ways which are merged in reversed order are boundaries. Probably because we have incomplete type=boundary relations and thus the members of those relations are not joined to single closed ways. Looking at this now, maybe it is better to use the joined way instead of the fragments.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Mittwoch, 5. Mai 2021 03:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters

oh sorry, no I got confused. We don't need that difference based on level. It's one list where we add all types that in the typfile lead to being impossible to change direction and then of course any routable line can be merged also at level 0 if it is not on that list and has no oneway attribute. For level 1 and higher it is only about the list and those types which could not be merged because of oneway attribute can now also be merged.

On Wed, 5 May 2021 at 09:42, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: I think the simplify 4 patch had some more improvements for contourlines - but then I played around all the time with the DP values so it's hard to compare. I do know that simplify v4 versus 3 back then was an improvement. I think merging lines of different directions would be good too - with the caveat that we would need an additional instruction in the lines style-file to tell for lines not to merge (maybe make this a list - because then it's not needed each occurrence in the lines file, but once per type. I feel this is only important for any type that is either off center (e.g. I have MTB routes on the right side of the center line, hiking routes on the left - so you can see both if on the same way) or that have an arrow or similar in the typ-file (i.e. I have arrows on my rivers so you can see the direction of water flow). Oh and not sure if this is would be merged also at level 0 or only >0. That would make a big difference in how many line types I put on that list. I mean there are many types also at level 0 where I don't care about the direction. Of course any line with oneway that is routable could not be merged too. On the other hand even quite a few routable lines could be merged - but not a ll. If this also applies to level 0, then that file needs to have one command for level 0, and one command for level 1 and higher. At level 1 and onwards it only depends on the typfile if merging is possible or not. At level 0 it depends on both typfile and oneway attribute.

On Mon, 3 May 2021 at 23:28, Gerd Petermann < GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com

...

<mailto:GPetermann_muenchen@hotmail.com<mailto: GPetermann_muenchen@hotmail.com>>> wrote: Hi all,

as a result of the thread about raster problems I've started this new branch.

First commit implements experimental options to specify values for --reducePointError and --reducePointErrorPolygon for each resolution Options are --simplify-filter-line-errors as replacement for --reducePointError and --simplify-filter-polygon-errors as replacement for --reducePointErrorPolygon. If --simplify-filter-line-errors is given and ----simplify-filter-polygon-errors is not given the values for lines are also used for polygons. Meaning is similar to the --polygon-size-limits option, values are given in pairs <resolution,reduce-value> Note that in resolution 24 the filter is not used. Sample usage: --x-simplify-filter-line-errors=23:1.3,22:2.6,20:4,18:6 --x-simplify-filter-polygon-errors=23:1.3,22:2.6,20:4 The old options are still supported, --reducePointErrorPolygon=1.3 is treated like --x-simplify-filter-line-errors=23:1.3

If none of the options is used the default is 2.6 for all resolutions.

There are a few more things to change: - simplify4.patch with special code to improve rendering of contour lines - more-merge.patch to allow merging of roads at level > 0 - Line merger could merge more lines if direction of the lines doesn't matter - maybe I find a way to merge dual-carriage ways into one line (again, if direction doesn't matter) - the --housenumber option should probably not assign numbers to trunk roads (similar to motorways), this can add lables to these roads and thus prohibit merging.

None of these changes should change routing results. They can reduce img size and improve rendering.

Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk

...

<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- Felix Hartman - Openmtbmap.org & VeloMap.org

-- Felix Hartman - Openmtbmap.org & VeloMap.org

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- Felix Hartman - Openmtbmap.org & VeloMap.org

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

-- Felix Hartman - Openmtbmap.org & VeloMap.org

labels as in just names, or highway labels? In that case for maps without highway labels there could be more merging... And I don't think housenumbers should make any difference for level 1 and onwards... On Wed, 5 May 2021 at 15:13, Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:

Hi Felix,

I already wrote it. I think NET points to levels > 0 to allow showing more labels, possibly also house numbers. I really don't think that data at levels > 0 is used for routing, but who knows what Garmin software does with unexpected data in NET?

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Mittwoch, 5. Mai 2021 08:42 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters

Hi Gerd, why does a road have pointers to lines in any level except 0? Is there really any routing in levels>0 ? As for rivers - yes they will show wrong direction than in gpsmapedit, but who cares? If the map is shown correctly in garmin tools, that should be enough. If you need the right direction then add the exception as for other lines that should not direction reversed. I always thought only level 0 is responsible for routing - whatever is in higher levels only matters for visual purposes.

So yes with very high DP values and lots of simplification if you plan a car route over highways, at some point it will look a bit strange. But again, very few people use Garmin maps for car routing nowadays, and even less car routing based on OSM data.

On Wed, 5 May 2021 at 14:29, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,

I don't think that it only depends on the typ file. Programs like GpsMapEdit also show wrong merges.

Reg. roads: Seems RoadMerger also doesn't reverse points, I didn't notice that before. So, I have two methods to improve. It's quite difficult to understand the effects because we - merge roads with equal attributes - possibly split those roads again to avoid loops or too long roads or too complex roads (too many connections) or other limits in IMG format (this is needed for routable maps, maybe not for others) - possibly merge again at levels > 0

I have to think about this again. Maybe there is no problem with the NET file changes when this last step is done. The NET file contains "pointers" to the RGN file for each level in which the road is rendered. So, if a road is rendered at level 1 the data in NET allows to show all the road labels. Maybe that's all and there is no further effect (esp. not on routing), but maybe the info is also used when you create route in Basecamp. I guess it's not. I have no idea what Garmin software does when a road has pointers to lines at levels 0, 1, and 3 but not at level 2. I found no such case in Garmin demo maps. I think that could happen when I don't add code to prevent it. Probably it doesn't matter much when RoadMerger is allowed to reverse so that we have fewer parts which could be merged later.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Mittwoch, 5. Mai 2021 07:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters

well a waterway can be merged if it's displayed without arrows so it should not have special handling. A cliff cannot be merged, because it should have a direction (well yes problem with basecamp vs gps device being opposite, but that's another problem maybe solved one day by garmin). my routes cannot be merged because they would overlap otherwise more often

and so on. it's complicated and mainly depends on the typfile. Even oneway ways can be merged from level 1 onwards, if not direction dependant in the typfile.

The reason I proposed a separate file, is that maybe types like a route or waterway you will have 10-20 lines in your lines file (e.g. depending on width or importance you show something earlier, but you still use the same type). Yes possible also in lines file itself, just for some styles it would be much cleaner in a separate file.

And I'm not sure how much saving potential there is for roads, but merging a second time for level 1 until overview map may make quite a big change (because of oneway) and not only merge for level 0.

On Wed, 5 May 2021 at 13:14, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com

...

<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,

yes, I have similar results. I am playing with an implementation that first only merges lines in the given direction and then tries again to merge with reversed order, but only if the way has no specific direction. The img format has a flag for "has a direction", and another one for "is oneway". With the current code you can only use the oneway=* tag to tell mkgmap that a way has a direction. It turned out that it looks wrong to merge waterways with a direction, so I added (waterway=river | waterway=stream | waterway=rapids | waterway=waterfall) {add oneway=yes}

I think a new tag mkgmap:has-direction=1" would be the better alternative. A list of types would be another alternative, but I think the style is the right place to do that (and much easier to implement and document)

Roads are handled earlier by the RoadMerger, and further merging is only possible in the overview map where there is no NET file so far.

Now, most of the ways which are merged in reversed order are boundaries. Probably because we have incomplete type=boundary relations and thus the members of those relations are not joined to single closed ways. Looking at this now, maybe it is better to use the joined way instead of the fragments.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Mittwoch, 5. Mai 2021 03:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters

oh sorry, no I got confused. We don't need that difference based on level. It's one list where we add all types that in the typfile lead to being impossible to change direction and then of course any routable line can be merged also at level 0 if it is not on that list and has no oneway attribute. For level 1 and higher it is only about the list and those types which could not be merged because of oneway attribute can now also be merged.

On Wed, 5 May 2021 at 09:42, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>> wrote: I think the simplify 4 patch had some more improvements for contourlines - but then I played around all the time with the DP values so it's hard to compare. I do know that simplify v4 versus 3 back then was an improvement. I think merging lines of different directions would be good too - with the caveat that we would need an additional instruction in the lines style-file to tell for lines not to merge (maybe make this a list - because then it's not needed each occurrence in the lines file, but once per type. I feel this is only important for any type that is either off center (e.g. I have MTB routes on the right side of the center line, hiking routes on the left - so you can see both if on the same way) or that have an arrow or similar in the typ-file (i.e. I have arrows on my rivers so you can see the direction of water flow). Oh and not sure if this is would be merged also at level 0 or only >0. That would make a big difference in how many line types I put on that list. I mean there are many types also at level 0 where I don't care about the direction. Of course any line with oneway that is routable could not be merged too. On the other hand even quite a few routable lines could be merged - but not a ll. If this also applies to level 0, then that file needs to have one command for level 0, and one command for level 1 and higher. At level 1 and onwards it only depends on the typfile if merging is possible or not. At level 0 it depends on both typfile and oneway attribute.

On Mon, 3 May 2021 at 23:28, Gerd Petermann < GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com

...

<mailto:GPetermann_muenchen@hotmail.com<mailto: GPetermann_muenchen@hotmail.com>><mailto:GPetermann_muenchen@hotmail.com <mailto:GPetermann_muenchen@hotmail.com><mailto: GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>>> wrote: Hi all,

as a result of the thread about raster problems I've started this new branch.

First commit implements experimental options to specify values for --reducePointError and --reducePointErrorPolygon for each resolution Options are --simplify-filter-line-errors as replacement for --reducePointError and --simplify-filter-polygon-errors as replacement for --reducePointErrorPolygon. If --simplify-filter-line-errors is given and ----simplify-filter-polygon-errors is not given the values for lines are also used for polygons. Meaning is similar to the --polygon-size-limits option, values are given in pairs <resolution,reduce-value> Note that in resolution 24 the filter is not used. Sample usage: --x-simplify-filter-line-errors=23:1.3,22:2.6,20:4,18:6 --x-simplify-filter-polygon-errors=23:1.3,22:2.6,20:4 The old options are still supported, --reducePointErrorPolygon=1.3 is treated like --x-simplify-filter-line-errors=23:1.3

If none of the options is used the default is 2.6 for all resolutions.

There are a few more things to change: - simplify4.patch with special code to improve rendering of contour lines - more-merge.patch to allow merging of roads at level > 0 - Line merger could merge more lines if direction of the lines doesn't matter - maybe I find a way to merge dual-carriage ways into one line (again, if direction doesn't matter) - the --housenumber option should probably not assign numbers to trunk roads (similar to motorways), this can add lables to these roads and thus prohibit merging.

None of these changes should change routing results. They can reduce img size and improve rendering.

Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk

...

<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- Felix Hartman - Openmtbmap.org & VeloMap.org

-- Felix Hartman - Openmtbmap.org & VeloMap.org

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk

...

<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- Felix Hartman - Openmtbmap.org & VeloMap.org

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- Felix Hartman - Openmtbmap.org & VeloMap.org

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

-- Felix Hartman - Openmtbmap.org & VeloMap.org