default style improvements
Hi I'd like to make quite a few changes and improvements to the default style. Some of these should be non-contentious: The first change I propose is to make the layout consistent and clearer and I've attached a patch to do this for the points/lines/polygons files. The only change here is white-space (blanks, tabs, new-lines), no other characters have been changed. I've used: $ java ... uk.me.parabola.mkgmap.osmstyle.StyleImpl pathTo/default to check there are no semantic changes, but this program fails to dump the <finalize> section, so I've checked these very carefully via other methods. Next changes I am thinking of are: Simple layout where character changes are involved Provide more information on unnamed objects where a good garmin mapping hasn't been found, eg, after all the shop=known ... lines there is a mop-up: shop=* & shop!=no & shop!=none [0x2e0c resolution 24] changing this to: shop=* & shop!=no & shop!=none {add name='${shop|subst:"_=> "}'} [0x2e0c resolution 24] will name unnamed shops with the value of the shop tag. There are about 15 sections that benefit from this. Add more commonly used tag-values, eg: tourism=bed_and_breakfast [0x2b02 resolution 24] and other mop-ups I think these sort of changes should be applied to the trunk After this, the changes I'm thinking of will require more discussion. Regards Ticker
Hi Ticker, reg. the curly brackets in the barrier section I must say that i don't like the old style as well as your new one ;-) I would put the closing bracket without indention: barrier=bollard | barrier=cycle_barrier { add mkgmap:bicycle=yes; add mkgmap:foot=yes; addaccess no; set mkgmap:road-speed=1; } Besides that the changes are OK for me. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 12. November 2018 13:03 An: mkgmap development Betreff: [mkgmap-dev] default style improvements Hi I'd like to make quite a few changes and improvements to the default style. Some of these should be non-contentious: The first change I propose is to make the layout consistent and clearer and I've attached a patch to do this for the points/lines/polygons files. The only change here is white-space (blanks, tabs, new-lines), no other characters have been changed. I've used: $ java ... uk.me.parabola.mkgmap.osmstyle.StyleImpl pathTo/default to check there are no semantic changes, but this program fails to dump the <finalize> section, so I've checked these very carefully via other methods. Next changes I am thinking of are: Simple layout where character changes are involved Provide more information on unnamed objects where a good garmin mapping hasn't been found, eg, after all the shop=known ... lines there is a mop-up: shop=* & shop!=no & shop!=none [0x2e0c resolution 24] changing this to: shop=* & shop!=no & shop!=none {add name='${shop|subst:"_=> "}'} [0x2e0c resolution 24] will name unnamed shops with the value of the shop tag. There are about 15 sections that benefit from this. Add more commonly used tag-values, eg: tourism=bed_and_breakfast [0x2b02 resolution 24] and other mop-ups I think these sort of changes should be applied to the trunk After this, the changes I'm thinking of will require more discussion. Regards Ticker
Hi Gerd I thought of doing it as you suggest but then it's wrong when there is a [type ...] part, which I also want indented, ie some condition { action1; action2; ... } [0x01 resolution 20] not that I can find any examples. And I feel that its clearer that all parts of a continuation of a rule are indented. Ticker On Mon, 2018-11-12 at 14:55 +0000, Gerd Petermann wrote:
Hi Ticker,
reg. the curly brackets in the barrier section I must say that i don't like the old style as well as your new one ;-) I would put the closing bracket without indention: barrier=bollard | barrier=cycle_barrier { add mkgmap:bicycle=yes; add mkgmap:foot=yes; addaccess no; set mkgmap:road-speed=1; }
Besides that the changes are OK for me.
Gerd
Hi Ticker, OK, got your point. If no one complains I'll commit that patch on thursday. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 12. November 2018 16:19 An: mkgmap development Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd I thought of doing it as you suggest but then it's wrong when there is a [type ...] part, which I also want indented, ie some condition { action1; action2; ... } [0x01 resolution 20] not that I can find any examples. And I feel that its clearer that all parts of a continuation of a rule are indented. Ticker On Mon, 2018-11-12 at 14:55 +0000, Gerd Petermann wrote:
Hi Ticker,
reg. the curly brackets in the barrier section I must say that i don't like the old style as well as your new one ;-) I would put the closing bracket without indention: barrier=bollard | barrier=cycle_barrier { add mkgmap:bicycle=yes; add mkgmap:foot=yes; addaccess no; set mkgmap:road-speed=1; }
Besides that the changes are OK for me.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
All I'd like any thoughts on changing and introducing new element TYPE numbers for various OSM objects. I propose: POINTS: Use 0x2f0c instead of 0x4e00 for amenity=toilet always. 0x4e00 isn't findable. 0x2f0c is "Other:Rest Area/Tourist Info". Use 0x3200 instead of 0x660f for barrier=bollard barrier=...etc. 0x660f is "Land Features:Pillar" and so they all show in FIND, making searching for nearby features less useful. 0x3200 is a small point, that can be labeled with the type of barrier. Use 0x6505 instead of 0x6603 for water=canal, lock 0x6603 is "Land Features:Basin"; 0x6505 is "Water Features:Canal" LINES: Use 0x11 instead of 0x07 for highway=cycleway Suggested by Joris Bo. 0x07 is Alley and is already used for highway=bridleway, service, mop-up Use 0x13 for highway=raceway This isn't handled at the moment and falls into the highway mop-up Use 0x17 for various linear barriers and also man_made=breakwater Use 0x1a for car ferries, 0x1b for other ferries At the moment 0x1b is used for all ferries Use 0x26 instead of 0x10a02 for intermittent steam & drain @gerd - slightly concerned about func in mkgmap/reader/osm/GType.java: public static boolean isSpecialRoutableLineType(int type){ return type >= 0x01 && type <= 0x13 || type == 0x16 || type == 0x1b; POLYGONS: Use 0x02 for place=suburb Use 0x0f instead of 0x0c for landuse=commercial Use 0x10 only for landuse=residential Currently also used for farmyard Use 0x11 instead of 0x04 for military=danger_area This often covers a large area of other mixed use, and rendering it with parts transparent is much more informative Use 0x12 instead of 0x08 for landuse=retail Use 0x13 only for building=* Currently also used for amenity=* and man_made=... Type 0x17, which shows as "Park" in green, is currently used for these OSM objects: park,playground,common,garden,greenfield,meadow,grass,village_green,squ are/plaza Keep this mapping for leisure=park, playground Use 0x15 for landuse=village_green Use 0x1c for landuse=meadow, grass, greenfield, farmland Use 0x1d for leisure=common Use 0x20 for leisure=garden Use 0x25 for square/plaza Use 0x1b instead of 0x10 for landuse=farmyard Use 0x1b instead of 0x4e for landuse=farm Use 0x21 instead of 0x1f for tourism=... Use 0x22 instead of 0x1e for historic=... Use 0x23 instead of 0x13 for mop-up amenity=* Use 0x24 instead of 0x13 for man_made=... Use 0x3b for mop-up waterway=* Use 0x41 instead of 0x3c for small lakes Use 0x48 for water=canal Use 0x4c for water=lock Use 0x4c for dock=drydock This is "Intermittant Water" Use 0x53 for natural=beach, sand Suggested by Nick / Minko 27Sep18 Use 0x53 instead of 0x51 for natural=mud Use 0x56 instead of 0x53 for small named islands/islets And render as transparent/invisible Use 0x58 for adminin boundary=ceremonial, eg UK counties And render as transparent/invisible Thanks Ticker
Hello Ticker and All In general i 'm fine with the suggestions for new elements .
From a default style point of view I think we better not use 'mop-up' features at all but only use strictly defined elements.
Mop up rules and [tag = *] will always somewhere create unexpected behaviour (popup of fixme bugs, strange lines, rarely used elements) where defined elements will give us a more maintainable control over future change requests without disappointing current users who at the moment rely on the unpredictable mop-up rules. Just let me know what the final style will be and I'll reflect these changes against the TYP-file proposal. Kind regards, Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Ticker Berkin Verzonden: dinsdag 13 november 2018 18:26 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] default style improvements All I'd like any thoughts on changing and introducing new element TYPE numbers for various OSM objects. I propose: POINTS: Use 0x2f0c instead of 0x4e00 for amenity=toilet always. 0x4e00 isn't findable. 0x2f0c is "Other:Rest Area/Tourist Info". Use 0x3200 instead of 0x660f for barrier=bollard barrier=...etc. 0x660f is "Land Features:Pillar" and so they all show in FIND, making searching for nearby features less useful. 0x3200 is a small point, that can be labeled with the type of barrier. Use 0x6505 instead of 0x6603 for water=canal, lock 0x6603 is "Land Features:Basin"; 0x6505 is "Water Features:Canal" LINES: Use 0x11 instead of 0x07 for highway=cycleway Suggested by Joris Bo. 0x07 is Alley and is already used for highway=bridleway, service, mop-up Use 0x13 for highway=raceway This isn't handled at the moment and falls into the highway mop-up Use 0x17 for various linear barriers and also man_made=breakwater Use 0x1a for car ferries, 0x1b for other ferries At the moment 0x1b is used for all ferries Use 0x26 instead of 0x10a02 for intermittent steam & drain @gerd - slightly concerned about func in mkgmap/reader/osm/GType.java: public static boolean isSpecialRoutableLineType(int type){ return type >= 0x01 && type <= 0x13 || type == 0x16 || type == 0x1b; POLYGONS: Use 0x02 for place=suburb Use 0x0f instead of 0x0c for landuse=commercial Use 0x10 only for landuse=residential Currently also used for farmyard Use 0x11 instead of 0x04 for military=danger_area This often covers a large area of other mixed use, and rendering it with parts transparent is much more informative Use 0x12 instead of 0x08 for landuse=retail Use 0x13 only for building=* Currently also used for amenity=* and man_made=... Type 0x17, which shows as "Park" in green, is currently used for these OSM objects: park,playground,common,garden,greenfield,meadow,grass,village_green,squ are/plaza Keep this mapping for leisure=park, playground Use 0x15 for landuse=village_green Use 0x1c for landuse=meadow, grass, greenfield, farmland Use 0x1d for leisure=common Use 0x20 for leisure=garden Use 0x25 for square/plaza Use 0x1b instead of 0x10 for landuse=farmyard Use 0x1b instead of 0x4e for landuse=farm Use 0x21 instead of 0x1f for tourism=... Use 0x22 instead of 0x1e for historic=... Use 0x23 instead of 0x13 for mop-up amenity=* Use 0x24 instead of 0x13 for man_made=... Use 0x3b for mop-up waterway=* Use 0x41 instead of 0x3c for small lakes Use 0x48 for water=canal Use 0x4c for water=lock Use 0x4c for dock=drydock This is "Intermittant Water" Use 0x53 for natural=beach, sand Suggested by Nick / Minko 27Sep18 Use 0x53 instead of 0x51 for natural=mud Use 0x56 instead of 0x53 for small named islands/islets And render as transparent/invisible Use 0x58 for adminin boundary=ceremonial, eg UK counties And render as transparent/invisible Thanks Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Here is a patch to change some TYPE element numbers in default/points: Changes are: Always use 0x2f0c instead of 0x4e00 for amenity=toilet. 0x4e00 isn't findable. 0x2f0c is "Other:Rest Area/Tourist Info". add: tourism=resort [0x2b04 resolution 24] This is searchable under the "Lodgings" > "Resort" category on some devices Use 0x3200 instead of 0x660f for barrier=bollard barrier=...etc. 0x660f is "Land Features:Pillar" and so they all show in FIND, making searching for nearby features less useful. 0x3200 is a small point, that can be labeled with the type of barrier Regards Ticker
Hi Gerd Given the lack of comments and objections, can you apply my 3 patches to default style points/lines/polygons from 21-Jan Thanks Ticker
Hi Ticker, I'd prefer to get some positive feedback. I did not even try to understand the reasons for all these changes because I hoped for some feedback from the other typ file experts. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 5. Februar 2019 09:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd Given the lack of comments and objections, can you apply my 3 patches to default style points/lines/polygons from 21-Jan Thanks Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, I'm not sure if I've seen changes from 21st of Jan. I tested r 4262 and it is working very well for me. Just adopted some resolutions of lines according to my personal flavour. Regards, Michael -----Ursprüngliche Nachricht----- Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Im Auftrag von Gerd Petermann Gesendet: Dienstag, 5. Februar 2019 09:26 An: Ticker Berkin <rwb-mkgmap@jagit.co.uk>; Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] default style improvements Hi Ticker, I'd prefer to get some positive feedback. I did not even try to understand the reasons for all these changes because I hoped for some feedback from the other typ file experts. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 5. Februar 2019 09:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd Given the lack of comments and objections, can you apply my 3 patches to default style points/lines/polygons from 21-Jan Thanks Ticker _______________________________________________ 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 Michael The changes to the default style haven't been applied and released yet. There were in 3 posts on 21-Jan around 06:30. Regards Ticker On Sat, 2019-02-09 at 07:49 +0100, Michael Poesdorf wrote:
Hi Ticker,
I'm not sure if I've seen changes from 21st of Jan. I tested r 4262 and it is working very well for me. Just adopted some resolutions of lines according to my personal flavour.
Regards, Michael
-----Ursprüngliche Nachricht----- Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Im Auftrag von Gerd Petermann Gesendet: Dienstag, 5. Februar 2019 09:26 An: Ticker Berkin <rwb-mkgmap@jagit.co.uk>; Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] default style improvements
Hi Ticker,
I'd prefer to get some positive feedback. I did not even try to understand the reasons for all these changes because I hoped for some feedback from the other typ file experts.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 5. Februar 2019 09:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Given the lack of comments and objections, can you apply my 3 patches to default style points/lines/polygons from 21-Jan
Thanks Ticker
_______________________________________________ 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 think I found the posts for polygons, lines and points. I will have a look into it on the weekend. Regards, Michael -----Ursprüngliche Nachricht----- Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Im Auftrag von Ticker Berkin Gesendet: Montag, 11. Februar 2019 20:43 An: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] default style improvements Hi Michael The changes to the default style haven't been applied and released yet. There were in 3 posts on 21-Jan around 06:30. Regards Ticker On Sat, 2019-02-09 at 07:49 +0100, Michael Poesdorf wrote:
Hi Ticker,
I'm not sure if I've seen changes from 21st of Jan. I tested r 4262 and it is working very well for me. Just adopted some resolutions of lines according to my personal flavour.
Regards, Michael
-----Ursprüngliche Nachricht----- Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Im Auftrag von Gerd Petermann Gesendet: Dienstag, 5. Februar 2019 09:26 An: Ticker Berkin <rwb-mkgmap@jagit.co.uk>; Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] default style improvements
Hi Ticker,
I'd prefer to get some positive feedback. I did not even try to understand the reasons for all these changes because I hoped for some feedback from the other typ file experts.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 5. Februar 2019 09:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Given the lack of comments and objections, can you apply my 3 patches to default style points/lines/polygons from 21-Jan
Thanks Ticker
_______________________________________________ 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
Hello Ticker I had a look into the 3 mails/proposals of yours. Point and Lines are in a way easy. More interesting is the look into the polygons. To get the map impression I implemented the changes to polygons, lines and points of r4268. I also modified the mapnik.typ. Please find the relevant files attached. Maybe someone else wants to have a look. Recognize changed style lines by my comments starting with ###. The added polygons in the typ-file should be easily recognizable. Also the lines and points. Please have a look at these 3 topics: 1) “Park”. There is already 0x17. You ask for 0x1e and 0x1f, also as “Park”. Not sure if we need this kind of differentiation. 0x1e is not on the typ - I created a 0x1f. 2) landuse=retail, 0x12. What is the difference to “Shopping center”? Nevertheless implemented in the typ. 3) 0x17 – the Park-topic I implemented the requested typs also. And I understand that there are many different usages for areas. The problem that I see is the colouring. We might get many quite similar coloured areas. Fifty shades of green. Maybe recognizable in Basecamp on a computer, but not that easy to distinguish on devices (like my Montana 610). In case DEM is used, all the flavours become darker. Night colours not considered. It is do-able, but requires some a sense for colours. With landuse=farmland I had to split that line into two, to follow your idea. You will see it from the comments. To sum up: It works for me. If we do the changes to the default style, we should also change the default typ-file with some reasonable colouring. Maybe Joris could comment what is do-able in the mapnik colour schema. @ Gerd: Could you check the latest releases, please. I cannot find the mapnik.txt in the zip. Cheers, Michael -----Ursprüngliche Nachricht----- Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Im Auftrag von Ticker Berkin Gesendet: Montag, 11. Februar 2019 20:43 An: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] default style improvements Hi Michael The changes to the default style haven't been applied and released yet. There were in 3 posts on 21-Jan around 06:30. Regards Ticker On Sat, 2019-02-09 at 07:49 +0100, Michael Poesdorf wrote:
Hi Ticker,
I'm not sure if I've seen changes from 21st of Jan. I tested r 4262 and it is working very well for me. Just adopted some resolutions of lines according to my personal flavour.
Regards, Michael
-----Ursprüngliche Nachricht----- Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Im Auftrag von Gerd Petermann Gesendet: Dienstag, 5. Februar 2019 09:26 An: Ticker Berkin <rwb-mkgmap@jagit.co.uk>; Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] default style improvements
Hi Ticker,
I'd prefer to get some positive feedback. I did not even try to understand the reasons for all these changes because I hoped for some feedback from the other typ file experts.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 5. Februar 2019 09:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Given the lack of comments and objections, can you apply my 3 patches to default style points/lines/polygons from 21-Jan
Thanks Ticker
_______________________________________________ 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
Hello Michael Thank you for your work checking all of this and your feedback. See embedded for my comments. Kind regards Ticker On Sun, 2019-02-17 at 11:01 +0100, Michael Poesdorf wrote:
Hello Ticker
I had a look into the 3 mails/proposals of yours. Point and Lines are in a way easy. More interesting is the look into the polygons.
Other users need to be slightly aware that the versions of points, lines & polygons you attached are slightly different from the result of applying my patches.
To get the map impression I implemented the changes to polygons, lines and points of r4268. I also modified the mapnik.typ. Please find the relevant files attached. Maybe someone else wants to have a look. Recognize changed style lines by my comments starting with ###. The added polygons in the typ-file should be easily recognizable. Also the lines and points.
Please have a look at these 3 topics: 1) “Park”. There is already 0x17. You ask for 0x1e and 0x1f, also as “Park”. Not sure if we need this kind of differentiation. 0x1e is not on the typ - I created a 0x1f.
I had various objectives. The main one was to stop the overloading of type 0x17 for 9 different OSM objects. My Garmin device, without a TYP file, shows types 0x14 to 0x17 and 0x1e to 0x20 as green, with label 'Park' and 0x1b to 0x1d as green with label 'Area'. So I moved some of the overloaded OSM objects where green would be a good representation to other, unused green areas and, where green is not a good colour (eg square/plaza) to unused types elsewhere. I also moved other OSM objects that were in this 'green' range, but green is not a sensible representation, elsewhere So, without a typ-file the representation should be reasonable and, with a typ-file, each area can be labeled correctly and the representation can chosen appropriately.
2) landuse=retail, 0x12. What is the difference to “Shopping center”? Nevertheless implemented in the typ.
My interpretation is that Garmin type 0x08, labeled "Shopping center" is used for buildings, eg actual shops or a number of shops and maybe some supporting services within a single building (ie a shopping centre), whereas landuse=retail is an area that people go to shop, so it will have lots of buildings (shops and eating places possibly), car parks, maybe petrol etc. For this I've introduced previously unused type 0x12
3) 0x17 – the Park-topic I implemented the requested typs also. And I understand that there are many different usages for areas. The problem that I see is the colouring. We might get many quite similar coloured areas. Fifty shades of green. Maybe recognizable in Basecamp on a computer, but not that easy to distinguish on devices (like my Montana 610).
I agree that it is difficult to differentiate all the colours that could be used, but it is now the choice of the typ-file. I use a very limited set of colours: green for farmland/meadow/park/grass etc. light yellow for built areas (including residential, farm/yard, suburb, village, commercial, retail). brown (brick colour) for building, shopping center, historic, amenity. striped green/transparent for nature reserve. striped red/transparent for danger area. pinkish for square/plaza. and the default Garmin representation for everything else.
In case DEM is used, all the flavours become darker. Night colours not considered. It is do-able, but requires some a sense for colours. With landuse=farmland I had to split that line into two, to follow your idea. You will see it from the comments.
I had already split these: landuse=farm [0x26 resolution 22] landuse=farmland [0x1c resolution 20] landuse=farmyard [0x26 resolution 22] but I'd made minimal reorganisation of the file in this iteration because I just wanted to concentrate on the type changes.
To sum up: It works for me. If we do the changes to the default style, we should also change the default typ-file with some reasonable colouring. Maybe Joris could comment what is do-able in the mapnik colour schema.
@ Gerd: Could you check the latest releases, please. I cannot find the mapnik.txt in the zip.
Cheers, Michael
Hello Ticker, thanks for your detailed explanations. The colours and appearance from the typ-file is quite individual, so I followed the idea of creating a map without a typ-file. Checking several familiar spots in Europe I find, that it is working with the changes and my Montana 610. Kind regards, Michael -----Ursprüngliche Nachricht----- Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Im Auftrag von Ticker Berkin Gesendet: Dienstag, 19. Februar 2019 11:57 An: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] default style improvements Hello Michael Thank you for your work checking all of this and your feedback. See embedded for my comments. Kind regards Ticker On Sun, 2019-02-17 at 11:01 +0100, Michael Poesdorf wrote:
Hello Ticker
I had a look into the 3 mails/proposals of yours. Point and Lines are in a way easy. More interesting is the look into the polygons.
Other users need to be slightly aware that the versions of points, lines & polygons you attached are slightly different from the result of applying my patches.
To get the map impression I implemented the changes to polygons, lines and points of r4268. I also modified the mapnik.typ. Please find the relevant files attached. Maybe someone else wants to have a look. Recognize changed style lines by my comments starting with ###. The added polygons in the typ-file should be easily recognizable. Also the lines and points.
Please have a look at these 3 topics: 1) “Park”. There is already 0x17. You ask for 0x1e and 0x1f, also as “Park”. Not sure if we need this kind of differentiation. 0x1e is not on the typ - I created a 0x1f.
I had various objectives. The main one was to stop the overloading of type 0x17 for 9 different OSM objects. My Garmin device, without a TYP file, shows types 0x14 to 0x17 and 0x1e to 0x20 as green, with label 'Park' and 0x1b to 0x1d as green with label 'Area'. So I moved some of the overloaded OSM objects where green would be a good representation to other, unused green areas and, where green is not a good colour (eg square/plaza) to unused types elsewhere. I also moved other OSM objects that were in this 'green' range, but green is not a sensible representation, elsewhere So, without a typ-file the representation should be reasonable and, with a typ-file, each area can be labeled correctly and the representation can chosen appropriately.
2) landuse=retail, 0x12. What is the difference to “Shopping center”? Nevertheless implemented in the typ.
My interpretation is that Garmin type 0x08, labeled "Shopping center" is used for buildings, eg actual shops or a number of shops and maybe some supporting services within a single building (ie a shopping centre), whereas landuse=retail is an area that people go to shop, so it will have lots of buildings (shops and eating places possibly), car parks, maybe petrol etc. For this I've introduced previously unused type 0x12
3) 0x17 – the Park-topic I implemented the requested typs also. And I understand that there are many different usages for areas. The problem that I see is the colouring. We might get many quite similar coloured areas. Fifty shades of green. Maybe recognizable in Basecamp on a computer, but not that easy to distinguish on devices (like my Montana 610).
I agree that it is difficult to differentiate all the colours that could be used, but it is now the choice of the typ-file. I use a very limited set of colours: green for farmland/meadow/park/grass etc. light yellow for built areas (including residential, farm/yard, suburb, village, commercial, retail). brown (brick colour) for building, shopping center, historic, amenity. striped green/transparent for nature reserve. striped red/transparent for danger area. pinkish for square/plaza. and the default Garmin representation for everything else.
In case DEM is used, all the flavours become darker. Night colours not considered. It is do-able, but requires some a sense for colours. With landuse=farmland I had to split that line into two, to follow your idea. You will see it from the comments.
I had already split these: landuse=farm [0x26 resolution 22] landuse=farmland [0x1c resolution 20] landuse=farmyard [0x26 resolution 22] but I'd made minimal reorganisation of the file in this iteration because I just wanted to concentrate on the type changes.
To sum up: It works for me. If we do the changes to the default style, we should also change the default typ-file with some reasonable colouring. Maybe Joris could comment what is do-able in the mapnik colour schema.
@ Gerd: Could you check the latest releases, please. I cannot find the mapnik.txt in the zip.
Cheers, Michael
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Michael, if I got you right you think the patches should be applied without any changes? Gerd -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
Hi Gerd, based on my test, I think the changes of Ticker can be applied - more testers and opinions greatly appreciated. Find attached the typ prepared for publishing. The additional objects have English-based descriptions. Michael -----Ursprüngliche Nachricht----- Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Im Auftrag von Gerd Petermann Gesendet: Donnerstag, 28. Februar 2019 08:27 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] default style improvements Hi Michael, if I got you right you think the patches should be applied without any changes? Gerd -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Michael,
@ Gerd: Could you check the latest releases, please. I cannot find the mapnik.txt in the zip.
The file is in the mkgmap-default-typ-r4268.zip You have to scroll down on the download site to find it. But it is not the latest version published by Joris because my understanding is that Steve has to fix something in the TYP file compiler or reader to suppress a wrong warning about a code page mismatch. @Steve: Am I wrong? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Michael Poesdorf <michael.poesdorf@poesinet.de> Gesendet: Sonntag, 17. Februar 2019 11:01 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] default style improvements Hello Ticker I had a look into the 3 mails/proposals of yours. Point and Lines are in a way easy. More interesting is the look into the polygons. To get the map impression I implemented the changes to polygons, lines and points of r4268. I also modified the mapnik.typ. Please find the relevant files attached. Maybe someone else wants to have a look. Recognize changed style lines by my comments starting with ###. The added polygons in the typ-file should be easily recognizable. Also the lines and points. Please have a look at these 3 topics: 1) “Park”. There is already 0x17. You ask for 0x1e and 0x1f, also as “Park”. Not sure if we need this kind of differentiation. 0x1e is not on the typ - I created a 0x1f. 2) landuse=retail, 0x12. What is the difference to “Shopping center”? Nevertheless implemented in the typ. 3) 0x17 – the Park-topic I implemented the requested typs also. And I understand that there are many different usages for areas. The problem that I see is the colouring. We might get many quite similar coloured areas. Fifty shades of green. Maybe recognizable in Basecamp on a computer, but not that easy to distinguish on devices (like my Montana 610). In case DEM is used, all the flavours become darker. Night colours not considered. It is do-able, but requires some a sense for colours. With landuse=farmland I had to split that line into two, to follow your idea. You will see it from the comments. To sum up: It works for me. If we do the changes to the default style, we should also change the default typ-file with some reasonable colouring. Maybe Joris could comment what is do-able in the mapnik colour schema. @ Gerd: Could you check the latest releases, please. I cannot find the mapnik.txt in the zip. Cheers, Michael -----Ursprüngliche Nachricht----- Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Im Auftrag von Ticker Berkin Gesendet: Montag, 11. Februar 2019 20:43 An: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] default style improvements Hi Michael The changes to the default style haven't been applied and released yet. There were in 3 posts on 21-Jan around 06:30. Regards Ticker On Sat, 2019-02-09 at 07:49 +0100, Michael Poesdorf wrote:
Hi Ticker,
I'm not sure if I've seen changes from 21st of Jan. I tested r 4262 and it is working very well for me. Just adopted some resolutions of lines according to my personal flavour.
Regards, Michael
-----Ursprüngliche Nachricht----- Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Im Auftrag von Gerd Petermann Gesendet: Dienstag, 5. Februar 2019 09:26 An: Ticker Berkin <rwb-mkgmap@jagit.co.uk>; Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] default style improvements
Hi Ticker,
I'd prefer to get some positive feedback. I did not even try to understand the reasons for all these changes because I hoped for some feedback from the other typ file experts.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 5. Februar 2019 09:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Given the lack of comments and objections, can you apply my 3 patches to default style points/lines/polygons from 21-Jan
Thanks Ticker
_______________________________________________ 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 Here is a patch to change some TYPE element numbers in default/lines: Changes are: Use 0x30 for leisure=track instead of treating it like a footpath. 0x30 was introduced in the last set of changes as the code for various sports tracks (gallop, raceway) Use 0x0b (Road) instead of 0x06 as the "hint" portion of a *_link. 0x0b was unused. 0x06 is used for highway=minor & highway=unclassified Use 0x11 instead of 0x07 for highway=cycleway 0x11 was unused. 0x07 is Alley and is used for bridleway, service... Use 0x17 for various linear barriers and also man_made=breakwater Use 0x1a for car ferries, 0x1b for other ferries. At the moment 0x1b is used for all ferries Use 0x26 instead of 0x10a02 for intermittent steam & drain Regards Ticker
Hi Here is a patch to change some TYPE element numbers in default/polygons: Changes are: 0x17, which shows as "Park" in green, is currently used for these OSM objects: park, playground, common, garden, greenfield, meadow, grass, village_green, square/plaza Keep this mapping for leisure=park, playground Use 0x15 for landuse=village_green Use 0x1c for landuse=meadow, grass, greenfield, farmland Use 0x1d for leisure=common Use 0x20 for leisure=garden Use 0x25 for square/plaza Use 0x26 instead of 0x10 for landuse=farmyard 0x26 was unused. 0x10 is used landuse=residential Use 0x26 instead of 0x4e for landuse=farm Use 0x12 instead of 0x08 for landuse=retail 0x12 was unused. 0x08 is "Shopping Center" Use 0x12 instead of 0x05 for highway=services ie consider it a retail area - it normally includes shops, parking, fuel, eating places etc and isn't just a "Parking Lot". Someone suggested this change a few months ago but I can't remember who. Use 0x22 instead of 0x1e for historic=... 0x22 was unused. 0x1e is "Park" add natural=tundra [0x52 resolution 18] This is a standard Garmin type add natural=beach | natural=sand [0x53 resolution 20] This is Garmin type, sometimes labeled "Flat" or Sandbank,tidal/mud flat and the change was suggested by Nick / Minko on 27-Sep-2018 Use 0x0f instead of 0x0c for landuse=commercial 0x0f was unused. 0x0c is "Industrial Complex" Use 0x11 instead of 0x04 for military=danger_area This often covers a large area of other mixed use, and rendering it with partially transparent is much more informative Use 0x23 instead of 0x13 for amenity=... Use 0x24 instead of 0x13 for man_made=... 0x23 & 0x24 were unused. 0x13 is now just used for building Use 0x21 instead of 0x1f for tourism=... 0x21 was unused. 0x1f is "Park" Regards Ticker
Hi This is the next batch of default style changes. I don't think anything here is contention. The changes are: A few minor white-space changes that I missed in the previous batch. Remove unnecessary () in conditions Add tmp: prefix to tags that are just used by the style logic, so it is clear they don't have special meaning to the mkgmap code and don't overwrite osm tags. There are still a few tags created in relation that I think should be renamed (mkgmap:boundary_name, mkgmap:relref, mkgmap:fast_road, mkgmap:us_interstate, mkgmap:us_usroute, mkgmap:us_state) but I won't do this yet. Ferries default to mkgmap:toll=yes add a few new points: amenity=charging_station amenity=grave_yard, crematorium amenity=post_box amenity=recycling amenity=restaurant, cuisine=curry, fish_and_chips, indian, seafood amenity=swimming_pool tourism=bed_and_breakfast add default name, either as [default_name ...] or {add name=...} to: amenity=fast_food amenity=prison amenity=restaurant amenity=playground amenity=recreation_ground shop=* tourism=* man_made=* Improve Embassy name Ticker
Hi Gerd, Andrzej & maybe others I'm trying to understand a couple of bits of logic in the default style: 'relation' sets mkgmap:us_interstate, mkgmap:us_usroute and mkgmap:us_state but I can't find any use of these tags. It looks like these were introduced in revision 3979, 5-Aug-2017 following discussions on 27-Jul-2017 "Strange long distance routes on Nüvi" The other one is the use of cityxx / continue with_actions in the 'points' file. All the place=city/town/village/suburb/hamlet (& island/islet) have logic explicit to prevent re-triggering once an earlier rule has fired, but after these 'place=', I can't see any other rule that would be relevant. I'd expect just removing & cityxx!=yes, {set cityxx=yes} and "with_actions" to have the same effect and be the normal way to express this. Ticker
Hi Ticker, I guess variables like mkgmap:us_interstate come from my style. I use them for shields with road reference numbers. There are dedicated shields for US maps and standard shields for other countries. These variables allows to create single style for both cases. This is an example from my style, file "lines": # Set highway names to include the reference if there is one highway=motorway & mkgmap:us_interstate=* {name '${mkgmap:us_interstate|highway-symbol:interstate:12}'; addlabel '${name|not-equal:ref}'; set mkgmap:refnam=yes} highway=motorway & mkgmap:refnam!=* & mkgmap:us_usroute=* {name '${mkgmap:us_usroute|highway-symbol:shield:12}'; addlabel '${name|not-equal:ref}'; set mkgmap:refnam=yes} highway=motorway & mkgmap:refnam!=* & mkgmap:us_state=* {name '${mkgmap:us_state|highway-symbol:round:12}'; addlabel '${name|not-equal:ref}'; set mkgmap:refnam=yes} highway=motorway & mkgmap:refnam!=* & mkgmap:admin_level2=USA {name '${name}' | '${ref}'; set mkgmap:refnam=yes} #disable box highway=motorway & mkgmap:refnam!=* & mkgmap:admin_level2!=USA {name '${ref|highway-symbol:hbox:12}'; addlabel '${name|not-equal:ref}'; set mkgmap:refnam=yes} highway=trunk & mkgmap:refnam!=* & mkgmap:admin_level2!=USA {name '${ref|highway-symbol:hbox:12}'; addlabel '${name|not-equal:ref}'; set mkgmap:refnam=yes} highway=* & mkgmap:refnam!=* & mkgmap:us_interstate=* {name '${mkgmap:us_interstate|highway-symbol:interstate:12}'; addlabel '${name|not-equal:ref}'; set mkgmap:refnam=yes} highway=* & mkgmap:refnam!=* & mkgmap:us_usroute=* {name '${mkgmap:us_usroute|highway-symbol:shield:12}'; addlabel '${name|not-equal:ref}'; set mkgmap:refnam=yes} highway=* & mkgmap:refnam!=* & mkgmap:us_state=* {name '${mkgmap:us_state|highway-symbol:round:12}'; addlabel '${name|not-equal:ref}'; set mkgmap:refnam=yes} highway=* & mkgmap:refnam!=* & mkgmap:admin_level2=USA {name '${name}' | '${ref}'; set mkgmap:refnam=yes} #disable box highway=primary & mkgmap:refnam!=* & (name=* | ref=*) {name '${name|not-equal:ref}' | '${ref|highway-symbol:box:12}'; set mkgmap:refnam=yes} highway=secondary & mkgmap:refnam!=* & (name=* | ref=*) {name '${name|not-equal:ref}' | '${ref|highway-symbol:oval:12}'; set mkgmap:refnam=yes} highway=* & mkgmap:refnam!=* {name '${name}' | '${ref}'} -- Best regards, Andrzej
Hi Andrzej Is this logic general enough to move into the default style? I assume it replaces: # Display highway shield for mayor roads if they have a ref and make them searchable by their name (highway=motorway | highway=trunk) & ref=* {name '${ref|highway -symbol:hbox}'; addlabel '${name}'} highway=primary & ref=* {name '${ref|highway-symbol:box}'; addlabel '${name}'} (highway=secondary | highway=tertiary) & ref=* {name '${ref|highway -symbol:oval}'; addlabel '${name}'} but this tests for $ref being set and also handles tertiary. If it goes into 'default' I think we should have a different naming convention for style working tags, eg: tmp:fast_road, tmp:refnam, tmp:us_usroute, etc If it doesn't go into 'default' then the bits should be removed from 'relations' (and renaming xxx:fast_road, as above) Regards Ticker On Tue, 2018-11-20 at 15:15 +0100, Andrzej Popowski wrote:
Hi Ticker,
I guess variables like mkgmap:us_interstate come from my style. I use them for shields with road reference numbers. There are dedicated shields for US maps and standard shields for other countries. These variables allows to create single style for both cases.
Hi Ticker,
Is this logic general enough to move into the default style?
This is a solution for my maps and I have tried to make it universal. There could be other propositions, for example some people could prefer name of the road over ref number or include name into shield (but it doesn't look good on nuvis). For my topo maps, I set road name on level 0 and ref number on next levels. But this is much complicated style. -- Best regards, Andrzej
Hi Gerd Given lack of objections to any of this, could defaultStyleTidy2.patch be applied to trunk. Thanks Ticker On Fri, 2018-11-16 at 16:56 +0000, Ticker Berkin wrote:
Hi
This is the next batch of default style changes.
I don't think anything here is contention. The changes are:
A few minor white-space changes that I missed in the previous batch.
Remove unnecessary () in conditions
Add tmp: prefix to tags that are just used by the style logic, so it is clear they don't have special meaning to the mkgmap code and don't overwrite osm tags. There are still a few tags created in relation that I think should be renamed (mkgmap:boundary_name, mkgmap:relref, mkgmap:fast_road, mkgmap:us_interstate, mkgmap:us_usroute, mkgmap:us_state) but I won't do this yet.
Ferries default to mkgmap:toll=yes
add a few new points: amenity=charging_station amenity=grave_yard, crematorium amenity=post_box amenity=recycling amenity=restaurant, cuisine=curry, fish_and_chips, indian, seafood amenity=swimming_pool tourism=bed_and_breakfast
add default name, either as [default_name ...] or {add name=...} to: amenity=fast_food amenity=prison amenity=restaurant amenity=playground amenity=recreation_ground shop=* tourism=* man_made=*
Improve Embassy name
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, yes, your are right. I was a bit distracted because of some work for JOSM... Committed now . Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 26. November 2018 11:15 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd Given lack of objections to any of this, could defaultStyleTidy2.patch be applied to trunk. Thanks Ticker On Fri, 2018-11-16 at 16:56 +0000, Ticker Berkin wrote:
Hi
This is the next batch of default style changes.
I don't think anything here is contention. The changes are:
A few minor white-space changes that I missed in the previous batch.
Remove unnecessary () in conditions
Add tmp: prefix to tags that are just used by the style logic, so it is clear they don't have special meaning to the mkgmap code and don't overwrite osm tags. There are still a few tags created in relation that I think should be renamed (mkgmap:boundary_name, mkgmap:relref, mkgmap:fast_road, mkgmap:us_interstate, mkgmap:us_usroute, mkgmap:us_state) but I won't do this yet.
Ferries default to mkgmap:toll=yes
add a few new points: amenity=charging_station amenity=grave_yard, crematorium amenity=post_box amenity=recycling amenity=restaurant, cuisine=curry, fish_and_chips, indian, seafood amenity=swimming_pool tourism=bed_and_breakfast
add default name, either as [default_name ...] or {add name=...} to: amenity=fast_food amenity=prison amenity=restaurant amenity=playground amenity=recreation_ground shop=* tourism=* man_made=*
Improve Embassy name
Ticker
_______________________________________________ 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 Here is the third batch of default style changes. Changes are: Add GBR section to inc/access_country and tidy up the layout LINES A few minor layout tidy-ups Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway Ignore more highways when abandoned/disused/demolished Ignore more highway tags that are not suitable for routing Convert highway=steps/corridor/stepping_stones/elevator/escalator/platform to footway / bicycle=no and remove later test for steps Convert highway=crossing/virtual to path Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway Add footway around man_made=pier even if area=yes Fix common bad tagging for highway= and convert to the better values Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing Handle some rarer highway types Show any other water lines POINTS Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits. This was put in as a safety measure when this block of rules was added, see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html [mkgmap-dev] Adaptions in style (needed to make good use of) for overview2 branch
From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46 BST 2013 and has never had any effect - there are no other tags on objects with place=city/town... that need to be rendered
Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search. The only overall effect of this is that amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food" category. Add some a few more cuisines. For leisure=* where sport might be involved, show the sport if no name available. NB name will defaulted by the standard code in <finalize> Show canal/lock as 0x6505 (Water Features>Canal) POLYGONS Show aeroway=runway/taxiway/taxilane only if marked as area=yes Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show at Show place=suburb Show highway=pedestrian as square/plaza unless explicit area=no, but, for highway=footway, only show if explicit area=yes Don't assume any other closed highway is parking area, just services/rest_area Show all historic=* Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes Show any other water area Show all man_made=* unless explicit area=no Regards Ticker
Hi Ticker, I did not yet understand all changes. Can you explain why 1) highway=trail is translated to track? I would have used path. 2) rest_area is converted to a routable way? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 3. Dezember 2018 16:04 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Here is the third batch of default style changes. Changes are: Add GBR section to inc/access_country and tidy up the layout LINES A few minor layout tidy-ups Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway Ignore more highways when abandoned/disused/demolished Ignore more highway tags that are not suitable for routing Convert highway=steps/corridor/stepping_stones/elevator/escalator/platform to footway / bicycle=no and remove later test for steps Convert highway=crossing/virtual to path Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway Add footway around man_made=pier even if area=yes Fix common bad tagging for highway= and convert to the better values Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing Handle some rarer highway types Show any other water lines POINTS Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits. This was put in as a safety measure when this block of rules was added, see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html [mkgmap-dev] Adaptions in style (needed to make good use of) for overview2 branch
From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46 BST 2013 and has never had any effect - there are no other tags on objects with place=city/town... that need to be rendered
Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search. The only overall effect of this is that amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food" category. Add some a few more cuisines. For leisure=* where sport might be involved, show the sport if no name available. NB name will defaulted by the standard code in <finalize> Show canal/lock as 0x6505 (Water Features>Canal) POLYGONS Show aeroway=runway/taxiway/taxilane only if marked as area=yes Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show at Show place=suburb Show highway=pedestrian as square/plaza unless explicit area=no, but, for highway=footway, only show if explicit area=yes Don't assume any other closed highway is parking area, just services/rest_area Show all historic=* Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes Show any other water area Show all man_made=* unless explicit area=no Regards Ticker
Hi Gerd I had various OSM maps for Great Britain, Spain, Italy, Belgium and Morocco of different ages and when I found a highway tag that wasn't handled, looked at a few examples of the way/relation on OSM. For trail, I don't think I found many examples and 'track' seemed a reasonable option because, the example I looked at: https://www.openstreetmap.org/way/445188184 joined to 2 other 'track's. 'path' is probably better but that there is logic to convert 'path' to footway/cycleway/bridleway. The rest_area example I looked at didn't have any other highway into it, just a closed highway=rest_area with the beginning and end along the main highway. It seemed best to make it routable so that navigation turns into it correctly, rather than it saying a 90 degrees turn to the center, after having gone past the entrance. One of the maps I used was about 6 months old, and lots of the examples of bad tagging I went looking for, I found you'd recently fixed in OSM. Ticker On Tue, 2018-12-04 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
I did not yet understand all changes. Can you explain why 1) highway=trail is translated to track? I would have used path. 2) rest_area is converted to a routable way?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 3. Dezember 2018 16:04 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi
Here is the third batch of default style changes. Changes are:
Add GBR section to inc/access_country and tidy up the layout
LINES
A few minor layout tidy-ups
Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway
Ignore more highways when abandoned/disused/demolished
Ignore more highway tags that are not suitable for routing
Convert highway=steps/corridor/stepping_stones/elevator/escalator/platform to footway / bicycle=no and remove later test for steps
Convert highway=crossing/virtual to path
Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway
Add footway around man_made=pier even if area=yes
Fix common bad tagging for highway= and convert to the better values
Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing
Handle some rarer highway types
Show any other water lines
POINTS
Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits. This was put in as a safety measure when this block of rules was added, see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html [mkgmap-dev] Adaptions in style (needed to make good use of) for overview2 branch From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46 BST 2013 and has never had any effect - there are no other tags on objects with place=city/town... that need to be rendered
Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search. The only overall effect of this is that amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food" category. Add some a few more cuisines.
For leisure=* where sport might be involved, show the sport if no name available. NB name will defaulted by the standard code in <finalize>
Show canal/lock as 0x6505 (Water Features>Canal)
POLYGONS
Show aeroway=runway/taxiway/taxilane only if marked as area=yes
Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show at
Show place=suburb
Show highway=pedestrian as square/plaza unless explicit area=no, but, for highway=footway, only show if explicit area=yes
Don't assume any other closed highway is parking area, just services/rest_area
Show all historic=*
Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes
Show any other water area
Show all man_made=* unless explicit area=no
Regards Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, I think highway=trail is often used in the USA. When I stumbled over one it often looked like a highway=path + surface=ground. With rest_area I see the same problem as with highway=services mentioned here: https://forum.openstreetmap.org/viewtopic.php?pid=728618#p728618 And yes, I fixed lots of highway=footpath and other typos during the last weeks. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 4. Dezember 2018 17:50 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd I had various OSM maps for Great Britain, Spain, Italy, Belgium and Morocco of different ages and when I found a highway tag that wasn't handled, looked at a few examples of the way/relation on OSM. For trail, I don't think I found many examples and 'track' seemed a reasonable option because, the example I looked at: https://www.openstreetmap.org/way/445188184 joined to 2 other 'track's. 'path' is probably better but that there is logic to convert 'path' to footway/cycleway/bridleway. The rest_area example I looked at didn't have any other highway into it, just a closed highway=rest_area with the beginning and end along the main highway. It seemed best to make it routable so that navigation turns into it correctly, rather than it saying a 90 degrees turn to the center, after having gone past the entrance. One of the maps I used was about 6 months old, and lots of the examples of bad tagging I went looking for, I found you'd recently fixed in OSM. Ticker On Tue, 2018-12-04 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
I did not yet understand all changes. Can you explain why 1) highway=trail is translated to track? I would have used path. 2) rest_area is converted to a routable way?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 3. Dezember 2018 16:04 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi
Here is the third batch of default style changes. Changes are:
Add GBR section to inc/access_country and tidy up the layout
LINES
A few minor layout tidy-ups
Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway
Ignore more highways when abandoned/disused/demolished
Ignore more highway tags that are not suitable for routing
Convert highway=steps/corridor/stepping_stones/elevator/escalator/platform to footway / bicycle=no and remove later test for steps
Convert highway=crossing/virtual to path
Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway
Add footway around man_made=pier even if area=yes
Fix common bad tagging for highway= and convert to the better values
Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing
Handle some rarer highway types
Show any other water lines
POINTS
Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits. This was put in as a safety measure when this block of rules was added, see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html [mkgmap-dev] Adaptions in style (needed to make good use of) for overview2 branch From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46 BST 2013 and has never had any effect - there are no other tags on objects with place=city/town... that need to be rendered
Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search. The only overall effect of this is that amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food" category. Add some a few more cuisines.
For leisure=* where sport might be involved, show the sport if no name available. NB name will defaulted by the standard code in <finalize>
Show canal/lock as 0x6505 (Water Features>Canal)
POLYGONS
Show aeroway=runway/taxiway/taxilane only if marked as area=yes
Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show at
Show place=suburb
Show highway=pedestrian as square/plaza unless explicit area=no, but, for highway=footway, only show if explicit area=yes
Don't assume any other closed highway is parking area, just services/rest_area
Show all historic=*
Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes
Show any other water area
Show all man_made=* unless explicit area=no
Regards Ticker _______________________________________________ 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
I don't think it's a good idea to add other bad highway tags to the default style. They should be fixed in osm. I would get rid of all these: highway=minor highway=byway highway=driveway highway=access highway=footpath highway=foot highway=unsurfaced highway=layby highway=gallop Lorenzo Il giorno mar, 04/12/2018 alle 17.01 +0000, Gerd Petermann ha scritto:
Hi Ticker, I think highway=trail is often used in the USA.When I stumbled over one it often looked like a highway=path + surface=ground. With rest_area I see the same problem as with highway=services mentioned here: https://forum.openstreetmap.org/viewtopic.php?pid=728618#p728618
And yes, I fixed lots of highway=footpath and other typos during the last weeks. Gerd ________________________________________Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk>Gesendet: Dienstag, 4. Dezember 2018 17:50An: Development list for mkgmapBetreff: Re: [mkgmap-dev] default style improvements Hi Gerd I had various OSM maps for Great Britain, Spain, Italy, Belgium andMorocco of different ages and when I found a highway tag that wasn'thandled, looked at a few examples of the way/relation on OSM. For trail, I don't think I found many examples and 'track' seemed areasonable option because, the example I looked at: https://www.openstreetmap.org/way/445188184
joined to 2 other 'track's. 'path' is probably better but that there islogic to convert 'path' to footway/cycleway/bridleway. The rest_area example I looked at didn't have any other highway intoit, just a closed highway=rest_area with the beginning and end alongthe main highway. It seemed best to make it routable so that navigationturns into it correctly, rather than it saying a 90 degrees turn to thecenter, after having gone past the entrance. One of the maps I used was about 6 months old, and lots of the examplesof bad tagging I went looking for, I found you'd recently fixed in OSM. Ticker
On Tue, 2018-12-04 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker, I did not yet understand all changes. Can you explain why1) highway=trail is translated to track? I would have used path.2) rest_area is converted to a routable way? Gerd
________________________________________Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftragvon Ticker Berkin <rwb-mkgmap@jagit.co.uk>Gesendet: Montag, 3. Dezember 2018 16:04An: Development list for mkgmapBetreff: Re: [mkgmap-dev] default style improvements Hi Here is the third batch of default style changes. Changes are:
Add GBR section to inc/access_country and tidy up the layout
LINES A few minor layout tidy-ups Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yesand show these lines even when also a highway Ignore more highways when abandoned/disused/demolished Ignore more highway tags that are not suitable for routing Converthighway=steps/corridor/stepping_stones/elevator/escalator/pl atform tofootway / bicycle=no and remove later test for steps Convert highway=crossing/virtual to path Don't convert footway to cycleway, but more rules to convert path tofootway/cycleway/bridleway Add footway around man_made=pier even if area=yes Fix common bad tagging for highway= and convert to the better values Put routable path around highway=pedestrian closed areas;squares/plazas often don't have other routing joining all entry/exitways. Similarly for footway. Then continue to allow any polygonprocessing Handle some rarer highway types Show any other water lines
POINTS Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes,continuewith_actions bits. This was put in as a safety measure when thisblockof rules was added, see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html [mkgmap-dev] Adaptions in style (needed to make good use of) foroverview2 branchFrom Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46BST 2013and has never had any effect - there are no other tags on objectswithplace=city/town... that need to be rendered Group the rules amenity=restaurant/fast_food, cuisine= to clarify,simplify and show better how it relates Garmin "Food & Drink" search.The only overall effect of this is thatamenity=fast_food,cuisine=pizza/grill moves to the "Fast Food"category. Add some a few more cuisines. For leisure=* where sport might be involved, show the sport if nonameavailable. NB name will defaulted by the standard code in <finalize> Show canal/lock as 0x6505 (Water Features>Canal)
POLYGONS Show aeroway=runway/taxiway/taxilane only if marked as area=yes Increase resolution that amenity=cafe/fast_food/restaurant, shop=*showat Show place=suburb Show highway=pedestrian as square/plaza unless explicit area=no, but,for highway=footway, only show if explicit area=yes Don't assume any other closed highway is parking area, justservices/rest_area Show all historic=* Show drydock, canal & lock differently from standard natural=water,anduse a different code for small lakes Show any other water area Show all man_made=* unless explicit area=no RegardsTicker_______________________________________________mkgmap- dev mailing listmkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________mkgmap-dev mailing listmkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________mkgmap-dev mailing listmkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi I agree that bad tagging should be fixed in OSM but: 1/ some of the tags you mention here are acceptable 2/ it is a continuous job as some common mis-uses just get repeated 3/ its time-consuming 4/ it may be difficult for a non-local person to know exactly what the highway really is 5/ my intention was to make the default style handle most of what was thrown at it in a sensible way. and, not quite related to your point: 6/ Joris has suggested we should avoid mop-ups (generating a slow routable 0x07 Alley), and I was working towards this but find a large number where mappers have put the road name as the highway tag and I'd rather have these on my map. Ticker On Wed, 2018-12-05 at 00:03 +0100, Lorenzo Mastrogiacomi wrote:
I don't think it's a good idea to add other bad highway tags to the default style. They should be fixed in osm. I would get rid of all these:
highway=minor highway=byway highway=driveway highway=access highway=footpath highway=foot highway=unsurfaced highway=layby highway=gallop
Lorenzo
Hi Gerd Yes, I think trail > path, maybe with {add bicycle=no} would be better. The services/rest_area question is slightly different from this topic. I've not made a line element for any highway=services, but, having had a trawl through all my OSM data, I've found a few cases (not many) where this is the only route into a services area, eg way 534287035 rest_area is different and I think this should be a routable line, regardless of area= Ticker On Tue, 2018-12-04 at 17:01 +0000, Gerd Petermann wrote:
Hi Ticker,
I think highway=trail is often used in the USA. When I stumbled over one it often looked like a highway=path + surface=ground.
With rest_area I see the same problem as with highway=services mentioned here: https://forum.openstreetmap.org/viewtopic.php?pid=728618#p728618
And yes, I fixed lots of highway=footpath and other typos during the last weeks.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 4. Dezember 2018 17:50 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
I had various OSM maps for Great Britain, Spain, Italy, Belgium and Morocco of different ages and when I found a highway tag that wasn't handled, looked at a few examples of the way/relation on OSM.
For trail, I don't think I found many examples and 'track' seemed a reasonable option because, the example I looked at:
https://www.openstreetmap.org/way/445188184
joined to 2 other 'track's. 'path' is probably better but that there is logic to convert 'path' to footway/cycleway/bridleway.
The rest_area example I looked at didn't have any other highway into it, just a closed highway=rest_area with the beginning and end along the main highway. It seemed best to make it routable so that navigation turns into it correctly, rather than it saying a 90 degrees turn to the center, after having gone past the entrance.
One of the maps I used was about 6 months old, and lots of the examples of bad tagging I went looking for, I found you'd recently fixed in OSM.
Ticker
On Tue, 2018-12-04 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
I did not yet understand all changes. Can you explain why 1) highway=trail is translated to track? I would have used path. 2) rest_area is converted to a routable way?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 3. Dezember 2018 16:04 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi
Here is the third batch of default style changes. Changes are:
Add GBR section to inc/access_country and tidy up the layout
LINES
A few minor layout tidy-ups
Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway
Ignore more highways when abandoned/disused/demolished
Ignore more highway tags that are not suitable for routing
Convert highway=steps/corridor/stepping_stones/elevator/escalator/platform to footway / bicycle=no and remove later test for steps
Convert highway=crossing/virtual to path
Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway
Add footway around man_made=pier even if area=yes
Fix common bad tagging for highway= and convert to the better values
Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing
Handle some rarer highway types
Show any other water lines
POINTS
Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits. This was put in as a safety measure when this block of rules was added, see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html [mkgmap-dev] Adaptions in style (needed to make good use of) for overview2 branch From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46 BST 2013 and has never had any effect - there are no other tags on objects with place=city/town... that need to be rendered
Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search. The only overall effect of this is that amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food" category. Add some a few more cuisines.
For leisure=* where sport might be involved, show the sport if no name available. NB name will defaulted by the standard code in <finalize>
Show canal/lock as 0x6505 (Water Features>Canal)
POLYGONS
Show aeroway=runway/taxiway/taxilane only if marked as area=yes
Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show at
Show place=suburb
Show highway=pedestrian as square/plaza unless explicit area=no, but, for highway=footway, only show if explicit area=yes
Don't assume any other closed highway is parking area, just services/rest_area
Show all historic=*
Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes
Show any other water area
Show all man_made=* unless explicit area=no
Regards Ticker _______________________________________________ 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, way 534287035 is a typical typo, it should be service. Can you give an example for a rest_area which should be routable? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 5. Dezember 2018 12:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd Yes, I think trail > path, maybe with {add bicycle=no} would be better. The services/rest_area question is slightly different from this topic. I've not made a line element for any highway=services, but, having had a trawl through all my OSM data, I've found a few cases (not many) where this is the only route into a services area, eg way 534287035 rest_area is different and I think this should be a routable line, regardless of area= Ticker On Tue, 2018-12-04 at 17:01 +0000, Gerd Petermann wrote:
Hi Ticker,
I think highway=trail is often used in the USA. When I stumbled over one it often looked like a highway=path + surface=ground.
With rest_area I see the same problem as with highway=services mentioned here: https://forum.openstreetmap.org/viewtopic.php?pid=728618#p728618
And yes, I fixed lots of highway=footpath and other typos during the last weeks.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 4. Dezember 2018 17:50 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
I had various OSM maps for Great Britain, Spain, Italy, Belgium and Morocco of different ages and when I found a highway tag that wasn't handled, looked at a few examples of the way/relation on OSM.
For trail, I don't think I found many examples and 'track' seemed a reasonable option because, the example I looked at:
https://www.openstreetmap.org/way/445188184
joined to 2 other 'track's. 'path' is probably better but that there is logic to convert 'path' to footway/cycleway/bridleway.
The rest_area example I looked at didn't have any other highway into it, just a closed highway=rest_area with the beginning and end along the main highway. It seemed best to make it routable so that navigation turns into it correctly, rather than it saying a 90 degrees turn to the center, after having gone past the entrance.
One of the maps I used was about 6 months old, and lots of the examples of bad tagging I went looking for, I found you'd recently fixed in OSM.
Ticker
On Tue, 2018-12-04 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
I did not yet understand all changes. Can you explain why 1) highway=trail is translated to track? I would have used path. 2) rest_area is converted to a routable way?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 3. Dezember 2018 16:04 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi
Here is the third batch of default style changes. Changes are:
Add GBR section to inc/access_country and tidy up the layout
LINES
A few minor layout tidy-ups
Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway
Ignore more highways when abandoned/disused/demolished
Ignore more highway tags that are not suitable for routing
Convert highway=steps/corridor/stepping_stones/elevator/escalator/platform to footway / bicycle=no and remove later test for steps
Convert highway=crossing/virtual to path
Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway
Add footway around man_made=pier even if area=yes
Fix common bad tagging for highway= and convert to the better values
Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing
Handle some rarer highway types
Show any other water lines
POINTS
Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits. This was put in as a safety measure when this block of rules was added, see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html [mkgmap-dev] Adaptions in style (needed to make good use of) for overview2 branch From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46 BST 2013 and has never had any effect - there are no other tags on objects with place=city/town... that need to be rendered
Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search. The only overall effect of this is that amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food" category. Add some a few more cuisines.
For leisure=* where sport might be involved, show the sport if no name available. NB name will defaulted by the standard code in <finalize>
Show canal/lock as 0x6505 (Water Features>Canal)
POLYGONS
Show aeroway=runway/taxiway/taxilane only if marked as area=yes
Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show at
Show place=suburb
Show highway=pedestrian as square/plaza unless explicit area=no, but, for highway=footway, only show if explicit area=yes
Don't assume any other closed highway is parking area, just services/rest_area
Show all historic=*
Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes
Show any other water area
Show all man_made=* unless explicit area=no
Regards Ticker _______________________________________________ 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 Here are some polygons with area=yes: https://www.openstreetmap.org/way/515054518 this needs to be routable otherwise the navigation instruction would be too late. https://www.openstreetmap.org/way/303562822 doesn't matter for this because the edge is the road. and a multi-polygon: https://www.openstreetmap.org/relation/5889542 again, doesn't matter because the edge is the road This is just a single road: https://www.openstreetmap.org/way/242643878 Ticker On Wed, 2018-12-05 at 12:00 +0000, Gerd Petermann wrote:
Hi Ticker,
way 534287035 is a typical typo, it should be service. Can you give an example for a rest_area which should be routable?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 5. Dezember 2018 12:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Yes, I think trail > path, maybe with {add bicycle=no} would be better.
The services/rest_area question is slightly different from this topic. I've not made a line element for any highway=services, but, having had a trawl through all my OSM data, I've found a few cases (not many) where this is the only route into a services area, eg way 534287035
rest_area is different and I think this should be a routable line, regardless of area=
Ticker
On Tue, 2018-12-04 at 17:01 +0000, Gerd Petermann wrote:
Hi Ticker,
I think highway=trail is often used in the USA. When I stumbled over one it often looked like a highway=path + surface=ground.
With rest_area I see the same problem as with highway=services mentioned here: https://forum.openstreetmap.org/viewtopic.php?pid=728618#p728618
And yes, I fixed lots of highway=footpath and other typos during the last weeks.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 4. Dezember 2018 17:50 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
I had various OSM maps for Great Britain, Spain, Italy, Belgium and Morocco of different ages and when I found a highway tag that wasn't handled, looked at a few examples of the way/relation on OSM.
For trail, I don't think I found many examples and 'track' seemed a reasonable option because, the example I looked at:
https://www.openstreetmap.org/way/445188184
joined to 2 other 'track's. 'path' is probably better but that there is logic to convert 'path' to footway/cycleway/bridleway.
The rest_area example I looked at didn't have any other highway into it, just a closed highway=rest_area with the beginning and end along the main highway. It seemed best to make it routable so that navigation turns into it correctly, rather than it saying a 90 degrees turn to the center, after having gone past the entrance.
One of the maps I used was about 6 months old, and lots of the examples of bad tagging I went looking for, I found you'd recently fixed in OSM.
Ticker
On Tue, 2018-12-04 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
I did not yet understand all changes. Can you explain why 1) highway=trail is translated to track? I would have used path. 2) rest_area is converted to a routable way?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 3. Dezember 2018 16:04 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi
Here is the third batch of default style changes. Changes are:
Add GBR section to inc/access_country and tidy up the layout
LINES
A few minor layout tidy-ups
Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway
Ignore more highways when abandoned/disused/demolished
Ignore more highway tags that are not suitable for routing
Convert highway=steps/corridor/stepping_stones/elevator/escalator/platfor m to footway / bicycle=no and remove later test for steps
Convert highway=crossing/virtual to path
Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway
Add footway around man_made=pier even if area=yes
Fix common bad tagging for highway= and convert to the better values
Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing
Handle some rarer highway types
Show any other water lines
POINTS
Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits. This was put in as a safety measure when this block of rules was added, see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html [mkgmap-dev] Adaptions in style (needed to make good use of) for overview2 branch From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46 BST 2013 and has never had any effect - there are no other tags on objects with place=city/town... that need to be rendered
Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search. The only overall effect of this is that amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food" category. Add some a few more cuisines.
For leisure=* where sport might be involved, show the sport if no name available. NB name will defaulted by the standard code in <finalize>
Show canal/lock as 0x6505 (Water Features>Canal)
POLYGONS
Show aeroway=runway/taxiway/taxilane only if marked as area=yes
Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show at
Show place=suburb
Show highway=pedestrian as square/plaza unless explicit area=no, but, for highway=footway, only show if explicit area=yes
Don't assume any other closed highway is parking area, just services/rest_area
Show all historic=*
Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes
Show any other water area
Show all man_made=* unless explicit area=no
Regards Ticker _______________________________________________ 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, the first example shows why it is not a good idea to make it routable. It is not connected to the road network. If you stand there with your gps and search for a route to somewhere else you'll get a problem. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 5. Dezember 2018 16:17 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd Here are some polygons with area=yes: https://www.openstreetmap.org/way/515054518 this needs to be routable otherwise the navigation instruction would be too late. https://www.openstreetmap.org/way/303562822 doesn't matter for this because the edge is the road. and a multi-polygon: https://www.openstreetmap.org/relation/5889542 again, doesn't matter because the edge is the road This is just a single road: https://www.openstreetmap.org/way/242643878 Ticker On Wed, 2018-12-05 at 12:00 +0000, Gerd Petermann wrote:
Hi Ticker,
way 534287035 is a typical typo, it should be service. Can you give an example for a rest_area which should be routable?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 5. Dezember 2018 12:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Yes, I think trail > path, maybe with {add bicycle=no} would be better.
The services/rest_area question is slightly different from this topic. I've not made a line element for any highway=services, but, having had a trawl through all my OSM data, I've found a few cases (not many) where this is the only route into a services area, eg way 534287035
rest_area is different and I think this should be a routable line, regardless of area=
Ticker
On Tue, 2018-12-04 at 17:01 +0000, Gerd Petermann wrote:
Hi Ticker,
I think highway=trail is often used in the USA. When I stumbled over one it often looked like a highway=path + surface=ground.
With rest_area I see the same problem as with highway=services mentioned here: https://forum.openstreetmap.org/viewtopic.php?pid=728618#p728618
And yes, I fixed lots of highway=footpath and other typos during the last weeks.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 4. Dezember 2018 17:50 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
I had various OSM maps for Great Britain, Spain, Italy, Belgium and Morocco of different ages and when I found a highway tag that wasn't handled, looked at a few examples of the way/relation on OSM.
For trail, I don't think I found many examples and 'track' seemed a reasonable option because, the example I looked at:
https://www.openstreetmap.org/way/445188184
joined to 2 other 'track's. 'path' is probably better but that there is logic to convert 'path' to footway/cycleway/bridleway.
The rest_area example I looked at didn't have any other highway into it, just a closed highway=rest_area with the beginning and end along the main highway. It seemed best to make it routable so that navigation turns into it correctly, rather than it saying a 90 degrees turn to the center, after having gone past the entrance.
One of the maps I used was about 6 months old, and lots of the examples of bad tagging I went looking for, I found you'd recently fixed in OSM.
Ticker
On Tue, 2018-12-04 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,
I did not yet understand all changes. Can you explain why 1) highway=trail is translated to track? I would have used path. 2) rest_area is converted to a routable way?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 3. Dezember 2018 16:04 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi
Here is the third batch of default style changes. Changes are:
Add GBR section to inc/access_country and tidy up the layout
LINES
A few minor layout tidy-ups
Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway
Ignore more highways when abandoned/disused/demolished
Ignore more highway tags that are not suitable for routing
Convert highway=steps/corridor/stepping_stones/elevator/escalator/platfor m to footway / bicycle=no and remove later test for steps
Convert highway=crossing/virtual to path
Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway
Add footway around man_made=pier even if area=yes
Fix common bad tagging for highway= and convert to the better values
Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing
Handle some rarer highway types
Show any other water lines
POINTS
Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits. This was put in as a safety measure when this block of rules was added, see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html [mkgmap-dev] Adaptions in style (needed to make good use of) for overview2 branch From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46 BST 2013 and has never had any effect - there are no other tags on objects with place=city/town... that need to be rendered
Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search. The only overall effect of this is that amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food" category. Add some a few more cuisines.
For leisure=* where sport might be involved, show the sport if no name available. NB name will defaulted by the standard code in <finalize>
Show canal/lock as 0x6505 (Water Features>Canal)
POLYGONS
Show aeroway=runway/taxiway/taxilane only if marked as area=yes
Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show at
Show place=suburb
Show highway=pedestrian as square/plaza unless explicit area=no, but, for highway=footway, only show if explicit area=yes
Don't assume any other closed highway is parking area, just services/rest_area
Show all historic=*
Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes
Show any other water area
Show all man_made=* unless explicit area=no
Regards Ticker _______________________________________________ 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
Yes - I saw the nodes marked "part of way ..." and just presumed they were the road; sorry for wasting your time. Ticker On Wed, 2018-12-05 at 17:06 +0000, Gerd Petermann wrote:
Hi Ticker,
the first example shows why it is not a good idea to make it routable. It is not connected to the road network. If you stand there with your gps and search for a route to somewhere else you'll get a problem.
Gerd
I see there is no distinction between a pedestrian highway and a footway/path yet. On the generic new map I use 0x11 for pedestrian highways and 0x10 for cycleways, but you can do the opposite. Both are routable lines and visible on most (?) devices. Also for steps I use another routable line (0x13). You can also think of adding paved footways and paths to the pedestrian lines, so the distinction between paved and non paved are better visisble. I also recommend to set the colour of the pedestrian typ to the same grey as squares.
Hi Gerd Here is revision to defaultStyleTidy3.patch. The changes are: 1/ change highway=trail to highway=path; add bicycle=no instead of track 2/ don't generate routable line for highway=rest_area Regards Ticker
Hi Ticker, I think it is not a good idea to remove highway=escape or highway=emergency_bay. The last time I looked at them most where correctly mapped. I'd also remove horse=yes or horse=no unless you want evaluate that somewhere in the style. Don't know why it is in the current default style. There is no code in mkgmap to evaluate it. Reg. rules like highway=footpath | highway=foot {set highway=footway} # fix common bad tagging I think we don't need them. Most of those ways are mapped by HOT projects, it is very likely that they are not connected or self intersecting etc. I'd rather remove the mop up rule instead of adding a lot of "try to guess better" rules. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 8. Dezember 2018 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd Here is revision to defaultStyleTidy3.patch. The changes are: 1/ change highway=trail to highway=path; add bicycle=no instead of track 2/ don't generate routable line for highway=rest_area Regards Ticker
Hi Gerd My rationale was to see what highway= tags from various european countries the default style didn't handle and hence generated: [0x07 road_class=0 road_speed=0 resolution 23] and then decide to: a) explicitly ignore. b) handle as if they were a well defined highway type, with appropriate access control. c) generate a new line type, with routing as appropriate. d) allow mop-up as above. I removed escape/emergency_bay because I didn't think they added anything useful to routing or the resultant map. footpath/foot looked like they should be footway or path, but if you think they should be ignored, I have no problem with that. What remained after this exercise was a few rubbish tags and lots of highway={real name of street} and I'd rather have these on my map The {add horse=xxx} I just changed a bit to be in keeping with what was there already but happy to delete it. Ticker On Thu, 2018-12-13 at 09:18 +0000, Gerd Petermann wrote:
Hi Ticker,
I think it is not a good idea to remove highway=escape or highway=emergency_bay. The last time I looked at them most where correctly mapped. I'd also remove horse=yes or horse=no unless you want evaluate that somewhere in the style. Don't know why it is in the current default style. There is no code in mkgmap to evaluate it.
Reg. rules like highway=footpath | highway=foot {set highway=footway} # fix common bad tagging I think we don't need them. Most of those ways are mapped by HOT projects, it is very likely that they are not connected or self intersecting etc. I'd rather remove the mop up rule instead of adding a lot of "try to guess better" rules.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 8. Dezember 2018 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Here is revision to defaultStyleTidy3.patch. The changes are:
1/ change highway=trail to highway=path; add bicycle=no instead of track
2/ don't generate routable line for highway=rest_area
Regards Ticker
Hi Gerd Do you want me to do another version of this patch before you commit it? I'd like to get on with the next set of changes; minor things like removing horse= can be done with these. Regards Ticker On Thu, 2018-12-13 at 10:54 +0000, Ticker Berkin wrote:
Hi Gerd
My rationale was to see what highway= tags from various european countries the default style didn't handle and hence generated:
[0x07 road_class=0 road_speed=0 resolution 23]
and then decide to:
a) explicitly ignore. b) handle as if they were a well defined highway type, with appropriate access control. c) generate a new line type, with routing as appropriate. d) allow mop-up as above.
I removed escape/emergency_bay because I didn't think they added anything useful to routing or the resultant map.
footpath/foot looked like they should be footway or path, but if you think they should be ignored, I have no problem with that.
What remained after this exercise was a few rubbish tags and lots of highway={real name of street} and I'd rather have these on my map
The {add horse=xxx} I just changed a bit to be in keeping with what was there already but happy to delete it.
Ticker
On Thu, 2018-12-13 at 09:18 +0000, Gerd Petermann wrote:
Hi Ticker,
I think it is not a good idea to remove highway=escape or highway=emergency_bay. The last time I looked at them most where correctly mapped. I'd also remove horse=yes or horse=no unless you want evaluate that somewhere in the style. Don't know why it is in the current default style. There is no code in mkgmap to evaluate it.
Reg. rules like highway=footpath | highway=foot {set highway=footway} # fix common bad tagging I think we don't need them. Most of those ways are mapped by HOT projects, it is very likely that they are not connected or self intersecting etc. I'd rather remove the mop up rule instead of adding a lot of "try to guess better" rules.
Gerd
Hi Ticker, yes please, my understanding was that the patch was not accepted. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 3. Januar 2019 11:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd Do you want me to do another version of this patch before you commit it? I'd like to get on with the next set of changes; minor things like removing horse= can be done with these. Regards Ticker On Thu, 2018-12-13 at 10:54 +0000, Ticker Berkin wrote:
Hi Gerd
My rationale was to see what highway= tags from various european countries the default style didn't handle and hence generated:
[0x07 road_class=0 road_speed=0 resolution 23]
and then decide to:
a) explicitly ignore. b) handle as if they were a well defined highway type, with appropriate access control. c) generate a new line type, with routing as appropriate. d) allow mop-up as above.
I removed escape/emergency_bay because I didn't think they added anything useful to routing or the resultant map.
footpath/foot looked like they should be footway or path, but if you think they should be ignored, I have no problem with that.
What remained after this exercise was a few rubbish tags and lots of highway={real name of street} and I'd rather have these on my map
The {add horse=xxx} I just changed a bit to be in keeping with what was there already but happy to delete it.
Ticker
On Thu, 2018-12-13 at 09:18 +0000, Gerd Petermann wrote:
Hi Ticker,
I think it is not a good idea to remove highway=escape or highway=emergency_bay. The last time I looked at them most where correctly mapped. I'd also remove horse=yes or horse=no unless you want evaluate that somewhere in the style. Don't know why it is in the current default style. There is no code in mkgmap to evaluate it.
Reg. rules like highway=footpath | highway=foot {set highway=footway} # fix common bad tagging I think we don't need them. Most of those ways are mapped by HOT projects, it is very likely that they are not connected or self intersecting etc. I'd rather remove the mop up rule instead of adding a lot of "try to guess better" rules.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Here is another patch. I've made the changes as you suggested and the following changes: When highway=path is converted into a cycleway or bridleway, add foot=yes in case the inc/access[_country] rules don't allow foot on the resultant highway type Restrict which historic= are shown as polygons. The original patch widened this too much. Regards Ticker On Thu, 2019-01-03 at 14:56 +0000, Gerd Petermann wrote:
Hi Ticker,
yes please, my understanding was that the patch was not accepted.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 3. Januar 2019 11:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Do you want me to do another version of this patch before you commit it?
I'd like to get on with the next set of changes; minor things like removing horse= can be done with these.
Regards Ticker
On Thu, 2018-12-13 at 10:54 +0000, Ticker Berkin wrote:
Hi Gerd
My rationale was to see what highway= tags from various european countries the default style didn't handle and hence generated:
[0x07 road_class=0 road_speed=0 resolution 23]
and then decide to:
a) explicitly ignore. b) handle as if they were a well defined highway type, with appropriate access control. c) generate a new line type, with routing as appropriate. d) allow mop-up as above.
I removed escape/emergency_bay because I didn't think they added anything useful to routing or the resultant map.
footpath/foot looked like they should be footway or path, but if you think they should be ignored, I have no problem with that.
What remained after this exercise was a few rubbish tags and lots of highway={real name of street} and I'd rather have these on my map
The {add horse=xxx} I just changed a bit to be in keeping with what was there already but happy to delete it.
Ticker
On Thu, 2018-12-13 at 09:18 +0000, Gerd Petermann wrote:
Hi Ticker,
I think it is not a good idea to remove highway=escape or highway=emergency_bay. The last time I looked at them most where correctly mapped. I'd also remove horse=yes or horse=no unless you want evaluate that somewhere in the style. Don't know why it is in the current default style. There is no code in mkgmap to evaluate it.
Reg. rules like highway=footpath | highway=foot {set highway=footway} # fix common bad tagging I think we don't need them. Most of those ways are mapped by HOT projects, it is very likely that they are not connected or self intersecting etc. I'd rather remove the mop up rule instead of adding a lot of "try to guess better" rules.
Gerd
_______________________________________________ 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, it would be easier to check if you would not mix simple optical changes (additional/removed blanks) with functional changes ;) I'd also prefer smaller patches, each one adressing only one problem. This makes it easier to discuss the patch. 1) I do not yet understand the changes regarding area=yes and multipolygons. Can you explain that, please? 2) Why are the rules for food POI moved behind e.g. tourism=hotel? I think you often find OSM objects tagged with both amenity=restaurant and tourism=hotel, and I'd prefer to find both. Probably a case for continue ? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 3. Januar 2019 17:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd Here is another patch. I've made the changes as you suggested and the following changes: When highway=path is converted into a cycleway or bridleway, add foot=yes in case the inc/access[_country] rules don't allow foot on the resultant highway type Restrict which historic= are shown as polygons. The original patch widened this too much. Regards Ticker On Thu, 2019-01-03 at 14:56 +0000, Gerd Petermann wrote:
Hi Ticker,
yes please, my understanding was that the patch was not accepted.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 3. Januar 2019 11:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Do you want me to do another version of this patch before you commit it?
I'd like to get on with the next set of changes; minor things like removing horse= can be done with these.
Regards Ticker
On Thu, 2018-12-13 at 10:54 +0000, Ticker Berkin wrote:
Hi Gerd
My rationale was to see what highway= tags from various european countries the default style didn't handle and hence generated:
[0x07 road_class=0 road_speed=0 resolution 23]
and then decide to:
a) explicitly ignore. b) handle as if they were a well defined highway type, with appropriate access control. c) generate a new line type, with routing as appropriate. d) allow mop-up as above.
I removed escape/emergency_bay because I didn't think they added anything useful to routing or the resultant map.
footpath/foot looked like they should be footway or path, but if you think they should be ignored, I have no problem with that.
What remained after this exercise was a few rubbish tags and lots of highway={real name of street} and I'd rather have these on my map
The {add horse=xxx} I just changed a bit to be in keeping with what was there already but happy to delete it.
Ticker
On Thu, 2018-12-13 at 09:18 +0000, Gerd Petermann wrote:
Hi Ticker,
I think it is not a good idea to remove highway=escape or highway=emergency_bay. The last time I looked at them most where correctly mapped. I'd also remove horse=yes or horse=no unless you want evaluate that somewhere in the style. Don't know why it is in the current default style. There is no code in mkgmap to evaluate it.
Reg. rules like highway=footpath | highway=foot {set highway=footway} # fix common bad tagging I think we don't need them. Most of those ways are mapped by HOT projects, it is very likely that they are not connected or self intersecting etc. I'd rather remove the mop up rule instead of adding a lot of "try to guess better" rules.
Gerd
_______________________________________________ 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 I'd tried to get all the optical changes out of the way in the first 2 patches, but I missed a few and it seemed easier to fix them as I spotted them. This last patch covered about 25 issues. I think it might take a long time to go through this process sequentially and, as it involves changes to just 3 or 4 files, it will be confusing do them in parallel, with multiple patches outstanding. I don't see any difficulty with having dialogs in parallel about individual aspects in a patch, based on my list of topics supplied with the first version of the patch. Regarding polygons and area tag: In the following, 'polygon' refers to a directly closed way or ways from a multipolygon relation. 'lines' can test if is dealing with a polygon with: ... & (is_closed()=true | mkgmap:mp_created=true) If an element needs to be rendered as a line possibly also a polygon it needs a [... continue] in 'lines' in case it came from a closed way. In 'polygons', one cannot assume that the element has not already been rendered as a line. The area= tag is for OSM mappers to influence the meaning of polygons; mkgmap style should never set it. The treatment of polygons being rendered as lines and/or polygons in the absence of area=yes/no depends on the tag; for instance: aeroway=runway is considered a line unless also has area=yes highway=pedestrian always generates a line and, unless area=no, a polygon. This is the OSM representation of a square/plaza, and, in many cases, needs the routing given by the edge. The area tag is often missing, so assumed as yes. highway=footway always generates a line and, if area=yes, a polygon. Again, the edge routing is might be needed. Some mappers use this for walking area that are joined to other walkways/paths, but it shouldn't be assumed to this, hence assumption of area=no. It seems reasonably safe and clearer to omit the polygon test if also testing area=yes. For instance, in 'lines' aeroway=runway & area!=yes {name '${ref}'} [0x27 ...] in 'polygons' the polygon test is irrelevant anyway, but it needs the inverse of the additional clause in 'lines' aeroway=runway & area=yes {name '${ref}'} [0x0e resolution 20] Obviously, a non-polygon with area=yes doesn't get rendered at all. Does this adequately explain my changes in this area? At the moment, only elements with internet_access= can generate multiple points. In your example of a hotel with a restaurant, I'd rather have the hotel POI than the restaurant one. Many hotels have restaurants, but most you wouldn't go out of your way to eat there or they are often for guests only. The same is true of some of the amenity/leisure/sport/tourist categories; they are more significant tha n any restaurant they contain. I must admit that this is an additional post-justification, I hadn't thought of this when I moved the rules down. Multiple POI from a single element, requiring massive reordering of the sections in 'points' and lots of [... continue]s looks a different problem that I don't want to address at the moment. Regards Ticker On Sat, 2019-01-05 at 08:43 +0000, Gerd Petermann wrote:
Hi Ticker,
it would be easier to check if you would not mix simple optical changes (additional/removed blanks) with functional changes ;) I'd also prefer smaller patches, each one adressing only one problem. This makes it easier to discuss the patch.
1) I do not yet understand the changes regarding area=yes and multipolygons. Can you explain that, please? 2) Why are the rules for food POI moved behind e.g. tourism=hotel? I think you often find OSM objects tagged with both amenity=restaurant and tourism=hotel, and I'd prefer to find both. Probably a case for continue ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 3. Januar 2019 17:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Here is another patch. I've made the changes as you suggested and the following changes:
When highway=path is converted into a cycleway or bridleway, add foot=yes in case the inc/access[_country] rules don't allow foot on the resultant highway type
Restrict which historic= are shown as polygons. The original patch widened this too much.
Regards Ticker
On Thu, 2019-01-03 at 14:56 +0000, Gerd Petermann wrote:
Hi Ticker,
yes please, my understanding was that the patch was not accepted.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 3. Januar 2019 11:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Do you want me to do another version of this patch before you commit it?
I'd like to get on with the next set of changes; minor things like removing horse= can be done with these.
Regards Ticker
On Thu, 2018-12-13 at 10:54 +0000, Ticker Berkin wrote:
Hi Gerd
My rationale was to see what highway= tags from various european countries the default style didn't handle and hence generated:
[0x07 road_class=0 road_speed=0 resolution 23]
and then decide to:
a) explicitly ignore. b) handle as if they were a well defined highway type, with appropriate access control. c) generate a new line type, with routing as appropriate. d) allow mop-up as above.
I removed escape/emergency_bay because I didn't think they added anything useful to routing or the resultant map.
footpath/foot looked like they should be footway or path, but if you think they should be ignored, I have no problem with that.
What remained after this exercise was a few rubbish tags and lots of highway={real name of street} and I'd rather have these on my map
The {add horse=xxx} I just changed a bit to be in keeping with what was there already but happy to delete it.
Ticker
On Thu, 2018-12-13 at 09:18 +0000, Gerd Petermann wrote:
Hi Ticker,
I think it is not a good idea to remove highway=escape or highway=emergency_bay. The last time I looked at them most where correctly mapped. I'd also remove horse=yes or horse=no unless you want evaluate that somewhere in the style. Don't know why it is in the current default style. There is no code in mkgmap to evaluate it.
Reg. rules like highway=footpath | highway=foot {set highway=footway} # fix common bad tagging I think we don't need them. Most of those ways are mapped by HOT projects, it is very likely that they are not connected or self intersecting etc. I'd rather remove the mop up rule instead of adding a lot of "try to guess better" rules.
Gerd
_______________________________________________ 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
Il giorno sab, 05/01/2019 alle 17.18 +0000, Ticker Berkin ha scritto:
highway=pedestrian always generates a line and, unless area=no, a polygon. This is the OSM representation of a square/plaza, and, in many cases, needs the routing given by the edge. The area tag is often missing, so assumed as yes.
Not really Ticker, highway=pedestrian is a linear feature in osm like other highway=* tags used for road ways. area=yes is required to make it an area. Lorenzo
Hi Lorenzo I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg https://www.openstreetmap.org/relation/5174171 With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza. The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered. Ticker On Sun, 2019-01-06 at 00:26 +0100, Lorenzo Mastrogiacomi wrote:
Il giorno sab, 05/01/2019 alle 17.18 +0000, Ticker Berkin ha scritto:
highway=pedestrian always generates a line and, unless area=no, a polygon. This is the OSM representation of a square/plaza, and, in many cases, needs the routing given by the edge. The area tag is often missing, so assumed as yes.
Not really Ticker, highway=pedestrian is a linear feature in osm like other highway=* tags used for road ways. area=yes is required to make it an area.
Lorenzo
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:
I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg
https://www.openstreetmap.org/relation/5174171
With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza.
The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered.
I see this as part of a larger issue: when the OSM data is wrong, but it's possible to figure out what it should have been, should those errors be fixed up in map generation? A compromise might be to explicitly note the workaround in the style file, rather than making it seem like the style is correctly interpreting the data.
Il giorno dom, 06/01/2019 alle 12.45 +0000, Ticker Berkin ha scritto:
Hi Lorenzo
I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg
This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion.
With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza.
The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered.
I don't. 1 in 3 correct is not so good :)
Ticker
Lorenzo
Hi all, Just to make that clear: A way with highway=pedestrian is that is not closed will only be treated by polygon rules when it is part of a multipolygon. So, the question is how many of those don't have an area=yes and how many of the latter probably should have area=yes. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Lorenzo Mastrogiacomi <lomastrolo@gmail.com> Gesendet: Sonntag, 6. Januar 2019 17:46 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Il giorno dom, 06/01/2019 alle 12.45 +0000, Ticker Berkin ha scritto:
Hi Lorenzo
I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg
This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion.
With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza.
The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered.
I don't. 1 in 3 correct is not so good :)
Ticker
Lorenzo _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Not sure what you mean here. Only complete polygons, either from closed ways or generated by multipolygon get to be interpreted by 'polygons' style processing. Ticker On Sun, 2019-01-06 at 16:58 +0000, Gerd Petermann wrote:
Hi all, Just to make that clear: A way with highway=pedestrian is that is not closed will only be treated by polygon rules when it is part of a multipolygon. So, the question is how many of those don't have an area=yes and how many of the latter probably should have area=yes.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Lorenzo Mastrogiacomi <lomastrolo@gmail.com> Gesendet: Sonntag, 6. Januar 2019 17:46 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Il giorno dom, 06/01/2019 alle 12.45 +0000, Ticker Berkin ha scritto:
Hi Lorenzo
I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg
This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion.
With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza.
The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered.
I don't. 1 in 3 correct is not so good :)
Ticker
Lorenzo
_______________________________________________ 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, yes, you are right. I guess I thought about the special case where the mp-code would try to close an unclosed ring. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Sonntag, 6. Januar 2019 18:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd Not sure what you mean here. Only complete polygons, either from closed ways or generated by multipolygon get to be interpreted by 'polygons' style processing. Ticker On Sun, 2019-01-06 at 16:58 +0000, Gerd Petermann wrote:
Hi all, Just to make that clear: A way with highway=pedestrian is that is not closed will only be treated by polygon rules when it is part of a multipolygon. So, the question is how many of those don't have an area=yes and how many of the latter probably should have area=yes.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Lorenzo Mastrogiacomi <lomastrolo@gmail.com> Gesendet: Sonntag, 6. Januar 2019 17:46 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Il giorno dom, 06/01/2019 alle 12.45 +0000, Ticker Berkin ha scritto:
Hi Lorenzo
I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg
This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion.
With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza.
The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered.
I don't. 1 in 3 correct is not so good :)
Ticker
Lorenzo
_______________________________________________ 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 I don't see anything in the OSM definition of a square that requires it to come from a multipolygon relation https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian Ticker On Sun, 2019-01-06 at 17:46 +0100, Lorenzo Mastrogiacomi wrote:
Il giorno dom, 06/01/2019 alle 12.45 +0000, Ticker Berkin ha scritto:
Hi Lorenzo
I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg
This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion.
With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza.
The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered.
I don't. 1 in 3 correct is not so good :)
Ticker
Lorenzo
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
It's not what I meant. The example you provided is a multipolygon relation and multipolygons are always areas regardless if area=yes is set or not. So this is not a valid example, actually I can not find one really evident of missing area=yes on pedestrian areas. Lorenzo Il giorno dom, 06/01/2019 alle 17.37 +0000, Ticker Berkin ha scritto:
Hi
I don't see anything in the OSM definition of a square that requires it to come from a multipolygon relation
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian
Ticker
On Sun, 2019-01-06 at 17:46 +0100, Lorenzo Mastrogiacomi wrote:
Il giorno dom, 06/01/2019 alle 12.45 +0000, Ticker Berkin ha scritto:
Hi Lorenzo
I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg
This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion.
With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza. The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered.
I don't. 1 in 3 correct is not so good :)
Ticker
Lorenzo
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
Hi Reading some of the relevant wiki pages, I am finding the wording ambiguous. https://wiki.openstreetmap.org/wiki/Key:area https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian https://wiki.openstreetmap.org/wiki/Area It seems wrong that the handling of the area= tag is not consistent between polygons generated from closed ways and those generated by multipolygon relations, but, if you assert that it is, I'll respect it. Regardless, there are a lot of Piazzas that are not generated from a multipolygon and don't have the area tag, eg https://www.openstreetmap.org/way/601220094 https://www.openstreetmap.org/way/256580148 https://www.openstreetmap.org/way/173770171 My 'polygons' change as it stands: highway=pedestrian & area!=no [0x17 resolution 22] will show these as piazza, along with other areas that might not be. If I change it to: highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] it won't show them. Which is preferred? Ticker On Sun, 2019-01-06 at 20:37 +0100, Lorenzo Mastrogiacomi wrote:
It's not what I meant.
The example you provided is a multipolygon relation and multipolygons are always areas regardless if area=yes is set or not. So this is not a valid example, actually I can not find one really evident of missing area=yes on pedestrian areas.
Lorenzo
Il giorno dom, 06/01/2019 alle 17.37 +0000, Ticker Berkin ha scritto:
Hi
I don't see anything in the OSM definition of a square that requires it to come from a multipolygon relation
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian
Ticker
On Sun, 2019-01-06 at 17:46 +0100, Lorenzo Mastrogiacomi wrote:
Il giorno dom, 06/01/2019 alle 12.45 +0000, Ticker Berkin ha scritto:
Hi Lorenzo
I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg
This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion.
With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza. The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered.
I don't. 1 in 3 correct is not so good :)
Ticker
Lorenzo
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I think it is OK when you add a comment like # assume that a closed way with highway=pedestrian is meant to describe an area even if area=yes is missing Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 7. Januar 2019 10:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] default style improvements Hi Reading some of the relevant wiki pages, I am finding the wording ambiguous. https://wiki.openstreetmap.org/wiki/Key:area https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian https://wiki.openstreetmap.org/wiki/Area It seems wrong that the handling of the area= tag is not consistent between polygons generated from closed ways and those generated by multipolygon relations, but, if you assert that it is, I'll respect it. Regardless, there are a lot of Piazzas that are not generated from a multipolygon and don't have the area tag, eg https://www.openstreetmap.org/way/601220094 https://www.openstreetmap.org/way/256580148 https://www.openstreetmap.org/way/173770171 My 'polygons' change as it stands: highway=pedestrian & area!=no [0x17 resolution 22] will show these as piazza, along with other areas that might not be. If I change it to: highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] it won't show them. Which is preferred? Ticker On Sun, 2019-01-06 at 20:37 +0100, Lorenzo Mastrogiacomi wrote:
It's not what I meant.
The example you provided is a multipolygon relation and multipolygons are always areas regardless if area=yes is set or not. So this is not a valid example, actually I can not find one really evident of missing area=yes on pedestrian areas.
Lorenzo
Il giorno dom, 06/01/2019 alle 17.37 +0000, Ticker Berkin ha scritto:
Hi
I don't see anything in the OSM definition of a square that requires it to come from a multipolygon relation
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian
Ticker
On Sun, 2019-01-06 at 17:46 +0100, Lorenzo Mastrogiacomi wrote:
Il giorno dom, 06/01/2019 alle 12.45 +0000, Ticker Berkin ha scritto:
Hi Lorenzo
I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg
This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion.
With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza. The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered.
I don't. 1 in 3 correct is not so good :)
Ticker
Lorenzo
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
_______________________________________________ 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
Can it be like this? So I can just comment the second rule to be happy :) highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] # assume that a closed way with highway=pedestrian is meant to describe an area even if area=yes is missing highway=pedestrian & area!=no [0x17 resolution 22] Il giorno lun, 07/01/2019 alle 10.20 +0000, Gerd Petermann ha scritto:
I think it is OK when you add a comment like # assume that a closed way with highway=pedestrian is meant to describe an area even if area=yes is missing
Gerd
________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk
im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk
Gesendet: Montag, 7. Januar 2019 10:55 An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] default style improvements
Hi
Reading some of the relevant wiki pages, I am finding the wording ambiguous.
https://wiki.openstreetmap.org/wiki/Key:area
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian
https://wiki.openstreetmap.org/wiki/Area
It seems wrong that the handling of the area= tag is not consistent between polygons generated from closed ways and those generated by multipolygon relations, but, if you assert that it is, I'll respect it.
Regardless, there are a lot of Piazzas that are not generated from a multipolygon and don't have the area tag, eg
https://www.openstreetmap.org/way/601220094
https://www.openstreetmap.org/way/256580148
https://www.openstreetmap.org/way/173770171
My 'polygons' change as it stands:
highway=pedestrian & area!=no [0x17 resolution 22]
will show these as piazza, along with other areas that might not be. If I change it to:
highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22]
it won't show them.
Which is preferred?
Ticker
On Sun, 2019-01-06 at 20:37 +0100, Lorenzo Mastrogiacomi wrote:
It's not what I meant.
The example you provided is a multipolygon relation and multipolygons are always areas regardless if area=yes is set or not. So this is not a valid example, actually I can not find one really evident of missing area=yes on pedestrian areas.
Lorenzo
Il giorno dom, 06/01/2019 alle 17.37 +0000, Ticker Berkin ha scritto:
Hi
I don't see anything in the OSM definition of a square that requires it to come from a multipolygon relation
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian
Ticker
On Sun, 2019-01-06 at 17:46 +0100, Lorenzo Mastrogiacomi wrote:
Il giorno dom, 06/01/2019 alle 12.45 +0000, Ticker Berkin ha scritto:
Hi Lorenzo
I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg
This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion.
With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza. The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered.
I don't. 1 in 3 correct is not so good :)
Ticker
Lorenzo
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
_______________________________________________ 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
Hi I propose this in 'lines': # squares and plazas place=square [0x17 resolution 22] # squares/plazas are also mapped as highway=pedestrian areas. # The tag area=yes forces the polygon element to be considered an area and there is an understanding that # derivation from a multipolygon relation does likewise, hence this is the appropriate rule: #highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] # However, many squares are mapped as simple closed ways without any area tag and, to show these, an # alternative rule is needed, which assumes an area unless explicitly not: highway=pedestrian & area!=no [0x17 resolution 22] # Note that this rule will catch polygon elements that might not have been intended to be squares/plazas. # Only one of the above rules is needed Is this reasonably clear? should I leave both rules uncommented or comment the other way around? Ticker On Tue, 2019-01-08 at 00:30 +0100, Lorenzo Mastrogiacomi wrote:
Can it be like this? So I can just comment the second rule to be happy :)
highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] # assume that a closed way with highway=pedestrian is meant to describe an area even if area=yes is missing highway=pedestrian & area!=no [0x17 resolution 22]
Il giorno lun, 07/01/2019 alle 10.20 +0000, Gerd Petermann ha scritto:
I think it is OK when you add a comment like # assume that a closed way with highway=pedestrian is meant to describe an area even if area=yes is missing
Gerd
________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk
im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk
Gesendet: Montag, 7. Januar 2019 10:55 An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] default style improvements
Hi
Reading some of the relevant wiki pages, I am finding the wording ambiguous.
https://wiki.openstreetmap.org/wiki/Key:area
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian
https://wiki.openstreetmap.org/wiki/Area
It seems wrong that the handling of the area= tag is not consistent between polygons generated from closed ways and those generated by multipolygon relations, but, if you assert that it is, I'll respect it.
Regardless, there are a lot of Piazzas that are not generated from a multipolygon and don't have the area tag, eg
https://www.openstreetmap.org/way/601220094
https://www.openstreetmap.org/way/256580148
https://www.openstreetmap.org/way/173770171
My 'polygons' change as it stands:
highway=pedestrian & area!=no [0x17 resolution 22]
will show these as piazza, along with other areas that might not be. If I change it to:
highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22]
it won't show them.
Which is preferred?
Ticker
On Sun, 2019-01-06 at 20:37 +0100, Lorenzo Mastrogiacomi wrote:
It's not what I meant.
The example you provided is a multipolygon relation and multipolygons are always areas regardless if area=yes is set or not. So this is not a valid example, actually I can not find one really evident of missing area=yes on pedestrian areas.
Lorenzo
Il giorno dom, 06/01/2019 alle 17.37 +0000, Ticker Berkin ha scritto:
Hi
I don't see anything in the OSM definition of a square that requires it to come from a multipolygon relation
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian
Ticker
On Sun, 2019-01-06 at 17:46 +0100, Lorenzo Mastrogiacomi wrote:
Il giorno dom, 06/01/2019 alle 12.45 +0000, Ticker Berkin ha scritto:
Hi Lorenzo
I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg
This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion.
With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza. The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered.
I don't. 1 in 3 correct is not so good :)
Ticker
Lorenzo
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
_______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, I think that's too much. I'd use # squares and plazas place=square [0x17 resolution 22] highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] # following rule also renders a closed way without area attribute as a plaza highway=pedestrian & area!=no [0x17 resolution 22] I would not comment any of them in the default style and users who really care should be able to find which one they don't like. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 8. Januar 2019 17:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi I propose this in 'lines': # squares and plazas place=square [0x17 resolution 22] # squares/plazas are also mapped as highway=pedestrian areas. # The tag area=yes forces the polygon element to be considered an area and there is an understanding that # derivation from a multipolygon relation does likewise, hence this is the appropriate rule: #highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] # However, many squares are mapped as simple closed ways without any area tag and, to show these, an # alternative rule is needed, which assumes an area unless explicitly not: highway=pedestrian & area!=no [0x17 resolution 22] # Note that this rule will catch polygon elements that might not have been intended to be squares/plazas. # Only one of the above rules is needed Is this reasonably clear? should I leave both rules uncommented or comment the other way around? Ticker On Tue, 2019-01-08 at 00:30 +0100, Lorenzo Mastrogiacomi wrote: Can it be like this? So I can just comment the second rule to be happy :) highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] # assume that a closed way with highway=pedestrian is meant to describe an area even if area=yes is missing highway=pedestrian & area!=no [0x17 resolution 22] Il giorno lun, 07/01/2019 alle 10.20 +0000, Gerd Petermann ha scritto: I think it is OK when you add a comment like # assume that a closed way with highway=pedestrian is meant to describe an area even if area=yes is missing Gerd ________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 7. Januar 2019 10:55 An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] default style improvements Hi Reading some of the relevant wiki pages, I am finding the wording ambiguous. https://wiki.openstreetmap.org/wiki/Key:area https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian https://wiki.openstreetmap.org/wiki/Area It seems wrong that the handling of the area= tag is not consistent between polygons generated from closed ways and those generated by multipolygon relations, but, if you assert that it is, I'll respect it. Regardless, there are a lot of Piazzas that are not generated from a multipolygon and don't have the area tag, eg https://www.openstreetmap.org/way/601220094 https://www.openstreetmap.org/way/256580148 https://www.openstreetmap.org/way/173770171 My 'polygons' change as it stands: highway=pedestrian & area!=no [0x17 resolution 22] will show these as piazza, along with other areas that might not be. If I change it to: highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] it won't show them. Which is preferred? Ticker On Sun, 2019-01-06 at 20:37 +0100, Lorenzo Mastrogiacomi wrote: It's not what I meant. The example you provided is a multipolygon relation and multipolygons are always areas regardless if area=yes is set or not. So this is not a valid example, actually I can not find one really evident of missing area=yes on pedestrian areas. Lorenzo Il giorno dom, 06/01/2019 alle 17.37 +0000, Ticker Berkin ha scritto: Hi I don't see anything in the OSM definition of a square that requires it to come from a multipolygon relation https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian Ticker On Sun, 2019-01-06 at 17:46 +0100, Lorenzo Mastrogiacomi wrote: Il giorno dom, 06/01/2019 alle 12.45 +0000, Ticker Berkin ha scritto: Hi Lorenzo I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg https://www.openstreetmap.org/relation/5174171 This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion. With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza. The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered. I don't. 1 in 3 correct is not so good :) Ticker Lorenzo _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Here a new version of the patch with this wording. Ticker On Wed, 2019-01-09 at 15:15 +0000, Gerd Petermann wrote:
# squares and plazas place=square [0x17 resolution 22] highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] # following rule also renders a closed way without area attribute as a plaza highway=pedestrian & area!=no [0x17 resolution 22]
Hi Ticker, I've made a few modifications discussed before. For me this version would be OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 10. Januar 2019 10:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd Here a new version of the patch with this wording. Ticker On Wed, 2019-01-09 at 15:15 +0000, Gerd Petermann wrote:
# squares and plazas place=square [0x17 resolution 22] highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] # following rule also renders a closed way without area attribute as a plaza highway=pedestrian & area!=no [0x17 resolution 22]
Hi Gerd I had indented to do the highway_ramp change but the edit got into my pending list rather than the current change - sorry shop resolution remaining at value in old version - fine Areas of highway=service/residential/living_street explicitly as "Parking Lot" seems strange, even though that was the effect of the mop -up in the old version - did you mean this? Anyway - happy for you to apply this version. Regards Ticker On Thu, 2019-01-10 at 15:35 +0000, Gerd Petermann wrote:
Hi Ticker,
I've made a few modifications discussed before. For me this version would be OK.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 10. Januar 2019 10:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Here a new version of the patch with this wording.
Ticker
On Wed, 2019-01-09 at 15:15 +0000, Gerd Petermann wrote:
# squares and plazas place=square [0x17 resolution 22] highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] # following rule also renders a closed way without area attribute as a plaza highway=pedestrian & area!=no [0x17 resolution 22]
Hi Ticker, oops, I didn't understand that 0x05 is displayed as "parking lot". I'll remove that again. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 10. Januar 2019 17:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd I had indented to do the highway_ramp change but the edit got into my pending list rather than the current change - sorry shop resolution remaining at value in old version - fine Areas of highway=service/residential/living_street explicitly as "Parking Lot" seems strange, even though that was the effect of the mop -up in the old version - did you mean this? Anyway - happy for you to apply this version. Regards Ticker On Thu, 2019-01-10 at 15:35 +0000, Gerd Petermann wrote:
Hi Ticker,
I've made a few modifications discussed before. For me this version would be OK.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 10. Januar 2019 10:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Here a new version of the patch with this wording.
Ticker
On Wed, 2019-01-09 at 15:15 +0000, Gerd Petermann wrote:
# squares and plazas place=square [0x17 resolution 22] highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] # following rule also renders a closed way without area attribute as a plaza highway=pedestrian & area!=no [0x17 resolution 22]
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, please, can you summarize the changes implemented with this patch? Need this for the svn commit message. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 10. Januar 2019 17:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd I had indented to do the highway_ramp change but the edit got into my pending list rather than the current change - sorry shop resolution remaining at value in old version - fine Areas of highway=service/residential/living_street explicitly as "Parking Lot" seems strange, even though that was the effect of the mop -up in the old version - did you mean this? Anyway - happy for you to apply this version. Regards Ticker On Thu, 2019-01-10 at 15:35 +0000, Gerd Petermann wrote:
Hi Ticker,
I've made a few modifications discussed before. For me this version would be OK.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 10. Januar 2019 10:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Here a new version of the patch with this wording.
Ticker
On Wed, 2019-01-09 at 15:15 +0000, Gerd Petermann wrote:
# squares and plazas place=square [0x17 resolution 22] highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22] # following rule also renders a closed way without area attribute as a plaza highway=pedestrian & area!=no [0x17 resolution 22]
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Here is summary of the changes: A few minor layout tidy-ups Add GBR section to inc/access_country Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway Ignore more highways when abandoned/disused/demolished Ignore more highway tags that are not suitable for routing Convert highway=steps/corridor/stepping_stones/elevator/escalator/platform to footway with bicycle=no and remove later test for steps Convert highway=crossing/virtual to path Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway Add footway around man_made=pier even if area=yes Fix common bad tagging for highway= by converting to the presumed values Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing Handle some rarer highway types by converting to more generic type Show any other water lines Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits from place=city/town... Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search and add some more cuisines. One effect of this is that amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food" category. The other effect is that an element that is both a Restaurant and a Lodging now shows as Lodging rather than Restaurant For leisure=* where sport might be involved, show the sport if no name available Show canal/lock as 0x6505 (Water Features>Canal) Show aeroway=runway/taxiway/taxilane as polygon only if marked as area=yes Increase resolution that amenity=cafe/fast_food/restaurant polygons show at Show place=suburb Alternative rule to show highway=pedestrian as square/plaza unless explicit area=no. highway=footway show as square/plaza if explicit area=yes Don't assume any other closed highway is parking area, just services/rest_area Show more historic=* Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes Show any other water area Show all man_made=* unless explicit area=no Regards Ticker On Fri, 2019-01-11 at 06:13 +0000, Gerd Petermann wrote:
Hi Ticker,
please, can you summarize the changes implemented with this patch? Need this for the svn commit message.
Gerd
Hi Ticker, I often travel on bike in "nowhere land", where hotels and restaurants are rare. So I think it is good to show both PoIs if a hotel contains a restaurant. Of course, it would be more relevant to know how other users of OSM Garmin maps think about this topic (I use my own style, so the changes to the default style are not relevant for me). A different point I'd like to suggest is a new line type for unpaved highways (which are not tracks). Unpaved public highways may be not very common in Europe, but they are rather normal in other areas of the world. The fact that they are rendered like paved highways makes many mappers think that it is useless to add this tag - and the little use of the surface tag in turn makes map makers think that it does not matter... Clouds of dust caused by other vehicles on that road or getting stuck in a muddy quagmire are not great user experiences. Treating them differently for routing purposes is a good step, but that is not such visible to many users. Regards, Bernhard Am 05.01.2019 um 18:18 schrieb Ticker Berkin:
Hi Gerd
I'd tried to get all the optical changes out of the way in the first 2 patches, but I missed a few and it seemed easier to fix them as I spotted them.
This last patch covered about 25 issues. I think it might take a long time to go through this process sequentially and, as it involves changes to just 3 or 4 files, it will be confusing do them in parallel, with multiple patches outstanding. I don't see any difficulty with having dialogs in parallel about individual aspects in a patch, based on my list of topics supplied with the first version of the patch.
Regarding polygons and area tag:
In the following, 'polygon' refers to a directly closed way or ways from a multipolygon relation.
'lines' can test if is dealing with a polygon with: ... & (is_closed()=true | mkgmap:mp_created=true)
If an element needs to be rendered as a line possibly also a polygon it needs a [... continue] in 'lines' in case it came from a closed way.
In 'polygons', one cannot assume that the element has not already been rendered as a line.
The area= tag is for OSM mappers to influence the meaning of polygons; mkgmap style should never set it.
The treatment of polygons being rendered as lines and/or polygons in the absence of area=yes/no depends on the tag; for instance:
aeroway=runway is considered a line unless also has area=yes
highway=pedestrian always generates a line and, unless area=no, a polygon. This is the OSM representation of a square/plaza, and, in many cases, needs the routing given by the edge. The area tag is often missing, so assumed as yes.
highway=footway always generates a line and, if area=yes, a polygon. Again, the edge routing is might be needed. Some mappers use this for walking area that are joined to other walkways/paths, but it shouldn't be assumed to this, hence assumption of area=no.
It seems reasonably safe and clearer to omit the polygon test if also testing area=yes. For instance, in 'lines'
aeroway=runway & area!=yes {name '${ref}'} [0x27 ...]
in 'polygons' the polygon test is irrelevant anyway, but it needs the inverse of the additional clause in 'lines'
aeroway=runway & area=yes {name '${ref}'} [0x0e resolution 20]
Obviously, a non-polygon with area=yes doesn't get rendered at all.
Does this adequately explain my changes in this area?
At the moment, only elements with internet_access= can generate multiple points. In your example of a hotel with a restaurant, I'd rather have the hotel POI than the restaurant one. Many hotels have restaurants, but most you wouldn't go out of your way to eat there or they are often for guests only. The same is true of some of the amenity/leisure/sport/tourist categories; they are more significant tha n any restaurant they contain.
I must admit that this is an additional post-justification, I hadn't thought of this when I moved the rules down.
Multiple POI from a single element, requiring massive reordering of the sections in 'points' and lots of [... continue]s looks a different problem that I don't want to address at the moment.
Regards Ticker
On Sat, 2019-01-05 at 08:43 +0000, Gerd Petermann wrote:
Hi Ticker,
it would be easier to check if you would not mix simple optical changes (additional/removed blanks) with functional changes ;) I'd also prefer smaller patches, each one adressing only one problem. This makes it easier to discuss the patch.
1) I do not yet understand the changes regarding area=yes and multipolygons. Can you explain that, please? 2) Why are the rules for food POI moved behind e.g. tourism=hotel? I think you often find OSM objects tagged with both amenity=restaurant and tourism=hotel, and I'd prefer to find both. Probably a case for continue ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 3. Januar 2019 17:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Here is another patch. I've made the changes as you suggested and the following changes:
When highway=path is converted into a cycleway or bridleway, add foot=yes in case the inc/access[_country] rules don't allow foot on the resultant highway type
Restrict which historic= are shown as polygons. The original patch widened this too much.
Regards Ticker
On Thu, 2019-01-03 at 14:56 +0000, Gerd Petermann wrote:
Hi Ticker,
yes please, my understanding was that the patch was not accepted.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 3. Januar 2019 11:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Do you want me to do another version of this patch before you commit it?
I'd like to get on with the next set of changes; minor things like removing horse= can be done with these.
Regards Ticker
On Thu, 2018-12-13 at 10:54 +0000, Ticker Berkin wrote:
Hi Gerd
My rationale was to see what highway= tags from various european countries the default style didn't handle and hence generated:
[0x07 road_class=0 road_speed=0 resolution 23]
and then decide to:
a) explicitly ignore. b) handle as if they were a well defined highway type, with appropriate access control. c) generate a new line type, with routing as appropriate. d) allow mop-up as above.
I removed escape/emergency_bay because I didn't think they added anything useful to routing or the resultant map.
footpath/foot looked like they should be footway or path, but if you think they should be ignored, I have no problem with that.
What remained after this exercise was a few rubbish tags and lots of highway={real name of street} and I'd rather have these on my map
The {add horse=xxx} I just changed a bit to be in keeping with what was there already but happy to delete it.
Ticker
On Thu, 2018-12-13 at 09:18 +0000, Gerd Petermann wrote:
Hi Ticker,
I think it is not a good idea to remove highway=escape or highway=emergency_bay. The last time I looked at them most where correctly mapped. I'd also remove horse=yes or horse=no unless you want evaluate that somewhere in the style. Don't know why it is in the current default style. There is no code in mkgmap to evaluate it.
Reg. rules like highway=footpath | highway=foot {set highway=footway} # fix common bad tagging I think we don't need them. Most of those ways are mapped by HOT projects, it is very likely that they are not connected or self intersecting etc. I'd rather remove the mop up rule instead of adding a lot of "try to guess better" rules.
Gerd
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
Bernhard Hiller <bhil@gmx.de> writes:
I often travel on bike in "nowhere land", where hotels and restaurants are rare. So I think it is good to show both PoIs if a hotel contains a restaurant. Of course, it would be more relevant to know how other users of OSM Garmin maps think about this topic (I use my own style, so the changes to the default style are not relevant for me).
There are two issues; one is display, and the other is search. I think ti's pretty important that "show me cafes and restaurants nearby" find hotel restaurants (that are open to non-guests). I don't think it's quite as important that they both show up. But when zoomed all the way in, it would be nice. Plus, mappers often put the hotel POI on the building and a separate restuarant POI where the restaurant is.
A different point I'd like to suggest is a new line type for unpaved highways (which are not tracks). Unpaved public highways may be not very common in Europe, but they are rather normal in other areas of the world. The fact that they are rendered like paved highways makes many mappers think that it is useless to add this tag - and the little use of the surface tag in turn makes map makers think that it does not matter... Clouds of dust caused by other vehicles on that road or getting stuck in a muddy quagmire are not great user experiences. Treating them differently for routing purposes is a good step, but that is not such visible to many users.
Agreed that unpaved public roads should have a different symbol. (Even where I am, in Massachusetts, US, they have a significant existence.) (I think the real reason they don't exist in the UK is that it's too wet and they would always be muddy. I drove on some roads there that are so minor that almost certainly would not have been paved in the US. And this UK non-existence of unpaved real roads has led to some distortion of their representation in OSM.)
Hi On Sun, 2019-01-06 at 08:50 -0500, Greg Troxel wrote:
Bernhard Hiller <bhil@gmx.de> writes:
I often travel on bike in "nowhere land", where hotels and restaurants are rare. So I think it is good to show both PoIs if a hotel contains a restaurant. Of course, it would be more relevant to know how other users of OSM Garmin maps think about this topic (I use my own style, so the changes to the default style are not relevant for me).
There are two issues; one is display, and the other is search. I think ti's pretty important that "show me cafes and restaurants nearby" find hotel restaurants (that are open to non-guests). I don't think it's quite as important that they both show up. But when zoomed all the way in, it would be nice. Plus, mappers often put the hotel POI on the building and a separate restuarant POI where the restaurant is.
If the consensus is to have both 'Food & Drink' and 'Lodging' points, I'll can do it, preferably in a future change. There are many other cases like this; it's almost as if the default behaviour for 'points' processing should be [... continue ]
A different point I'd like to suggest is a new line type for unpaved highways (which are not tracks). Unpaved public highways may be not very common in Europe, but they are rather normal in other areas of the world. The fact that they are rendered like paved highways makes many mappers think that it is useless to add this tag - and the little use of the surface tag in turn makes map makers think that it does not matter... Clouds of dust caused by other vehicles on that road or getting stuck in a muddy quagmire are not great user experiences. Treating them differently for routing purposes is a good step, but that is not such visible to many users.
Agreed that unpaved public roads should have a different symbol. (Even where I am, in Massachusetts, US, they have a significant existence.)
(I think the real reason they don't exist in the UK is that it's too wet and they would always be muddy. I drove on some roads there that are so minor that almost certainly would not have been paved in the US. And this UK non-existence of unpaved real roads has led to some distortion of their representation in OSM.)
This request is slightly confused by 2 issues: 1/ The mkgmap/garmin attribute mkgmap:unpaved which is used by the routing option "avoid unpaved" on some (older?) Garmin devices to avoid unpaved roads. 2/ The line type 0x0a = "Unpaved Road" being used by the default style for highway=track, highway=unsurfaced and railway=abandoned Is the existing setting in the default style of mkgmap:unpaved (based on tags surface, mtb:scale, tracktype, sac_scale) adequate, or are there other tags/values that need to considered? Are you thinking of having another line type? The default style has used all but 1 of the non-extended road types that show on newer devices without a typ-file specification; and I was thinking of using the last one (0x0b) as the Hint portion of a *_link instead of 0x06, which is also used for highway=minor & highway=unclassified Which highway types should be changed, eg unclassified, minor, tertiary, *_link, ... motorway? Should this new road type have the same [road_class road_speed resolution] attributes as the existing highway that it is replacing or can it just have a single fixed set of these attributes? Given answers to these questions, it can be done, but again, in some future change Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:
On Sun, 2019-01-06 at 08:50 -0500, Greg Troxel wrote:
This request is slightly confused by 2 issues:
1/ The mkgmap/garmin attribute mkgmap:unpaved which is used by the routing option "avoid unpaved" on some (older?) Garmin devices to avoid unpaved roads.
2/ The line type 0x0a = "Unpaved Road" being used by the default style for highway=track, highway=unsurfaced and railway=abandoned
Is the existing setting in the default style of mkgmap:unpaved (based on tags surface, mtb:scale, tracktype, sac_scale) adequate, or are there other tags/values that need to considered?
I have no reason to think anything is wrong there. Is there another mechanism for avoidance on other devices? That could interact with the line type choice, if those avoid line 0x0a only, and e.g. not extended line types we want to use to show other unpaved ways.
Are you thinking of having another line type? The default style has used all but 1 of the non-extended road types that show on newer devices without a typ-file specification; and I was thinking of using the last one (0x0b) as the Hint portion of a *_link instead of 0x06, which is also used for highway=minor & highway=unclassified
Yes, basically. (highway=minor sounds like an osm bug; that could also get a comment in the style that it's accomodating strange tagging.) Upleveling as I am wont to do from excessive formal computer science training: I think we're at the point where the richness of the OSM data model exceeds that of the basic Garmin data model. I see two approaches: project OSM onto Garmin, losing detail use new line types and a TYP file There is merit in each approach; perhaps there should be a no-typ default style and then a style that has within it a typ sourcefile that is used by default with the style, developed together with the style.
Which highway types should be changed, eg unclassified, minor, tertiary, *_link, ... motorway? Should this new road type have the same [road_class road_speed resolution] attributes as the existing highway that it is replacing or can it just have a single fixed set of these attributes?
Ideally, we'd have a separate visual presentation for unpaved versions of motorway/primary/secondary/tertiary/unclassified/residential/service plus all their link variants (I agree that unpaved motorway feels wrong, and arguably it can be ignored because if there is one (Alaska still?) everybody knows already and in those places checking "avoid unpaved roads" isn't useful.) from a routing point of view, road class and road_speed should be set on these in the same manner as if paved, presumably class from osm way type, and speed from tags (or maybe defaults). (Maybe maybe there should be a default maxpeed:practical to unsurfaced ways if there is no explicit maxspeed tag, but that's tricky business of second-guessing defaults to make routing work better.) avoid unpaved knows about these on all devices I don't see why resolution should be different than if paved; way type encodes hierarchy. track, path, railroads (active/abandoned/razed) all look different. track has less visual weight than unpaved residential. in particular, a highway=secondary or highway=tertiary with surface=unpaved should show up on the map quite differently than track. I think these goals lead to using unused extended line types and controlling their appearance with the TYP file. I think this approach means that TYP file is not optional and needs to be in sync with the style.
Given answers to these questions, it can be done, but again, in some future change
Sure -- I was not meaning to suggest that your present changes are problematic because they don't do everything I have ever wanted!
Hi Ticker, I think I understand the changes in the points file and in inc/accesss_country and they look okay to me. I agree that it is better to have the hotel POI for those cases where a point has both amenity=restaurant and tourism=hotel. In polygons I don't understand some of the changes. Dubious to me are those for - aeroway - shop now being rendered at res 24 instead of 22. Why? - highway=pedestrian - the rule highway=* & (area=yes | mkgmap:mp_created=true) [0x05 resolution 22] was removed. In Italy and probably other countries as well I see many highway=residential + area=yes or highway=service+area=yes as an alternative to map place=square (which is quite new) Most of the changes in lines look OK to me. - I don't like all the changes reg. area, see also Lorenzos comment. - I think highway=access_ramp is equivalent to highway=footway, see https://wiki.openstreetmap.org/wiki/Proposed_features/Access_Ramp - not sure why you set bicycle=no for highway=trail? - You see tmp:stopMopUp=yes in some rules but the rules that would evaluate that tag are commented. I'd rather remove all. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 5. Januar 2019 18:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd I'd tried to get all the optical changes out of the way in the first 2 patches, but I missed a few and it seemed easier to fix them as I spotted them. This last patch covered about 25 issues. I think it might take a long time to go through this process sequentially and, as it involves changes to just 3 or 4 files, it will be confusing do them in parallel, with multiple patches outstanding. I don't see any difficulty with having dialogs in parallel about individual aspects in a patch, based on my list of topics supplied with the first version of the patch. Regarding polygons and area tag: In the following, 'polygon' refers to a directly closed way or ways from a multipolygon relation. 'lines' can test if is dealing with a polygon with: ... & (is_closed()=true | mkgmap:mp_created=true) If an element needs to be rendered as a line possibly also a polygon it needs a [... continue] in 'lines' in case it came from a closed way. In 'polygons', one cannot assume that the element has not already been rendered as a line. The area= tag is for OSM mappers to influence the meaning of polygons; mkgmap style should never set it. The treatment of polygons being rendered as lines and/or polygons in the absence of area=yes/no depends on the tag; for instance: aeroway=runway is considered a line unless also has area=yes highway=pedestrian always generates a line and, unless area=no, a polygon. This is the OSM representation of a square/plaza, and, in many cases, needs the routing given by the edge. The area tag is often missing, so assumed as yes. highway=footway always generates a line and, if area=yes, a polygon. Again, the edge routing is might be needed. Some mappers use this for walking area that are joined to other walkways/paths, but it shouldn't be assumed to this, hence assumption of area=no. It seems reasonably safe and clearer to omit the polygon test if also testing area=yes. For instance, in 'lines' aeroway=runway & area!=yes {name '${ref}'} [0x27 ...] in 'polygons' the polygon test is irrelevant anyway, but it needs the inverse of the additional clause in 'lines' aeroway=runway & area=yes {name '${ref}'} [0x0e resolution 20] Obviously, a non-polygon with area=yes doesn't get rendered at all. Does this adequately explain my changes in this area? At the moment, only elements with internet_access= can generate multiple points. In your example of a hotel with a restaurant, I'd rather have the hotel POI than the restaurant one. Many hotels have restaurants, but most you wouldn't go out of your way to eat there or they are often for guests only. The same is true of some of the amenity/leisure/sport/tourist categories; they are more significant tha n any restaurant they contain. I must admit that this is an additional post-justification, I hadn't thought of this when I moved the rules down. Multiple POI from a single element, requiring massive reordering of the sections in 'points' and lots of [... continue]s looks a different problem that I don't want to address at the moment. Regards Ticker On Sat, 2019-01-05 at 08:43 +0000, Gerd Petermann wrote:
Hi Ticker,
it would be easier to check if you would not mix simple optical changes (additional/removed blanks) with functional changes ;) I'd also prefer smaller patches, each one adressing only one problem. This makes it easier to discuss the patch.
1) I do not yet understand the changes regarding area=yes and multipolygons. Can you explain that, please? 2) Why are the rules for food POI moved behind e.g. tourism=hotel? I think you often find OSM objects tagged with both amenity=restaurant and tourism=hotel, and I'd prefer to find both. Probably a case for continue ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 3. Januar 2019 17:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Here is another patch. I've made the changes as you suggested and the following changes:
When highway=path is converted into a cycleway or bridleway, add foot=yes in case the inc/access[_country] rules don't allow foot on the resultant highway type
Restrict which historic= are shown as polygons. The original patch widened this too much.
Regards Ticker
On Thu, 2019-01-03 at 14:56 +0000, Gerd Petermann wrote:
Hi Ticker,
yes please, my understanding was that the patch was not accepted.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 3. Januar 2019 11:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
Do you want me to do another version of this patch before you commit it?
I'd like to get on with the next set of changes; minor things like removing horse= can be done with these.
Regards Ticker
On Thu, 2018-12-13 at 10:54 +0000, Ticker Berkin wrote:
Hi Gerd
My rationale was to see what highway= tags from various european countries the default style didn't handle and hence generated:
[0x07 road_class=0 road_speed=0 resolution 23]
and then decide to:
a) explicitly ignore. b) handle as if they were a well defined highway type, with appropriate access control. c) generate a new line type, with routing as appropriate. d) allow mop-up as above.
I removed escape/emergency_bay because I didn't think they added anything useful to routing or the resultant map.
footpath/foot looked like they should be footway or path, but if you think they should be ignored, I have no problem with that.
What remained after this exercise was a few rubbish tags and lots of highway={real name of street} and I'd rather have these on my map
The {add horse=xxx} I just changed a bit to be in keeping with what was there already but happy to delete it.
Ticker
On Thu, 2018-12-13 at 09:18 +0000, Gerd Petermann wrote:
Hi Ticker,
I think it is not a good idea to remove highway=escape or highway=emergency_bay. The last time I looked at them most where correctly mapped. I'd also remove horse=yes or horse=no unless you want evaluate that somewhere in the style. Don't know why it is in the current default style. There is no code in mkgmap to evaluate it.
Reg. rules like highway=footpath | highway=foot {set highway=footway} # fix common bad tagging I think we don't need them. Most of those ways are mapped by HOT projects, it is very likely that they are not connected or self intersecting etc. I'd rather remove the mop up rule instead of adding a lot of "try to guess better" rules.
Gerd
_______________________________________________ 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 see embedded answers Regards Ticker On Sun, 2019-01-06 at 09:11 +0000, Gerd Petermann wrote:
Hi Ticker,
I think I understand the changes in the points file and in inc/accesss_country and they look okay to me. I agree that it is better to have the hotel POI for those cases where a point has both amenity=restaurant and tourism=hotel.
In polygons I don't understand some of the changes. Dubious to me are those for - aeroway
aeroway=runway/taxiway/taxilane are rendered as 0x27="Runway" lines unless they have area=yes, in which case they are rendered as 0x0e="Aircraft Road" polygons. Circular (ie closed ways) taxiways are a well defined concept and shouldn't need area=no. This handling seemed to fit with some of the examples I looked at.
- shop now being rendered at res 24 instead of 22. Why?
I changed this because most shops are at the same scale as building/cafe/restaurant, which are at res 24. I don't have a strong opinion on this.
- highway=pedestrian
Not sure what you are asking here. The most significant change was to render as routable lines regardless of being closed/multipolygons/area tag. (ie giving square/plaza edge routing). The other changes were to continue but avoid any possible highway mop-up so that always get to 'polygons' and there render as square/plaza unless area=no (but have this rule after place=square rule)
- the rule highway=* & (area=yes | mkgmap:mp_created=true) [0x05 resolution 22] was removed. In Italy and probably other countries as well I see many highway=residential + area=yes or highway=service+area=yes as an alternative to map place=square (which is quite new)
This rule is wrong in many ways! It generates a "Parking Lot" as a highway=* mop-up. There shouldn't be a difference in the handling of polygons derived from multiPolygon or simple closed ways. I added the explicit: # other highways that have area=yes are probably parking lots, eg services/rest_area (highway=services | highway=rest_area) & area!=no [0x05 resolution 22] but, from a recent post, it is thought that highway=services is better treated as a retail area and I plan to do this in a future change. If you think other highway types (ie service/residential) that have area=yes should also generate a square/plaza then I'm happy to include this.
Most of the changes in lines look OK to me. - I don't like all the changes reg. area, see also Lorenzos comment.
Are you referring to area= changes other than highway=pedestrian as per Lorenzos comments? Just seen Greg's comments and maybe the answer is to annotate the rule when it trying to do the best with bad data.
- I think highway=access_ramp is equivalent to highway=footway, see https://wiki.openstreetmap.org/wiki/Proposed_features/Access_Ramp
I can't remember the example I looked at but it seemed more like a service road. However, as there is this proposal, I'll change it to footway.
- not sure why you set bicycle=no for highway=trail?
This tag is not well defined, but its wiki page: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrail says should not assume that it cycleable
- You see tmp:stopMopUp=yes in some rules but the rules that would evaluate that tag are commented. I'd rather remove all.
Although the rules that test it are commented, one is a diagnostic to show unhandled highway= and the other is the one that generates a routable line. Although the opinion seems to be that these shouldn't be shown, I feel strongly that they should and will continue to do so on my maps. If other people want the same they just uncomment the line.
Gerd
Hello I updated a typ-file up to these changes of Ticker Kind regards, Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Ticker Berkin Verzonden: maandag 3 december 2018 16:04 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] default style improvements Hi Here is the third batch of default style changes. Changes are: Add GBR section to inc/access_country and tidy up the layout LINES A few minor layout tidy-ups Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway Ignore more highways when abandoned/disused/demolished Ignore more highway tags that are not suitable for routing Convert highway=steps/corridor/stepping_stones/elevator/escalator/platform to footway / bicycle=no and remove later test for steps Convert highway=crossing/virtual to path Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway Add footway around man_made=pier even if area=yes Fix common bad tagging for highway= and convert to the better values Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing Handle some rarer highway types Show any other water lines POINTS Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits. This was put in as a safety measure when this block of rules was added, see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html [mkgmap-dev] Adaptions in style (needed to make good use of) for overview2 branch From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46 BST 2013 and has never had any effect - there are no other tags on objects with place=city/town... that need to be rendered Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search. The only overall effect of this is that amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food" category. Add some a few more cuisines. For leisure=* where sport might be involved, show the sport if no name available. NB name will defaulted by the standard code in <finalize> Show canal/lock as 0x6505 (Water Features>Canal) POLYGONS Show aeroway=runway/taxiway/taxilane only if marked as area=yes Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show at Show place=suburb Show highway=pedestrian as square/plaza unless explicit area=no, but, for highway=footway, only show if explicit area=yes Don't assume any other closed highway is parking area, just services/rest_area Show all historic=* Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes Show any other water area Show all man_made=* unless explicit area=no Regards Ticker
On the forum someone asked if highway=services could be added to the polygons style. https://forum.openstreetmap.org/viewtopic.php?pid=728618#p728618 For example like in the generic new maps: landuse=retail | highway=services [0x08 resolution 22-20] If added, prevent that it also will be mopped up by excluding it in the lines style See https://github.com/ligfietser/mkgmap-style-sheets/commit/984b5ce9c8a9e9aacc6...
Hi In the latest release default style, all highway=* except pedestrian that have area=yes or come from multi-polygon relations have id 0x05 (Parking lot) In my latest batch of changes the polygon rule is: (highway=services | highway=rest_area) & area!=no [0x05 resolution 22] but, I agree, it would be better to have the services area as retail and I'll do this in a following batch I've also taken care, in my latest batch, of the correct handling of ways, closed ways, multi-polygons, mop-ups and how these are processed by 'lines' and/or 'polygons' Ticker On Wed, 2018-12-05 at 08:23 +0000, lig fietser wrote:
On the forum someone asked if highway=services could be added to the polygons style. https://forum.openstreetmap.org/viewtopic.php?pid=728618#p728618
For example like in the generic new maps: landuse=retail | highway=services [0x08 resolution 22-20]
If added, prevent that it also will be mopped up by excluding it in the lines style See https://github.com/ligfietser/mkgmap-style-sheets/commit/984b5ce9 c8a9e9aacc61d0cd022e9768006408c9
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Once my current batch of changes is out of the way the next one will be to change some if the element ids, mostly as per posting 13-Nov-18 17:25 UTC I still think these typ files should go into trunk now and the default -typ branch is abandoned I don't like the name 'mkgmap.txt', not sure what to suggest but no need for mkgmap in the name. Ticker On Wed, 2018-12-05 at 07:23 +0000, Joris Bo wrote:
Hello
I updated a typ-file up to these changes of Ticker Kind regards, Joris
participants (10)
-
Andrzej Popowski -
Bernhard Hiller -
Gerd Petermann -
Greg Troxel -
Joris Bo -
lig fietser -
Lorenzo Mastrogiacomi -
Michael Poesdorf -
Ticker Berkin -
Ticker Berkin