On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3. 2: more codes could be added for wider highways and their corresponding entries in mapnik.txt 3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16). [1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
Hi all I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end. Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html 1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll. 2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways. 3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp. [extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway. 4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer. 5/ Have line for leisure=track even if area. 6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a. 7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway. 8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html 9/ Consider natural=cliff a barrier. 10/ Add motorway[_link] roundabouts (yes, some do exist). 11/ Unquote some numbers - no actual effect. 12/ Tweak some road speeds. [extra] A few more tweaked. 13/ Use 0x09 (high-speed ramp) for road class 4 links 14/ Add footway around car parks if 'connecting'. [extra] This change is disabled. 15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map. 16/ Improve railway platform names and suppress footway if not 'connecting'. 17/ Show disused:railway in the same way as railway=disused. 18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only. 19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled 20/ Speed up car ferries. 21/ A few other layout/space fixes. Additional changes: 22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution 23/ natural=landslide like other barriers (eg cliff) 24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction. 25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail) 26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index 27/ Add comment about colour pallet to mapnik.txt Patch attached Ticker On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, while you are at it: I see lots of rather confusing texts like "gate" or "lift_gate" popping up in the map on my Oregon. I think they might be useful for mappers but they are not very useful for the normal user. Maybe it is only on my device but I don't see any need for this. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 11. Februar 2021 15:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes Hi all I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end. Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html 1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll. 2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways. 3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp. [extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway. 4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer. 5/ Have line for leisure=track even if area. 6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a. 7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway. 8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html 9/ Consider natural=cliff a barrier. 10/ Add motorway[_link] roundabouts (yes, some do exist). 11/ Unquote some numbers - no actual effect. 12/ Tweak some road speeds. [extra] A few more tweaked. 13/ Use 0x09 (high-speed ramp) for road class 4 links 14/ Add footway around car parks if 'connecting'. [extra] This change is disabled. 15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map. 16/ Improve railway platform names and suppress footway if not 'connecting'. 17/ Show disused:railway in the same way as railway=disused. 18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only. 19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled 20/ Speed up car ferries. 21/ A few other layout/space fixes. Additional changes: 22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution 23/ natural=landslide like other barriers (eg cliff) 24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction. 25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail) 26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index 27/ Add comment about colour pallet to mapnik.txt Patch attached Ticker On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd The "points" barriers use 0x3200 and I only see these when I "overzoom". I think I configured the device Map Detail levels and Text sizes to get it how I wanted. I find them useful when walking and sometimes useful for choosing an end-point for car navigation or seeing why a route hasn't been chosen. "lines" barriers (wall/ditch/etc) again I find useful when walking. Either of these can commented out by users making their own style starting from default. When I started, the first thing I had to remove were all the low-level administrative boundaries, but I think it right that they are in the default style. I'd rather not start on other changes until this lot is out of the way. Ticker On Thu, 2021-02-11 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
while you are at it: I see lots of rather confusing texts like "gate" or "lift_gate" popping up in the map on my Oregon. I think they might be useful for mappers but they are not very useful for the normal user. Maybe it is only on my device but I don't see any need for this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 11. Februar 2021 15:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, in fact 3200 - 3f1f strictly follow their given resolution value - other than e.g. 2a-2f, which only appear at kind of 24+, no matter what resolution is given. Even if both ranges are styled to resolution 24: 2a-2f will always appear a bit later. I suspect that´s what Gerd found to be confusing. Jan
Am 12.02.2021 um 09:46 schrieb Ticker Berkin <rwb-mkgmap@jagit.co.uk>:
Hi Gerd
The "points" barriers use 0x3200 and I only see these when I "overzoom". I think I configured the device Map Detail levels and Text sizes to get it how I wanted.
I find them useful when walking and sometimes useful for choosing an end-point for car navigation or seeing why a route hasn't been chosen.
"lines" barriers (wall/ditch/etc) again I find useful when walking.
Either of these can commented out by users making their own style starting from default. When I started, the first thing I had to remove were all the low-level administrative boundaries, but I think it right that they are in the default style.
I'd rather not start on other changes until this lot is out of the way.
Ticker
On Thu, 2021-02-11 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
while you are at it: I see lots of rather confusing texts like "gate" or "lift_gate" popping up in the map on my Oregon. I think they might be useful for mappers but they are not very useful for the normal user. Maybe it is only on my device but I don't see any need for this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 11. Februar 2021 15:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, reg. barrier names: I don't want those texts in the map at all. I might want to see them when I select the icon to look at the details. I expect strings in the map to be names of objects (streets, cities), not barrier properties. Esp. not in a foreign language. My opinion: If you can't find a good way to render them better don't render them at all. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Freitag, 12. Februar 2021 10:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes Hi Ticker, in fact 3200 - 3f1f strictly follow their given resolution value - other than e.g. 2a-2f, which only appear at kind of 24+, no matter what resolution is given. Even if both ranges are styled to resolution 24: 2a-2f will always appear a bit later. I suspect that´s what Gerd found to be confusing. Jan
Am 12.02.2021 um 09:46 schrieb Ticker Berkin <rwb-mkgmap@jagit.co.uk>:
Hi Gerd
The "points" barriers use 0x3200 and I only see these when I "overzoom". I think I configured the device Map Detail levels and Text sizes to get it how I wanted.
I find them useful when walking and sometimes useful for choosing an end-point for car navigation or seeing why a route hasn't been chosen.
"lines" barriers (wall/ditch/etc) again I find useful when walking.
Either of these can commented out by users making their own style starting from default. When I started, the first thing I had to remove were all the low-level administrative boundaries, but I think it right that they are in the default style.
I'd rather not start on other changes until this lot is out of the way.
Ticker
On Thu, 2021-02-11 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
while you are at it: I see lots of rather confusing texts like "gate" or "lift_gate" popping up in the map on my Oregon. I think they might be useful for mappers but they are not very useful for the normal user. Maybe it is only on my device but I don't see any need for this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 11. Februar 2021 15:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd This has always been a problem with styles, encouraged by [... default_name ...], eg: amenity=embassy & country!=* [0x3003 resolution 24 default_name 'Embassy'] amenity=emergency_phone [0x2f12 resolution 24 default_name 'Emergency Phone'] I've added to this in an attempt to provide more useful information for unnamed entities by using constructs like: tourism=* & name!=* & tourism!=yes & tourism!=no {set name='${tourism|subst:"_=> "}'} amenity=restaurant {add name='${cuisine|subst:"_=> "}'} What is needed is another "substitution filter" - translate, that takes an optional parameter "context"; context is normally the name of the tag. The above would read: amenity=embassy & country!=* {add name='${amenity|translate:amenity}'} [0x3003 resolution 24] amenity=emergency_phone {add name='${amenity|translate:amenity}'} [0x2f12 resolution 24 default_name 'Emergency Phone'] tourism=* & name!=* & tourism!=yes & tourism!=no {set name='${tourism|translate:tourism}'} amenity=restaurant {add name='${cuisine|translate:cuisine}'} Options would be added to mkmap: 1/ to specify a required language; given as a list, in the same manner as browsers, eg --language=en:gb,en 2/ a set of translation files (zip, list, directory or something), These could be simple lists of {language,context,tag,translation} where an empty value takes the previous value, so could have: en,amenity,parking,Parking , ,bench,Bench , ,place_of_worship,Church , ,restaurant,Restaurant or, ordered in a different way: en,barrier,fence,Fence fr, , ,french for fence barrier de, , ,german ... en, ,gate,Gate fr, , ,french for gate There would be a special "common" context that is used if the search for language/context/word fails, or if |translate isn't given a context parameter. As a final resort, the untranslated string is initcap'd and underscores are replaced by spaces. With a bit of trickery anything can be translated: {set whatever='${_|def:strToTranslate|translate}'; ...} Ticker On Fri, 2021-02-12 at 10:19 +0000, Gerd Petermann wrote:
Hi,
reg. barrier names: I don't want those texts in the map at all. I might want to see them when I select the icon to look at the details. I expect strings in the map to be names of objects (streets, cities), not barrier properties. Esp. not in a foreign language. My opinion: If you can't find a good way to render them better don't render them at all.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Freitag, 12. Februar 2021 10:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi Ticker,
in fact 3200 - 3f1f strictly follow their given resolution value - other than e.g. 2a-2f, which only appear at kind of 24+, no matter what resolution is given. Even if both ranges are styled to resolution 24: 2a-2f will always appear a bit later. I suspect that´s what Gerd found to be confusing.
Jan
Am 12.02.2021 um 09:46 schrieb Ticker Berkin < rwb-mkgmap@jagit.co.uk>:
Hi Gerd
The "points" barriers use 0x3200 and I only see these when I "overzoom". I think I configured the device Map Detail levels and Text sizes to get it how I wanted.
I find them useful when walking and sometimes useful for choosing an end-point for car navigation or seeing why a route hasn't been chosen.
"lines" barriers (wall/ditch/etc) again I find useful when walking.
Either of these can commented out by users making their own style starting from default. When I started, the first thing I had to remove were all the low-level administrative boundaries, but I think it right that they are in the default style.
I'd rather not start on other changes until this lot is out of the way.
Ticker
On Thu, 2021-02-11 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
while you are at it: I see lots of rather confusing texts like "gate" or "lift_gate" popping up in the map on my Oregon. I think they might be useful for mappers but they are not very useful for the normal user. Maybe it is only on my device but I don't see any need for this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 11. Februar 2021 15:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.htm l
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
HI Ticker, If you name the typ in the typ file, there should be no need for a default name in the style, and as the typ file already allows multiple languages this should mostly negate the need for a 'translate' function. Of course, this assumes that you don't use a generic typ code for several different objects. Or am I missing something? Regards, Mike -----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 15 February 2021 09:16 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Pending changes Hi Gerd This has always been a problem with styles, encouraged by [... default_name ...], eg: amenity=embassy & country!=* [0x3003 resolution 24 default_name 'Embassy'] amenity=emergency_phone [0x2f12 resolution 24 default_name 'Emergency Phone'] I've added to this in an attempt to provide more useful information for unnamed entities by using constructs like: tourism=* & name!=* & tourism!=yes & tourism!=no {set name='${tourism|subst:"_=> "}'} amenity=restaurant {add name='${cuisine|subst:"_=> "}'} What is needed is another "substitution filter" - translate, that takes an optional parameter "context"; context is normally the name of the tag. The above would read: amenity=embassy & country!=* {add name='${amenity|translate:amenity}'} [0x3003 resolution 24] amenity=emergency_phone {add name='${amenity|translate:amenity}'} [0x2f12 resolution 24 default_name 'Emergency Phone'] tourism=* & name!=* & tourism!=yes & tourism!=no {set name='${tourism|translate:tourism}'} amenity=restaurant {add name='${cuisine|translate:cuisine}'} Options would be added to mkmap: 1/ to specify a required language; given as a list, in the same manner as browsers, eg --language=en:gb,en 2/ a set of translation files (zip, list, directory or something), These could be simple lists of {language,context,tag,translation} where an empty value takes the previous value, so could have: en,amenity,parking,Parking , ,bench,Bench , ,place_of_worship,Church , ,restaurant,Restaurant or, ordered in a different way: en,barrier,fence,Fence fr, , ,french for fence barrier de, , ,german ... en, ,gate,Gate fr, , ,french for gate There would be a special "common" context that is used if the search for language/context/word fails, or if |translate isn't given a context parameter. As a final resort, the untranslated string is initcap'd and underscores are replaced by spaces. With a bit of trickery anything can be translated: {set whatever='${_|def:strToTranslate|translate}'; ...} Ticker On Fri, 2021-02-12 at 10:19 +0000, Gerd Petermann wrote:
Hi,
reg. barrier names: I don't want those texts in the map at all. I might want to see them when I select the icon to look at the details. I expect strings in the map to be names of objects (streets, cities), not barrier properties. Esp. not in a foreign language. My opinion: If you can't find a good way to render them better don't render them at all.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Freitag, 12. Februar 2021 10:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi Ticker,
in fact 3200 - 3f1f strictly follow their given resolution value - other than e.g. 2a-2f, which only appear at kind of 24+, no matter what resolution is given. Even if both ranges are styled to resolution 24: 2a-2f will always appear a bit later. I suspect that´s what Gerd found to be confusing.
Jan
Am 12.02.2021 um 09:46 schrieb Ticker Berkin < rwb-mkgmap@jagit.co.uk>:
Hi Gerd
The "points" barriers use 0x3200 and I only see these when I "overzoom". I think I configured the device Map Detail levels and Text sizes to get it how I wanted.
I find them useful when walking and sometimes useful for choosing an end-point for car navigation or seeing why a route hasn't been chosen.
"lines" barriers (wall/ditch/etc) again I find useful when walking.
Either of these can commented out by users making their own style starting from default. When I started, the first thing I had to remove were all the low-level administrative boundaries, but I think it right that they are in the default style.
I'd rather not start on other changes until this lot is out of the way.
Ticker
On Thu, 2021-02-11 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
while you are at it: I see lots of rather confusing texts like "gate" or "lift_gate" popping up in the map on my Oregon. I think they might be useful for mappers but they are not very useful for the normal user. Maybe it is only on my device but I don't see any need for this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 11. Februar 2021 15:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.htm l
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Mike There are various problems trying to do it as you suggest: If the point is to be indexed, the likelihood is that it hasn't matched a specific instance of the category and so must use the generic 0x00 subtype. The list of values could be long; having to have a rule for each, along with the allocation of a distinct typCode, would be a mess. It wouldn't be able to cope with new, unknown values. I realise that these won't have translations, but just formatting the string is a good start, until a translation can be added. Having to add lots of identical TYP icons just to get translations would also be a mess. I hate having to find/generate icons and maintain them in the TYP file when there are perfectly good ones built into the device simply to get a better description. I haven't found a way of keeping the device icon but changing the string. Ticker On Mon, 2021-02-15 at 12:51 +0000, Mike Baggaley wrote:
HI Ticker,
If you name the typ in the typ file, there should be no need for a default name in the style, and as the typ file already allows multiple languages this should mostly negate the need for a 'translate' function. Of course, this assumes that you don't use a generic typ code for several different objects. Or am I missing something?
Regards, Mike
-----Original Message----- From: Ticker Berkin [mailto:rwb-mkgmap@jagit.co.uk] Sent: 15 February 2021 09:16 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Pending changes
Hi Gerd
This has always been a problem with styles, encouraged by [... default_name ...], eg:
amenity=embassy & country!=* [0x3003 resolution 24 default_name 'Embassy'] amenity=emergency_phone [0x2f12 resolution 24 default_name 'Emergency Phone']
I've added to this in an attempt to provide more useful information for unnamed entities by using constructs like:
tourism=* & name!=* & tourism!=yes & tourism!=no {set name='${tourism|subst:"_=> "}'} amenity=restaurant {add name='${cuisine|subst:"_=> "}'}
What is needed is another "substitution filter" - translate, that takes an optional parameter "context"; context is normally the name of the tag. The above would read:
amenity=embassy & country!=* {add name='${amenity|translate:amenity}'} [0x3003 resolution 24] amenity=emergency_phone {add name='${amenity|translate:amenity}'}
[0x2f12 resolution 24 default_name 'Emergency Phone']
tourism=* & name!=* & tourism!=yes & tourism!=no {set name='${tourism|translate:tourism}'} amenity=restaurant {add name='${cuisine|translate:cuisine}'}
Options would be added to mkmap: 1/ to specify a required language; given as a list, in the same manner as browsers, eg --language=en:gb,en
2/ a set of translation files (zip, list, directory or something), These could be simple lists of {language,context,tag,translation} where an empty value takes the previous value, so could have:
en,amenity,parking,Parking , ,bench,Bench , ,place_of_worship,Church , ,restaurant,Restaurant
or, ordered in a different way:
en,barrier,fence,Fence fr, , ,french for fence barrier de, , ,german ... en, ,gate,Gate fr, , ,french for gate
There would be a special "common" context that is used if the search for language/context/word fails, or if |translate isn't given a context parameter. As a final resort, the untranslated string is initcap'd and underscores are replaced by spaces.
With a bit of trickery anything can be translated:
{set whatever='${_|def:strToTranslate|translate}'; ...}
Ticker
On Fri, 2021-02-12 at 10:19 +0000, Gerd Petermann wrote:
Hi,
reg. barrier names: I don't want those texts in the map at all. I might want to see them when I select the icon to look at the details. I expect strings in the map to be names of objects (streets, cities), not barrier properties. Esp. not in a foreign language. My opinion: If you can't find a good way to render them better don't render them at all.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Freitag, 12. Februar 2021 10:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi Ticker,
in fact 3200 - 3f1f strictly follow their given resolution value - other than e.g. 2a-2f, which only appear at kind of 24+, no matter what resolution is given. Even if both ranges are styled to resolution 24: 2a-2f will always appear a bit later. I suspect that´s what Gerd found to be confusing.
Jan
Am 12.02.2021 um 09:46 schrieb Ticker Berkin < rwb-mkgmap@jagit.co.uk>:
Hi Gerd
The "points" barriers use 0x3200 and I only see these when I "overzoom". I think I configured the device Map Detail levels and Text sizes to get it how I wanted.
I find them useful when walking and sometimes useful for choosing an end-point for car navigation or seeing why a route hasn't been chosen.
"lines" barriers (wall/ditch/etc) again I find useful when walking.
Either of these can commented out by users making their own style starting from default. When I started, the first thing I had to remove were all the low-level administrative boundaries, but I think it right that they are in the default style.
I'd rather not start on other changes until this lot is out of the way.
Ticker
On Thu, 2021-02-11 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
while you are at it: I see lots of rather confusing texts like "gate" or "lift_gate" popping up in the map on my Oregon. I think they might be useful for mappers but they are not very useful for the normal user. Maybe it is only on my device but I don't see any need for this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 11. Februar 2021 15:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.htm l http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.htm l
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.htm l
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.h tm l
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Regarding your extra comment on #3, would it be really the case for bridges? What about any connected highway=* + bridge=yes? No objection for new additional changes El 11/2/21 a las 15:57, Ticker Berkin escribió:
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Carlos Some bridges are a bit of a strange case. There are a lot of areas where I walk that are crossed by many small streams and no formal paths, but, here and there, there are foot bridges over the streams. These are normally mapped as [highway=path/footway, bridge=yes] and mostly don't connect to anything, but sometime to another bridge or a short section of unconnecting path. I want to see these on the map, but the little bits of highway will just cause a routing error if they are picked up as the start or end of a route; hence my changes. The only problem I see is if the bridge/highway is connected to the highway network at one end only and you want to generate a route with the start or end your of your journey the other side of bridge, then the routing algo might find another, closer start/end point. I could change it to be just 'set_unconnected_type' but I considered the benefits and frequency of fixing paired isolated highway bits outweighed an incorrect start/end point, which can be overcome by simply starting the journey in the sensible way and the device will recalculate or looking at the end-point route and, seeing it is stupid, choosing a better end-point. Ticker On Thu, 2021-02-11 at 18:05 +0100, Carlos Dávila wrote:
Regarding your extra comment on #3, would it be really the case for bridges? What about any connected highway=* + bridge=yes?
No objection for new additional changes
El 11/2/21 a las 15:57, Ticker Berkin escribió:
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, I have no idea what to do with patches for default style or typ files. I can decide if I like a patch when I understand what's wrong with the unpatched version, but I don't want to spent my time on cosmetic changes. I simply don't know how to decide if a patch is good or bad unless someone has a good example that shows a problem with the unpatched version (only one problem if possible). I see two ways to handle this: 1) Steve gives Ticker and /or Joris the right to commit changes to trunk or 2) Ticker and Joris create their own branch(es), either in the mkgmap svn repo or somewhere else. ciao, Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 12. Februar 2021 10:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes Hi Carlos Some bridges are a bit of a strange case. There are a lot of areas where I walk that are crossed by many small streams and no formal paths, but, here and there, there are foot bridges over the streams. These are normally mapped as [highway=path/footway, bridge=yes] and mostly don't connect to anything, but sometime to another bridge or a short section of unconnecting path. I want to see these on the map, but the little bits of highway will just cause a routing error if they are picked up as the start or end of a route; hence my changes. The only problem I see is if the bridge/highway is connected to the highway network at one end only and you want to generate a route with the start or end your of your journey the other side of bridge, then the routing algo might find another, closer start/end point. I could change it to be just 'set_unconnected_type' but I considered the benefits and frequency of fixing paired isolated highway bits outweighed an incorrect start/end point, which can be overcome by simply starting the journey in the sensible way and the device will recalculate or looking at the end-point route and, seeing it is stupid, choosing a better end-point. Ticker On Thu, 2021-02-11 at 18:05 +0100, Carlos Dávila wrote:
Regarding your extra comment on #3, would it be really the case for bridges? What about any connected highway=* + bridge=yes?
No objection for new additional changes
El 11/2/21 a las 15:57, Ticker Berkin escribió:
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd My views on this. For most of mkgmap /resources/ (styles, typ-files, documentation, roadNameConfig.txt, sample.cfg) you don't need to decide if the change is good or bad, and, almost by definition, it is all cosmetic. Change requests go through this forum for discussion. After any refinements necessary, the changes can be incorporated into trunk. It is very unlikely that this will cause Map generation will become 'broken'. Mostly, it seems, no one much cares because they use their own styles, TYP files etc. I view the default style (and the other resources) as a starting point for new users and a source of ideas for existing users. It is the ideal place to put rules/comments on any sort of issue that can be addressed by a style. Generally, more is better; it is easy for a new user to start with lots and gradually comment out elements they don't want. Whenever I notice something that could be improved on my maps, or a good idea floating around the forum, I incorporated it into my files and try it. Every now and again, I try to get what I consider improvements into mkgmap. This isn't for my benefit but, I hope, other people might benefit from it. Similarly, mapnik.txt is a good place to put element translations (it would be nice if we came up with a mechanism where this translation effort could be shared by any TYP file). The core/java code is a different matter and I'm very grateful for your amazing work on "keeping it all together" Ticker On Fri, 2021-02-12 at 09:51 +0000, Gerd Petermann wrote:
Hi all,
I have no idea what to do with patches for default style or typ files. I can decide if I like a patch when I understand what's wrong with the unpatched version, but I don't want to spent my time on cosmetic changes. I simply don't know how to decide if a patch is good or bad unless someone has a good example that shows a problem with the unpatched version (only one problem if possible).
I see two ways to handle this: 1) Steve gives Ticker and /or Joris the right to commit changes to trunk or 2) Ticker and Joris create their own branch(es), either in the mkgmap svn repo or somewhere else.
ciao, Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 12. Februar 2021 10:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi Carlos
Some bridges are a bit of a strange case. There are a lot of areas where I walk that are crossed by many small streams and no formal paths, but, here and there, there are foot bridges over the streams. These are normally mapped as [highway=path/footway, bridge=yes] and mostly don't connect to anything, but sometime to another bridge or a short section of unconnecting path.
I want to see these on the map, but the little bits of highway will just cause a routing error if they are picked up as the start or end of a route; hence my changes.
The only problem I see is if the bridge/highway is connected to the highway network at one end only and you want to generate a route with the start or end your of your journey the other side of bridge, then the routing algo might find another, closer start/end point.
I could change it to be just 'set_unconnected_type' but I considered the benefits and frequency of fixing paired isolated highway bits outweighed an incorrect start/end point, which can be overcome by simply starting the journey in the sensible way and the device will recalculate or looking at the end-point route and, seeing it is stupid, choosing a better end-point.
Ticker
On Thu, 2021-02-11 at 18:05 +0100, Carlos Dávila wrote:
Regarding your extra comment on #3, would it be really the case for bridges? What about any connected highway=* + bridge=yes?
No objection for new additional changes
El 11/2/21 a las 15:57, Ticker Berkin escribió:
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.htm l
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, I agree that the default style is a starting point and because of that I think "less is better": 1) The more stuff we put into the default style the less likely it becomes that a newbe will try to understand it. I think it is more likely that users will try to add a rule for something that they miss instead of working through hundredts of complicated rules to find out what can be (hast to be) removed without risking to loose anything important. 2) The screens of many (most?) Garmin devices are too small for lots of details, the details are simply confusing anyone who's not interested in OSM but just wants a routable map for free. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 17. Februar 2021 10:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes Hi Gerd My views on this. For most of mkgmap /resources/ (styles, typ-files, documentation, roadNameConfig.txt, sample.cfg) you don't need to decide if the change is good or bad, and, almost by definition, it is all cosmetic. Change requests go through this forum for discussion. After any refinements necessary, the changes can be incorporated into trunk. It is very unlikely that this will cause Map generation will become 'broken'. Mostly, it seems, no one much cares because they use their own styles, TYP files etc. I view the default style (and the other resources) as a starting point for new users and a source of ideas for existing users. It is the ideal place to put rules/comments on any sort of issue that can be addressed by a style. Generally, more is better; it is easy for a new user to start with lots and gradually comment out elements they don't want. Whenever I notice something that could be improved on my maps, or a good idea floating around the forum, I incorporated it into my files and try it. Every now and again, I try to get what I consider improvements into mkgmap. This isn't for my benefit but, I hope, other people might benefit from it. Similarly, mapnik.txt is a good place to put element translations (it would be nice if we came up with a mechanism where this translation effort could be shared by any TYP file). The core/java code is a different matter and I'm very grateful for your amazing work on "keeping it all together" Ticker On Fri, 2021-02-12 at 09:51 +0000, Gerd Petermann wrote:
Hi all,
I have no idea what to do with patches for default style or typ files. I can decide if I like a patch when I understand what's wrong with the unpatched version, but I don't want to spent my time on cosmetic changes. I simply don't know how to decide if a patch is good or bad unless someone has a good example that shows a problem with the unpatched version (only one problem if possible).
I see two ways to handle this: 1) Steve gives Ticker and /or Joris the right to commit changes to trunk or 2) Ticker and Joris create their own branch(es), either in the mkgmap svn repo or somewhere else.
ciao, Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 12. Februar 2021 10:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi Carlos
Some bridges are a bit of a strange case. There are a lot of areas where I walk that are crossed by many small streams and no formal paths, but, here and there, there are foot bridges over the streams. These are normally mapped as [highway=path/footway, bridge=yes] and mostly don't connect to anything, but sometime to another bridge or a short section of unconnecting path.
I want to see these on the map, but the little bits of highway will just cause a routing error if they are picked up as the start or end of a route; hence my changes.
The only problem I see is if the bridge/highway is connected to the highway network at one end only and you want to generate a route with the start or end your of your journey the other side of bridge, then the routing algo might find another, closer start/end point.
I could change it to be just 'set_unconnected_type' but I considered the benefits and frequency of fixing paired isolated highway bits outweighed an incorrect start/end point, which can be overcome by simply starting the journey in the sensible way and the device will recalculate or looking at the end-point route and, seeing it is stupid, choosing a better end-point.
Ticker
On Thu, 2021-02-11 at 18:05 +0100, Carlos Dávila wrote:
Regarding your extra comment on #3, would it be really the case for bridges? What about any connected highway=* + bridge=yes?
No objection for new additional changes
El 11/2/21 a las 15:57, Ticker Berkin escribió:
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.htm l
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
HI all I agree with Ticker default style is a good source of ideas for both new and experienced users (at least it is to me) and as such, more is better, but I also see Gerd's point about new users getting blocked by too many or complicated rules. I think comments about those complicated rules, as Ticker adds in some cases, may help circumvent that problem, or may be some kind of <advanced></advanced> tagging. El 17/2/21 a las 11:02, Gerd Petermann escribió:
Hi Ticker,
I agree that the default style is a starting point and because of that I think "less is better": 1) The more stuff we put into the default style the less likely it becomes that a newbe will try to understand it. I think it is more likely that users will try to add a rule for something that they miss instead of working through hundredts of complicated rules to find out what can be (hast to be) removed without risking to loose anything important. 2) The screens of many (most?) Garmin devices are too small for lots of details, the details are simply confusing anyone who's not interested in OSM but just wants a routable map for free.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 17. Februar 2021 10:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi Gerd
My views on this.
For most of mkgmap /resources/ (styles, typ-files, documentation, roadNameConfig.txt, sample.cfg) you don't need to decide if the change is good or bad, and, almost by definition, it is all cosmetic.
Change requests go through this forum for discussion. After any refinements necessary, the changes can be incorporated into trunk. It is very unlikely that this will cause Map generation will become 'broken'. Mostly, it seems, no one much cares because they use their own styles, TYP files etc.
I view the default style (and the other resources) as a starting point for new users and a source of ideas for existing users.
It is the ideal place to put rules/comments on any sort of issue that can be addressed by a style. Generally, more is better; it is easy for a new user to start with lots and gradually comment out elements they don't want.
Whenever I notice something that could be improved on my maps, or a good idea floating around the forum, I incorporated it into my files and try it. Every now and again, I try to get what I consider improvements into mkgmap. This isn't for my benefit but, I hope, other people might benefit from it.
Similarly, mapnik.txt is a good place to put element translations (it would be nice if we came up with a mechanism where this translation effort could be shared by any TYP file).
The core/java code is a different matter and I'm very grateful for your amazing work on "keeping it all together"
Ticker
On Fri, 2021-02-12 at 09:51 +0000, Gerd Petermann wrote:
Hi all,
I have no idea what to do with patches for default style or typ files. I can decide if I like a patch when I understand what's wrong with the unpatched version, but I don't want to spent my time on cosmetic changes. I simply don't know how to decide if a patch is good or bad unless someone has a good example that shows a problem with the unpatched version (only one problem if possible).
I see two ways to handle this: 1) Steve gives Ticker and /or Joris the right to commit changes to trunk or 2) Ticker and Joris create their own branch(es), either in the mkgmap svn repo or somewhere else.
ciao, Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 12. Februar 2021 10:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Pending changes
Hi Carlos
Some bridges are a bit of a strange case. There are a lot of areas where I walk that are crossed by many small streams and no formal paths, but, here and there, there are foot bridges over the streams. These are normally mapped as [highway=path/footway, bridge=yes] and mostly don't connect to anything, but sometime to another bridge or a short section of unconnecting path.
I want to see these on the map, but the little bits of highway will just cause a routing error if they are picked up as the start or end of a route; hence my changes.
The only problem I see is if the bridge/highway is connected to the highway network at one end only and you want to generate a route with the start or end your of your journey the other side of bridge, then the routing algo might find another, closer start/end point.
I could change it to be just 'set_unconnected_type' but I considered the benefits and frequency of fixing paired isolated highway bits outweighed an incorrect start/end point, which can be overcome by simply starting the journey in the sensible way and the device will recalculate or looking at the end-point route and, seeing it is stupid, choosing a better end-point.
Ticker
On Thu, 2021-02-11 at 18:05 +0100, Carlos Dávila wrote:
Regarding your extra comment on #3, would it be really the case for bridges? What about any connected highway=* + bridge=yes?
No objection for new additional changes
El 11/2/21 a las 15:57, Ticker Berkin escribió:
Hi all
I've re-made this set of changes, along with a few improvements that I've gathered over the last 6 months. Following list numbering is the same as original patch, but include some [extra] notes + new items at the end.
Relevant threads: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
1/ Sometimes charges for using a pedestrian highway are expressed as a fee rather than a toll, so pick this up in mkgmap:toll.
2/ Show bridges using type 0x10107. With the mapnik addition, these look good for narrow highways, but might not show for wide representations like motorways.
3/ Where it is likely that bits of highway might not be connected to the road/path system, use mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is being suspected of causing problems on some devices and BaseCamp.
[extra] In all cases where unconnected/semi-connected changes are mentioned, this only applies to lines not derived from an original/OSM standard highway.
4/ Quote some filter subst strings that contain spaces - no actual effect but clearer and safer.
5/ Have line for leisure=track even if area.
6/ Change the type for tracks/raceways etc from 0x30, which doesn't show on BaseCamp or MapSource, to 0x2a.
7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction: Pier or Jetty) instead of footway.
8/ Change type for the various barriers from 0x17, which doesn't show on BaseCamp to 0x2b, see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
9/ Consider natural=cliff a barrier.
10/ Add motorway[_link] roundabouts (yes, some do exist).
11/ Unquote some numbers - no actual effect.
12/ Tweak some road speeds. [extra] A few more tweaked.
13/ Use 0x09 (high-speed ramp) for road class 4 links
14/ Add footway around car parks if 'connecting'. [extra] This change is disabled.
15/ Disable coastline. For a long time the tag was suppressed by the Sea processing and it adds little to the map.
16/ Improve railway platform names and suppress footway if not 'connecting'.
17/ Show disused:railway in the same way as railway=disused.
18/ Have cable_car, gondola, funicular as routable, by default with a toll and pedestrian only.
19/ Show "Course of old Railway", unless a highway has taken over the way (for you Eric, but I like it as well). [extra] This change is disabled
20/ Speed up car ferries.
21/ A few other layout/space fixes.
Additional changes:
22/ motorroad=yes just sets mkgmap:fast_road, which generally increases the speed/class of the highway and decreases the resolution
23/ natural=landslide like other barriers (eg cliff)
24/ Don't generate (routable) line for highway=unclassified & area=yes; there are many instances in OSM where this is used to draw a polygon around a complex junction.
25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
26/ For ferry/platform/aerialway, blank out address fields to prevent it getting into the Address index
27/ Add comment about colour pallet to mapnik.txt
Patch attached
Ticker
On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
On [1] Ticker proposed a set of changes to default style lines file. There was a long discussion about point #14, which ended without a consensus. Other changes didn't get any objection, but they didn't get into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 and 16, but for unconnected ways only, see #3.
2: more codes could be added for wider highways and their corresponding entries in mapnik.txt
3: not sure about this one, specially about semi-connected ways, which I think should remain as routable (also applies for 7, 16).
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.htm l
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
Carlos Dávila -
Gerd Petermann -
jan meisters -
Mike Baggaley -
Ticker Berkin