Re: [mkgmap-dev] default style improvements
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 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 [_id] ProductCode=1 FID=8000 CodePage=1252 [End] [_drawOrder] Type=0x4B,1 Type=0x53,1 Type=0x02,2 Type=0x03,2 Type=0x07,2 Type=0x08,2 Type=0x09,2 Type=0x10,2 Type=0x16,2 Type=0x18,2 Type=0x1E,2 Type=0x1F,2 Type=0x32,2 Type=0x3B,2 Type=0x3D,2 Type=0x46,2 Type=0x47,2 Type=0x48,2 Type=0x4C,2 Type=0x4D,2 Type=0x51,2 Type=0x6B,2 Type=0x0A,3 Type=0x0C,3 Type=0x1A,3 Type=0x4E,3 Type=0x50,3 Type=0x0B,4 Type=0x4F,4 Type=0x17,5 Type=0x05,6 Type=0x19,6 Type=0x3C,6 Type=0x3F,6 Type=0x41,6 Type=0x06,7 Type=0x0E,7 Type=0x13,8 Type=0x6A,8 Type=0x6C,9 Type=0x04,10 [end] [_polygon] Type=0x02 ;polygon type:6 ;draworder:2 ;&9C DBlk:&15F5 String1=0x1,Résidentiel String2=0x2,Wohngebiet String3=0x4,Residential String4=0x3,Bebouwing String5=0x9, ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #E0DFDF" [end] [_polygon] Type=0x03 ;polygon type:6 ;draworder:2 ; DBlk:&15F9 String1=0x1,Résidentiel String2=0x2,Wohngebiet String3=0x4,Residential String4=0x3,Bebouwing String5=0x9, ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #E0DFDF" [end] [_polygon] Type=0x05 ;polygon type:6 ;draworder:6 ;&130 DBlk:&15FD String1=0x1,Parking String2=0x2,Parkplatz String3=0x4,Parking String4=0x3,Parkeerterrein String5=0x9, ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #EE" [end] [_polygon] Type=0x06 ;polygon type:6 ;draworder:7 ;&176 DBlk:&1601 String1=0x1,Garagen String2=0x2,Garages String3=0x4,Garages String4=0x3,Garages String5=0x9, ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #DFDDCE" [end] [_polygon] Type=0x07 ;polygon type:6 ;draworder:2 ;&1B3 DBlk:&1605 String1=0x1,Aéroport String2=0x2,Flughafen String3=0x4,Airport String4=0x3,Vliegveld String5=0x9, ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #E9E7E2" [end] [_polygon] Type=0x08 ;polygon type:6 ;draworder:2 ;&1F5 DBlk:&1609 String1=0x1,Zone commerciale String2=0x2,Gewerbegebiet String3=0x4,Commercial area String4=0x3,Commercieel gebied String5=0x9, ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #F2DAD9" [end] [_polygon] Type=0x09 ;polygon type:6 ;draworder:2 ;&254 DBlk:&160D String1=0x1,Piscine String2=0x2,Schwimmbad String3=0x4,Swimmingpool String4=0x3,Zwembad String5=0x9, ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #AAD3DF" [end] [_polygon] Type=0x0a ;polygon type:6 ;draworder:3 ;&299 DBlk:&1611 String1=0x1,École String2=0x2,Schule String3=0x4,Education String4=0x3,School String5=0x9, ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #E5" [end] [_polygon] Type=0x0b ;polygon type:6 ;draworder:4 ;&2D4 DBlk:&1615 String1=0x1,Hospital String2=0x2,Krankenhaus String3=0x4,Hospital String4=0x3,Ziekenhuis String5=0x9, ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #E5" [end] [_polygon] Type=0x0c ;polygon type:6 ;draworder:3 ;&31A DBlk:&1619 String1=0x1,Zone industrielle String2=0x2,Industriegebiet String3=0x4,Industrial area String4=0x3,Industriegebied String5=0x9, ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #EBDBE8" [end] [_polygon] Type=0x0e ;polygon type:6 ;draworder:7 ;&379 DBlk:&161D String1=0x1, String2=0x2,Landfläche String3=0x4,Aeroway String4=0x3,Landingsbaan String5=0x9, ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #CC" [end] [_polygon] Type=0x00F00 ;3B7 DBlk:&1621 String1=0x01,Commercial String2=0x02,Commercial String3=0x03,Commercial String4=0x04,Commercial ;polygon type: 8 ExtendedLabels=Y FontStyle=Nolabel Xpm="0 0 1 0" "0 c #EBDBE8" [end] [_polygon] Type=0x10 ;polygon type:6 ;draworder:2 ;&470 DBlk:&1625 String1=0x1,Résidentiel String2=0x2,Wohngebiet String3=0x4,Residential String4=0x3,Bebouwing String5=0x9, E
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
Re: [mkgmap-dev] default style improvements
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 Im Auftrag von Ticker Berkin Gesendet: Dienstag, 19. Februar 2019 11:57 An: Development list for mkgmap 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-
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Michael Poesdorf 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 Im Auftrag von Ticker Berkin Gesendet: Montag, 11. Februar 2019 20:43 An: Development list for mkgmap 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 Im Auftrag > von Gerd Petermann > Gesendet: Dienstag, 5. Februar 2019 09:26 > An: Ticker Berkin ; Development list for > mkgmap > 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 im Auftrag > von Ticker Berkin > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
Re: [mkgmap-dev] default style improvements
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 Im Auftrag von Ticker Berkin Gesendet: Montag, 11. Februar 2019 20:43 An: Development list for mkgmap 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 Im Auftrag > von Gerd Petermann > Gesendet: Dienstag, 5. Februar 2019 09:26 > An: Ticker Berkin ; Development list for > mkgmap > 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 im Auftrag > von Ticker Berkin > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 Im Auftrag > von Gerd > Petermann > Gesendet: Dienstag, 5. Februar 2019 09:26 > An: Ticker Berkin ; Development list for > mkgmap > > 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 im Auftrag > von > Ticker Berkin > 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
Re: [mkgmap-dev] default style improvements
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 Im Auftrag von Gerd Petermann Gesendet: Dienstag, 5. Februar 2019 09:26 An: Ticker Berkin ; Development list for mkgmap 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 im Auftrag von Ticker Berkin 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
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 im Auftrag von Ticker Berkin 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
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
Re: [mkgmap-dev] default style improvements / upated typ-file
Hi Some comments on "Some changes to be considered?" On Sun, 2019-01-13 at 11:11 +, Joris Bo wrote: > Hello, ... > Some changes to be considered? > === > Different kinds of public transport are mapped to the same symbol. > For now I choose the arbritary bus_station as the most common > Line 106: amenity=bus_station [0x2f08 resolution 23] > Line 126: amenity=ferry_terminal [0x2f08 resolution 22] > Line 206: railway=station [0x2f08 resolution 22] > Line 207: (public_transport=platform & rail=yes) | railway=halt > [0x2f08 resolution 23] > These POI should fit in with "Find"/"Where to?" > "Transportation" which has categories: 0x2f02: Auto Rental 0x2f04: Air Transportation 0x2f08: Ground Transportation 0x0f17: Transit Service so there isn't scope for different symbols > Different kinds of roads mapped to the same linetype, especially > cycleways deserve there on linetype I think > Line 190: highway=bridleway [0x07 road_class=0 road_speed=0 > resolution 23] > Line 197: highway=service & service=parking_aisle [0x07 > road_class=0 road_speed=1 resolution 24] > Line 198: highway=service & (service=alley | service=driveway) > [0x07 road_class=0 road_speed=0 resolution 23] > Line 199: highway=service [0x07 road_class=0 road_speed=2 > resolution 22] > Line 201: highway=cycleway [0x07 road_class=0 road_speed=1 > resolution 23] > Line 214: highway=turning_loop | highway=turning_circle | > highway=layby | highway=escape | highway=emergency_bay [0x07 > road_class=0 road_speed=0 resolution 24] I've changed cycleway to have use lineType 0x11. The others all represent ways that support a motor vehicle, and 0x07 (Alley) is the best fit for this in the standard Garmin Road types. Some could be changed to use the other, unused, lineTypes in the range 0x0d .. 0x13. These support routing, and, without a typ-file, show as a thin black line with label 'Line' on some Garmin devices, but not on all. > Add different (non-routable) linetype for highway = construction > instead of converting them to a routable footway (0x16) I think the original idea was that you'd be able to walk where the highway was being constructed; this is probably wrong and it would be clearer to show nothing. I can change this in a future revision if there is a consensus > Any comments, please let me know, > Kind regards Joris Regards Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Date: Mon, 21 Jan 2019 07:09:30 + From: Ticker Berkin To: Development list for mkgmap Subject: Re: [mkgmap-dev] default style improvements 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 Ticker, as a frequent user of Mkgmap, I want to commend you for all the thought you've put into trying to make the output better. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements / updated typ-file
Grazie mille, Lorenzo Van: mkgmap-dev Namens Lorenzo Mastrogiacomi Verzonden: maandag 21 januari 2019 00:19 Aan: mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] default style improvements / updated typ-file Attached my italian translation too. Lorenzo Il giorno dom, 20/01/2019 alle 12.17 -0200, Wesley Martins ha scritto: Hello Joris, Attached is the portuguese translation. Added column for portuguese and sortorder column is intact. ;D Regards Wesley On Sat, Jan 19, 2019 at 9:08 AM Joris Bo mailto:jori...@hotmail.com>> wrote: Super Ralf, Danke! Habe es schon verarbeitet Gr Joris -Oorspronkelijk bericht- Van: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> Namens Ralf Kleineisel Verzonden: zaterdag 19 januari 2019 11:57 Aan: Development list for mkgmap mailto:mkgmap-dev@lists.mkgmap.org.uk>> Onderwerp: Re: [mkgmap-dev] default style improvements / updated typ-file Hi, On 1/19/19 11:38 AM, Joris Bo wrote: > That’s very kind, thank you. > > Attached an excel with the exported translations up to r4262 > > Just add a column for any new language I just corrected a few issues in the german column. ___ 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 <mailto:mkgmap-dev@lists.mkgmap.org.uk> mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> 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
Re: [mkgmap-dev] default style improvements
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
Index: resources/styles/default/polygons
===
--- resources/styles/default/polygons (revision 4265)
+++ resources/styles/default/polygons (working copy)
@@ -37,8 +37,8 @@
healthcare=hospital | amenity=hospital | amenity=clinic [0x0b resolution 22]
healthcare=* | amenity=dentist | amenity=doctors | amenity=nursing_home [0x0b resolution 23]
-leisure=common [0x17 resolution 21]
-leisure=garden [0x17 resolution 21]
+leisure=common [0x1d resolution 21]
+leisure=garden [0x20 resolution 21]
leisure=golf_course [0x18 resolution 21]
leisure=ice_rink [0x19 resolution 22]
leisure=nature_reserve [0x16 resolution 19]
@@ -57,18 +57,18 @@
shop=* {add name='${shop|subst:"_=> "}'} [0x08 resolution 22]
# squares and plazas
-place=square [0x17 resolution 22]
-highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x17 resolution 22]
+place=square [0x25 resolution 22]
+highway=pedestrian & (area=yes | mkgmap:mp_created=true) [0x25 resolution 22]
# following rule also renders a closed way without area attribute as a plaza
-highway=pedestrian & area!=no [0x17 resolution 22]
+highway=pedestrian & area!=no [0x25 resolution 22]
# footways areas are similar, but should be explicity marked as such
-highway=footway & area=yes [0x17 resolution 24]
+highway=footway & area=yes [0x25 resolution 24]
-# other highways that have area=yes are probably parking lots, eg services/rest_area
-(highway=services | highway=rest_area) & area!=no [0x05 resolution 22]
+highway=services [0x12 resolution 22] # service station complex; show as retail
+highway=rest_area & area!=no [0x05 resolution 22] # show as parking lot
-historic=* & historic!=no & historic!=yes & boundary!=* {add name='${historic|subst:"_=> "}'} [0x1e resolution 21]
+historic=* & historic!=no & historic!=yes & boundary!=* {add name='${historic|subst:"_=> "}'} [0x22 resolution 21]
landuse=basin [0x3f resolution 20]
landuse=reservoir | (natural=water & water=reservoir) [0x3f resolution 20]
@@ -78,7 +78,9 @@
natural=bay [0x3d resolution 18]
natural=glacier [0x4d resolution 18]
natural=marsh [0x51 resolution 20]
+natural=tundra [0x52 resolution 18]
natural=mud [0x51 resolution 20]
+natural=beach | natural=sand [0x53 resolution 20]
natural=wetland [0x51 resolution 20]
natural=water & water=canal [0x48 resolution 22]
natural=water & water=lock [0x4c resolution 22 default_name 'Lock']
@@ -94,13 +96,14 @@
landuse=allotments [0x4e resolution 21]
landuse=cemetery | landuse=cemetary | amenity=grave_yard [0x1a resolution 21]
-landuse=commercial [0x0c resolution 19]
+landuse=commercial [0x0f resolution 19]
landuse=construction [0x0c resolution 21]
-landuse=farm | landuse=farmland [0x4e resolution 20]
-landuse=farmyard [0x10 resolution 22]
+landuse=farm [0x26 resolution 22]
+landuse=farmland [0x1c resolution 20]
+landuse=farmyard [0x26 resolution 22]
landuse=forest | landuse=wood [0x50 resolution 20]
-landuse=greenfield [0x17 resolution 20]
-landuse=meadow | landuse=grass [0x17 resolution 19]
+landuse=greenfield [0x1c resolution 20]
+landuse=meadow | landuse=grass [0x1c resolution 19]
landuse=military [0x04 resolution 19]
landuse=quarry
Re: [mkgmap-dev] default style improvements
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
Index: resources/styles/default/lines
===
--- resources/styles/default/lines (revision 4265)
+++ resources/styles/default/lines (working copy)
@@ -117,9 +117,11 @@
highway=path & foot=designated
{set highway=footway}
-leisure=track & area!=yes {add highway=footway; name '${name} (${sport})' | '${name}'}
+leisure=track & area!=yes {name '${name} (${sport})' | '${sport}'} [0x30 resolution 22]
man_made=pier | man_made=piste:halfpipe {add highway=footway; name '${ref} ${name}' | '${ref}' | '${name}'}
+man_made=breakwater & is_closed()=false & mkgmap:mp_created!=true [0x17 resolution 22 default_name 'Breakwater']
+
# Roundabouts
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c road_class=4 road_speed=2 resolution 24 continue]
junction=roundabout & (highway=trunk | highway=trunk_link) [0x10801 resolution 18]
@@ -155,18 +157,18 @@
# Ways sorted roughly by descending order of class
highway=motorway & mkgmap:fast_road=yes [0x01 road_class=4 road_speed=7 resolution 14]
highway=motorway [0x01 road_class=4 road_speed=7 resolution 15]
-highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) [0x06 road_class=4 road_speed=2 resolution 20]
+highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) [0x0b road_class=4 road_speed=2 resolution 20]
highway=motorway_link [0x09 road_class=4 road_speed=2 resolution 20]
highway=trunk & mkgmap:fast_road=yes [0x02 road_class=4 road_speed=5 resolution 15]
highway=trunk [0x02 road_class=4 road_speed=5 resolution 18]
-highway=trunk_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) [0x06 road_class=4 road_speed=2 resolution 20]
+highway=trunk_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) [0x0b road_class=4 road_speed=2 resolution 20]
highway=trunk_link [0x09 road_class=4 road_speed=2 resolution 20]
highway=* & motorroad=yes [0x02 road_class=4 road_speed=4 resolution 18]
highway=primary & mkgmap:fast_road=yes [0x03 road_class=4 road_speed=4 resolution 17]
highway=primary [0x03 road_class=3 road_speed=4 resolution 19]
-highway=primary_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) & mkgmap:fast_road=yes [0x06 road_class=4 road_speed=1 resolution 21]
-highway=primary_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) [0x06 road_class=3 road_speed=1 resolution 21]
+highway=primary_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) & mkgmap:fast_road=yes [0x0b road_class=4 road_speed=1 resolution 21]
+highway=primary_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) [0x0b road_class=3 road_speed=1 resolution 21]
highway=primary_link & mkgmap:fast_road=yes [0x08 road_class=4 road_speed=1 resolution 21]
highway=primary_link [0x08 road_class=3 road_speed=1 resolution 21]
highway=secondary & mkgmap:fast_road=yes [0x04 road_class=3 road_speed=3 resolution 18]
@@ -198,7 +200,7 @@
highway=service & (service=alley | service=driveway) [0x07 road_class=0 road_speed=0 resolution 23]
highway=service [0x07 road_class=0 road_speed=2 resolution 22]
-highway=cycleway [0x07 road_class=0 road_speed=1 resolution 23]
+highway=cycleway [0x11 road_class=0 road_speed=1 resolution 23]
# highway=footway is often an area as well, continue for polygon processing
highway=footway {set tmp:stopMopUp=yes} [0x16 road_class=0 road_speed=0 resolution 23 continue with_actions]
@@ -251,13 +253,15 @@
boundary=national [0x1e resolution 17]
boundary=political [0x1c resolution 19]
+barrier=wall | barrier=fence | barrier=hedge | barrier=ditch {add name='${barrier|subst:"_=> "}'} [0x17 resolution 24]
+
route=ferry & (toll=no | toll=false) {set mkgmap:toll=no}
route=ferry {set mkgmap:numbers=false; set mkgmap:ferry=1; add mkgmap:toll=yes}
route=ferry & (motorcar=no | motor_vehicle=no) [0x1b road_class=0 road_speed=0 resolution 23]
-route=ferry [0x1b road_class=3 road_speed=0 resolution 19]
+route=ferry [0x1a road_class=3 road_speed=0 resolution 19]
(waterway=river | waterway=canal) & intermittent=yes [0x26 resolution 20]
-(waterway=stream | waterway=drain) & intermittent=yes [0x10A02 resolution 22]
+(waterway=stream | waterway=drain) & intermittent=yes [0x26 resolution 22]
waterway=canal [0x1f resolution 21]
waterway=river
Re: [mkgmap-dev] default style improvements
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
Index: resources/styles/default/points
===
--- resources/styles/default/points (revision 4265)
+++ resources/styles/default/points (working copy)
@@ -156,8 +156,7 @@
amenity=taxi [0x2f17 resolution 24]
amenity=telephone [0x2f12 resolution 24 default_name 'Telephone']
amenity=theatre [0x2d01 resolution 24]
-amenity=toilets & highway=rest_area [0x2f0c resolution 24]
-amenity=toilets [0x4e00 resolution 24 default_name 'Toilets']
+amenity=toilets [0x2f0c resolution 24 default_name 'Toilets']
amenity=townhall [0x3003 resolution 24]
amenity=university [0x2c05 resolution 24]
# amenity=zoo is superceded by tourism=zoo
@@ -266,6 +265,7 @@
tourism=wilderness_hut [0x2b07 resolution 24 default_name 'wilderness hut']
tourism=museum [0x2c02 resolution 24]
tourism=picnic_site [0x4a00 resolution 24]
+tourism=resort [0x2b04 resolution 24]
tourism=theme_park [0x2c01 resolution 24]
tourism=viewpoint {name '${name} - ${description}' | '${name}'} [0x2c04 resolution 24]
tourism=wine_cellar [0x2c0a resolution 24]
@@ -329,8 +329,9 @@
#amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'} [0x2a07 resolution 24]
#amenity=fast_food [0x2a07 resolution 24]
-barrier=bollard | barrier=bus_trap | barrier=gate [0x660f resolution 24]
-barrier=block | barrier=cycle_barrier | barrier=stile | barrier=kissing_gate [0x660f resolution 24]
+barrier=bollard | barrier=bus_trap | barrier=gate | barrier=block | barrier=cycle_barrier |
+barrier=stile | barrier=kissing_gate | barrier=lift_gate | barrier=swing_gate
+{add name='${barrier|subst:"_=> "}'} [0x3200 resolution 24]
landuse=basin | landuse=reservoir [0x650f resolution 24]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements / updated typ-file
Hi
Sorry about the delay in replying.
I couldn't decide on a good colour for Historic either, and, at the
moment, I use the same colour for Building, Historic and Amenity.
I think the default style should output them as polygons not POI. A typ
-file can consider not rendering these polygons.
Ticker
On Wed, 2019-01-16 at 18:56 +, Joris Bo wrote:
> Hello
>
> Thx Nick
> Attached both issues changed
>
> @Ticker
> It was not easy to address a good polygon color for [0x1e] used for
> ‘historic’
> historic=* & historic!=no & historic!=yes & boundary!=* {add
> name='${historic|subst:"_=> "}'} [0x1e resolution 21]
>
> “Historic” can be used on almost anything from park to building to
> museum and ruins.
> After a compare on ‘Luxembourg’ I decided that ‘building’ is the most
> common occurrence.
> So I choosed the arbritrary color ‘grey’
>
> Maybe you could consider to use poi’s instead of polygons for
> historic.
> If somebody likes a different color, give me a hint.
>
> Kind regards,
> Joris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements / updated typ-file
Attached my italian translation too. Lorenzo Il giorno dom, 20/01/2019 alle 12.17 -0200, Wesley Martins ha scritto: > Hello Joris, > Attached is the portuguese translation. > Added column for portuguese and sortorder column is intact. ;D > > Regards > > Wesley > > > > On Sat, Jan 19, 2019 at 9:08 AM Joris Bo wrote: > > Super Ralf, Danke! > > > > Habe es schon verarbeitet > > > > > > > > Gr Joris > > > > > > > > > > > > -Oorspronkelijk bericht- > > > > Van: mkgmap-dev Namens > > Ralf Kleineisel > > > > Verzonden: zaterdag 19 januari 2019 11:57 > > > > Aan: Development list for mkgmap > > > > Onderwerp: Re: [mkgmap-dev] default style improvements / updated > > typ-file > > > > > > > > Hi, > > > > > > > > On 1/19/19 11:38 AM, Joris Bo wrote: > > > > > > > > > That’s very kind, thank you. > > > > > > > > > > Attached an excel with the exported translations up to r4262 > > > > > > > > > > Just add a column for any new language > > > > > > > > I just corrected a few issues in the german column. > > > > ___ > > > > mkgmap-dev mailing list > > > > mkgmap-dev@lists.mkgmap.org.uk > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > ___mkgmap-dev mailing > listmkgmap-...@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 20190119b_Translations_r4262_italiano.xlsx Description: MS-Excel 2007 spreadsheet ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements / updated typ-file
Hello Joris, Attached is the portuguese translation. Added column for portuguese and sortorder column is intact. ;D Regards Wesley On Sat, Jan 19, 2019 at 9:08 AM Joris Bo wrote: > Super Ralf, Danke! > Habe es schon verarbeitet > > Gr Joris > > > -Oorspronkelijk bericht- > Van: mkgmap-dev Namens Ralf > Kleineisel > Verzonden: zaterdag 19 januari 2019 11:57 > Aan: Development list for mkgmap > Onderwerp: Re: [mkgmap-dev] default style improvements / updated typ-file > > Hi, > > On 1/19/19 11:38 AM, Joris Bo wrote: > > > That’s very kind, thank you. > > > > Attached an excel with the exported translations up to r4262 > > > > Just add a column for any new language > > I just corrected a few issues in the german column. > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev portuguese.xlsx Description: MS-Excel 2007 spreadsheet ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements / updated typ-file
Super Ralf, Danke! Habe es schon verarbeitet Gr Joris -Oorspronkelijk bericht- Van: mkgmap-dev Namens Ralf Kleineisel Verzonden: zaterdag 19 januari 2019 11:57 Aan: Development list for mkgmap Onderwerp: Re: [mkgmap-dev] default style improvements / updated typ-file Hi, On 1/19/19 11:38 AM, Joris Bo wrote: > That’s very kind, thank you. > > Attached an excel with the exported translations up to r4262 > > Just add a column for any new language I just corrected a few issues in the german column. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements / updated typ-file
Hi, On 1/19/19 11:38 AM, Joris Bo wrote: > That’s very kind, thank you. > > Attached an excel with the exported translations up to r4262 > > Just add a column for any new language I just corrected a few issues in the german column. 20190119b Translations r4262.xlsx Description: MS-Excel 2007 spreadsheet ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements / updated typ-file
Hi Wesley,
That’s very kind, thank you.
Attached an excel with the exported translations up to r4262
Just add a column for any new language
As long as the sortorder column remains intact it should be pretty easy to
merge them into a new export.
Kind regards, Joris
Van: mkgmap-dev Namens Wesley Martins
Verzonden: zaterdag 19 januari 2019 11:18
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] default style improvements / updated typ-file
Hello Joris,
I have interest in help with portuguese (0x10) translate.
How can I help?
Regards,
Wesley
On Sat, Jan 19, 2019 at 7:04 AM Joris Bo
mailto:jori...@hotmail.com>> wrote:
Hello Nick
Thx for your feedback!
I wrote a program to extraxt icons from a master library to be used on
different elements in somebodies else his style.
I abuse both language tags as exchange-fields to keep track of mother / child
relationships.
In the final export, those fields are cleared, but you just find out that this
is not bullet proof
Thx, I’ll have a look
Van: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
Namens osm@pinns
Verzonden: vrijdag 18 januari 2019 12:44
Aan: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Onderwerp: Re: [mkgmap-dev] default style improvements / updated typ-file
Hi Jorus
Great job!
Just to be a pain, all (I think) your elements have a one character text
string for Basque and Korean:
ie
String5=0x09,
String6=0x24,
Perhaps you had big plans for translating labels into Basque or Korean ;)
r
Nick
On 16/01/2019 18:56, Joris Bo wrote:
Hello
Thx Nick
Attached both issues changed
@Ticker
It was not easy to address a good polygon color for [0x1e] used for ‘historic’
historic=* & historic!=no & historic!=yes & boundary!=* {add
name='${historic|subst:"_=> "}'} [0x1e resolution 21]
“Historic” can be used on almost anything from park to building to museum and
ruins.
After a compare on ‘Luxembourg’ I decided that ‘building’ is the most common
occurrence.
So I choosed the arbritrary color ‘grey’
Maybe you could consider to use poi’s instead of polygons for historic.
If somebody likes a different color, give me a hint.
Kind regards,
Joris
Van: mkgmap-dev
<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
Namens osm@pinns
Verzonden: dinsdag 15 januari 2019 22:01
Aan: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Onderwerp: Re: [mkgmap-dev] default style improvements / updated typ-file
Hi Jorus
You have a draworder for 0x1e without a matching polygon.
(Also, to have 0x53 sharing the same draworder as 0x4b might depending on your
map be problematic)
r
Nick
On 15/01/2019 20:51, Joris Bo wrote:
Hello
My previous typ had 2 bugs (No draworder for new lake 0x41) making lakes
invisible and missing wilderniss hut
Both are fixed in attached typ.
There were also a couple of polygons and lines having a night color bitmap, for
now I removed them and introduce them again if complete. There is help coming
up from Michael to fill that gap.
Feel free to send more findings
Kind regards
Joris
-Oorspronkelijk bericht-
Van: mkgmap-dev
<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
Namens Ticker Berkin
Verzonden: maandag 14 januari 2019 12:24
Aan: Development list for mkgmap
<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Onderwerp: Re: [mkgmap-dev] default style improvements / upated typ-file
Hi
I agree the name change from mkgmap.txt to something else (no problem with
mapnik.txt) is needed.
I haven't been through this TYP in detail yet. Some of my previous comments
still stands:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q4/029103.html
I'd like another, much, much simpler, TYP file for the default style also to be
available. It would avoid re-defining representation that the typical Garmin
device shows.
In my next set of changes I'm planning to change quite a few TYPE numbers, many
as suggested in this thread on 13-Nov-2018:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q4/029146.html
but there will be some differences from this post.
Some of these cover Joris's "changes to be considered". Some of the other
suggestions I feel are too much for the default style but I will consider them.
It will be a few days before I'm able to do anything in this area.
We need some pointers in the documentation to the collection of TYP -files.
Please can we have these TYP-files in "trunk". I think the "default -typ"
branch it is a hindrance.
Regards
Ticker
On Mon, 2019-01-14 at 06:51 +, Gerd Petermann wrote:
Hi Joris,
I've replaced the default style in the typ branch by that from trunk
and added your typ with that. I hope that was right?
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4263
I think about a move/rename of styles\default\typ.txt to typ
-files\mapnik.txt using the co
Re: [mkgmap-dev] default style improvements / updated typ-file
Hello Joris,
I have interest in help with portuguese (0x10) translate.
How can I help?
Regards,
Wesley
On Sat, Jan 19, 2019 at 7:04 AM Joris Bo wrote:
> Hello Nick
>
>
>
> Thx for your feedback!
>
>
>
> I wrote a program to extraxt icons from a master library to be used on
> different elements in somebodies else his style.
>
> I abuse both language tags as exchange-fields to keep track of mother /
> child relationships.
>
> In the final export, those fields are cleared, but you just find out that
> this is not bullet proof
>
> Thx, I’ll have a look
>
>
>
>
>
> *Van:* mkgmap-dev *Namens *
> osm@pinns
> *Verzonden:* vrijdag 18 januari 2019 12:44
> *Aan:* mkgmap-dev@lists.mkgmap.org.uk
> *Onderwerp:* Re: [mkgmap-dev] default style improvements / updated
> typ-file
>
>
>
> Hi Jorus
>
> Great job!
>
> Just to be a pain, all (I think) your elements have a one character text
> string for Basque and Korean:
>
> ie
>
> String5=0x09,
> String6=0x24,
>
> Perhaps you had big plans for translating labels into Basque or Korean ;)
>
> r
>
> Nick
>
> On 16/01/2019 18:56, Joris Bo wrote:
>
> Hello
>
>
>
> Thx Nick
>
> Attached both issues changed
>
>
>
> @Ticker
>
> It was not easy to address a good polygon color for [0x1e] used for
> ‘historic’
>
> historic=* & historic!=no & historic!=yes & boundary!=* {add
> name='${historic|subst:"_=> "}'} [0x1e resolution 21]
>
>
>
> “Historic” can be used on almost anything from park to building to museum
> and ruins.
>
> After a compare on ‘Luxembourg’ I decided that ‘building’ is the most
> common occurrence.
>
> So I choosed the arbritrary color ‘grey’
>
>
>
> Maybe you could consider to use poi’s instead of polygons for historic.
>
> If somebody likes a different color, give me a hint.
>
>
>
> Kind regards,
>
> Joris
>
>
>
>
>
>
>
>
>
> *Van:* mkgmap-dev
> *Namens *osm@pinns
> *Verzonden:* dinsdag 15 januari 2019 22:01
> *Aan:* mkgmap-dev@lists.mkgmap.org.uk
> *Onderwerp:* Re: [mkgmap-dev] default style improvements / updated
> typ-file
>
>
>
> Hi Jorus
>
> You have a draworder for 0x1e without a matching polygon.
>
> (Also, to have 0x53 sharing the same draworder as 0x4b might depending on
> your map be problematic)
>
> r
>
> Nick
>
> On 15/01/2019 20:51, Joris Bo wrote:
>
> Hello
>
>
>
> My previous typ had 2 bugs (No draworder for new lake 0x41) making lakes
> invisible and missing wilderniss hut
>
> Both are fixed in attached typ.
>
>
>
> There were also a couple of polygons and lines having a night color bitmap,
> for now I removed them and introduce them again if complete. There is help
> coming up from Michael to fill that gap.
>
> Feel free to send more findings
>
>
>
> Kind regards
>
> Joris
>
>
>
>
>
> -Oorspronkelijk bericht-
>
> Van: mkgmap-dev
> Namens Ticker Berkin
>
> Verzonden: maandag 14 januari 2019 12:24
>
> Aan: Development list for mkgmap
>
>
> Onderwerp: Re: [mkgmap-dev] default style improvements / upated typ-file
>
>
>
> Hi
>
>
>
> I agree the name change from mkgmap.txt to something else (no problem with
> mapnik.txt) is needed.
>
>
>
> I haven't been through this TYP in detail yet. Some of my previous comments
> still stands:
>
> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q4/029103.html
>
>
>
> I'd like another, much, much simpler, TYP file for the default style also to
> be available. It would avoid re-defining representation that the typical
> Garmin device shows.
>
>
>
> In my next set of changes I'm planning to change quite a few TYPE numbers,
> many as suggested in this thread on 13-Nov-2018:
>
> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q4/029146.html
>
> but there will be some differences from this post.
>
>
>
> Some of these cover Joris's "changes to be considered". Some of the other
> suggestions I feel are too much for the default style but I will consider
> them.
>
>
>
> It will be a few days before I'm able to do anything in this area.
>
>
>
> We need some pointers in the documentation to the collection of TYP -files.
>
>
>
> Please can we have these TYP-files in "trunk". I think the "default -typ"
> branch it is a hindrance.
>
>
>
> Regards
>
> Ticker
>
>
>
> On Mon, 2019-01-14 at 06:51 +, Gerd Petermann wrote:
>
> Hi Joris,
>
>
>
> I've replaced the default style
Re: [mkgmap-dev] default style improvements / updated typ-file
Hello Nick
Thx for your feedback!
I wrote a program to extraxt icons from a master library to be used on
different elements in somebodies else his style.
I abuse both language tags as exchange-fields to keep track of mother / child
relationships.
In the final export, those fields are cleared, but you just find out that this
is not bullet proof
Thx, I’ll have a look
Van: mkgmap-dev Namens osm@pinns
Verzonden: vrijdag 18 januari 2019 12:44
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] default style improvements / updated typ-file
Hi Jorus
Great job!
Just to be a pain, all (I think) your elements have a one character text
string for Basque and Korean:
ie
String5=0x09,
String6=0x24,
Perhaps you had big plans for translating labels into Basque or Korean ;)
r
Nick
On 16/01/2019 18:56, Joris Bo wrote:
Hello
Thx Nick
Attached both issues changed
@Ticker
It was not easy to address a good polygon color for [0x1e] used for ‘historic’
historic=* & historic!=no & historic!=yes & boundary!=* {add
name='${historic|subst:"_=> "}'} [0x1e resolution 21]
“Historic” can be used on almost anything from park to building to museum and
ruins.
After a compare on ‘Luxembourg’ I decided that ‘building’ is the most common
occurrence.
So I choosed the arbritrary color ‘grey’
Maybe you could consider to use poi’s instead of polygons for historic.
If somebody likes a different color, give me a hint.
Kind regards,
Joris
Van: mkgmap-dev
<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
Namens osm@pinns
Verzonden: dinsdag 15 januari 2019 22:01
Aan: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Onderwerp: Re: [mkgmap-dev] default style improvements / updated typ-file
Hi Jorus
You have a draworder for 0x1e without a matching polygon.
(Also, to have 0x53 sharing the same draworder as 0x4b might depending on your
map be problematic)
r
Nick
On 15/01/2019 20:51, Joris Bo wrote:
Hello
My previous typ had 2 bugs (No draworder for new lake 0x41) making lakes
invisible and missing wilderniss hut
Both are fixed in attached typ.
There were also a couple of polygons and lines having a night color bitmap, for
now I removed them and introduce them again if complete. There is help coming
up from Michael to fill that gap.
Feel free to send more findings
Kind regards
Joris
-Oorspronkelijk bericht-
Van: mkgmap-dev
<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
Namens Ticker Berkin
Verzonden: maandag 14 januari 2019 12:24
Aan: Development list for mkgmap
<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Onderwerp: Re: [mkgmap-dev] default style improvements / upated typ-file
Hi
I agree the name change from mkgmap.txt to something else (no problem with
mapnik.txt) is needed.
I haven't been through this TYP in detail yet. Some of my previous comments
still stands:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q4/029103.html
I'd like another, much, much simpler, TYP file for the default style also to be
available. It would avoid re-defining representation that the typical Garmin
device shows.
In my next set of changes I'm planning to change quite a few TYPE numbers, many
as suggested in this thread on 13-Nov-2018:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q4/029146.html
but there will be some differences from this post.
Some of these cover Joris's "changes to be considered". Some of the other
suggestions I feel are too much for the default style but I will consider them.
It will be a few days before I'm able to do anything in this area.
We need some pointers in the documentation to the collection of TYP -files.
Please can we have these TYP-files in "trunk". I think the "default -typ"
branch it is a hindrance.
Regards
Ticker
On Mon, 2019-01-14 at 06:51 +, Gerd Petermann wrote:
Hi Joris,
I've replaced the default style in the typ branch by that from trunk
and added your typ with that. I hope that was right?
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4263
I think about a move/rename of styles\default\typ.txt to typ
-files\mapnik.txt using the command svn move styles\default\typ.txt
typ-files\mapnik.txt
Would that be okay for you?
Reg. the other changes I hope that Ticker has an answer.
Gerd
Von: mkgmap-dev
<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
im Auftrag
von Joris Bo <mailto:jori...@hotmail.com>
Gesendet: Sonntag, 13. Januar 2019 12:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] default style improvements / upated typ
-file
Hello,
I modified the type-file up to Ticker's changes in build r4262.
Latest changes can also be found on
https://github.com/Jorisbo/Mkgmap-Mapnik-Style-Garmin
It already reflects some new mapnik colors which will be first visible
on www.openstreetmap.org<htt
Re: [mkgmap-dev] default style improvements / upated typ-file
Hi
I agree the name change from mkgmap.txt to something else (no problem
with mapnik.txt) is needed.
I haven't been through this TYP in detail yet. Some of my previous
comments still stands:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q4/029103.html
I'd like another, much, much simpler, TYP file for the default style
also to be available. It would avoid re-defining representation that
the typical Garmin device shows.
In my next set of changes I'm planning to change quite a few TYPE
numbers, many as suggested in this thread on 13-Nov-2018:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q4/029146.html
but there will be some differences from this post.
Some of these cover Joris's "changes to be considered". Some of the
other suggestions I feel are too much for the default style but I will
consider them.
It will be a few days before I'm able to do anything in this area.
We need some pointers in the documentation to the collection of TYP
-files.
Please can we have these TYP-files in "trunk". I think the "default
-typ" branch it is a hindrance.
Regards
Ticker
On Mon, 2019-01-14 at 06:51 +, Gerd Petermann wrote:
> Hi Joris,
>
> I've replaced the default style in the typ branch by that from trunk
> and added your typ with that. I hope that was right?
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4263
>
> I think about a move/rename of styles\default\typ.txt to typ
> -files\mapnik.txt using the command
> svn move styles\default\typ.txt typ-files\mapnik.txt
>
> Would that be okay for you?
>
> Reg. the other changes I hope that Ticker has an answer.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Joris Bo
> Gesendet: Sonntag, 13. Januar 2019 12:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] default style improvements / upated typ
> -file
>
> Hello,
>
> I modified the type-file up to Ticker's changes in build r4262.
> Latest changes can also be found on
> https://github.com/Jorisbo/Mkgmap-Mapnik-Style-Garmin
> It already reflects some new mapnik colors which will be first
> visible on www.openstreetmap.org in a couple of days
>
>
> The deltas I found after comparing Tickers changes are
> ===
> Added rendering for polygons
> 1)
> place=suburb [0x02 resolution 19]
> 2)
> # mop up any remaining water areas
> waterway=* & waterway!=no & area!=no {add
> name='${waterway|subst:"_=> "}'} [0x3b resolution 22]
> 3)
> natural=water & area_size() < 10 [0x41 resolution 22] #
> Small Lake
> 4)
> dock=drydock [0x4c resolution 22] # might also have
> natural=water
> natural=water & water=lock [0x4c resolution 22 default_name
> 'Lock']
>
> Added rendering for lines
> 5)
> highway=raceway | highway=gallop {add name='${highway}'}
> [0x30 resolution 23]
>
>
> Some changes to be considered?
> ===
> Different kinds of public transport are mapped to the same symbol.
> For now I choose the arbritary bus_station as the most common
> Line 106: amenity=bus_station [0x2f08 resolution 23]
> Line 126: amenity=ferry_terminal [0x2f08 resolution 22]
> Line 206: railway=station [0x2f08 resolution 22]
> Line 207: (public_transport=platform & rail=yes) |
> railway=halt [0x2f08 resolution 23]
>
> Different kinds of roads mapped to the same linetype, especially
> cycleways deserve there on linetype I think
> Line 190: highway=bridleway [0x07 road_class=0 road_speed=0
> resolution 23]
> Line 197: highway=service & service=parking_aisle [0x07
> road_class=0 road_speed=1 resolution 24]
> Line 198: highway=service & (service=alley |
> service=driveway) [0x07 road_class=0 road_speed=0 resolution 23]
> Line 199: highway=service [0x07 road_class=0 road_speed=2
> resolution 22]
> Line 201: highway=cycleway [0x07 road_class=0 road_speed=1
> resolution 23]
> Line 214: highway=turning_loop | highway=turning_circle |
> highway=layby | highway=escape | highway=emergency_bay [0x07
> road_class=0 road_speed=0 resolution 24]
>
> Add different (non-routable) linetype for highway = construction
> instead of converting them to a routable footway (0x16)
>
> Any comments, please let me know,
> Kind regards Joris
>
>
>
> -Oorspronkelijk bericht-
> Van: mkgmap-dev Namens
> Ticker Berkin
> Verzonden: vrijdag 11 januari 2019 10:30
> Aan: Development list for mkgmap
> Onderwerp: Re: [mkgmap-dev] default style improvements
>
> Hi Gerd
&
Re: [mkgmap-dev] default style improvements / upated typ-file
Hi Joris,
I've replaced the default style in the typ branch by that from trunk and added
your typ with that. I hope that was right?
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4263
I think about a move/rename of styles\default\typ.txt to typ-files\mapnik.txt
using the command
svn move styles\default\typ.txt typ-files\mapnik.txt
Would that be okay for you?
Reg. the other changes I hope that Ticker has an answer.
Gerd
Von: mkgmap-dev im Auftrag von Joris
Bo
Gesendet: Sonntag, 13. Januar 2019 12:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] default style improvements / upated typ-file
Hello,
I modified the type-file up to Ticker's changes in build r4262.
Latest changes can also be found on
https://github.com/Jorisbo/Mkgmap-Mapnik-Style-Garmin
It already reflects some new mapnik colors which will be first visible on
www.openstreetmap.org in a couple of days
The deltas I found after comparing Tickers changes are
===
Added rendering for polygons
1)
place=suburb [0x02 resolution 19]
2)
# mop up any remaining water areas
waterway=* & waterway!=no & area!=no {add name='${waterway|subst:"_=>
"}'} [0x3b resolution 22]
3)
natural=water & area_size() < 10 [0x41 resolution 22] # Small Lake
4)
dock=drydock [0x4c resolution 22] # might also have natural=water
natural=water & water=lock [0x4c resolution 22 default_name 'Lock']
Added rendering for lines
5)
highway=raceway | highway=gallop {add name='${highway}'} [0x30
resolution 23]
Some changes to be considered?
===
Different kinds of public transport are mapped to the same symbol. For now I
choose the arbritary bus_station as the most common
Line 106: amenity=bus_station [0x2f08 resolution 23]
Line 126: amenity=ferry_terminal [0x2f08 resolution 22]
Line 206: railway=station [0x2f08 resolution 22]
Line 207: (public_transport=platform & rail=yes) | railway=halt [0x2f08
resolution 23]
Different kinds of roads mapped to the same linetype, especially cycleways
deserve there on linetype I think
Line 190: highway=bridleway [0x07 road_class=0 road_speed=0 resolution
23]
Line 197: highway=service & service=parking_aisle [0x07 road_class=0
road_speed=1 resolution 24]
Line 198: highway=service & (service=alley | service=driveway) [0x07
road_class=0 road_speed=0 resolution 23]
Line 199: highway=service [0x07 road_class=0 road_speed=2 resolution 22]
Line 201: highway=cycleway [0x07 road_class=0 road_speed=1 resolution
23]
Line 214: highway=turning_loop | highway=turning_circle | highway=layby
| highway=escape | highway=emergency_bay [0x07 road_class=0 road_speed=0
resolution 24]
Add different (non-routable) linetype for highway = construction instead of
converting them to a routable footway (0x16)
Any comments, please let me know,
Kind regards Joris
-Oorspronkelijk bericht-
Van: mkgmap-dev Namens Ticker Berkin
Verzonden: vrijdag 11 januari 2019 10:30
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] default style improvements
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/loc
Re: [mkgmap-dev] default style improvements
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 +, Gerd Petermann wrote:
> Hi Ticker,
>
> please, can you summarize the changes implemented with this patch?
> Need this for the svn commit message.
>
> Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Hi Ticker, please, can you summarize the changes implemented with this patch? Need this for the svn commit message. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin 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 +, Gerd Petermann wrote: > Hi Ticker, > > I've made a few modifications discussed before. For me this version > would be OK. > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > 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 +, 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 defaultStyleTidy3e.patch Description: defaultStyleTidy3e.patch ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Hi Ticker, oops, I didn't understand that 0x05 is displayed as "parking lot". I'll remove that again. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin 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 +, Gerd Petermann wrote: > Hi Ticker, > > I've made a few modifications discussed before. For me this version > would be OK. > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > 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 +, 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 +, Gerd Petermann wrote: > Hi Ticker, > > I've made a few modifications discussed before. For me this version > would be OK. > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > 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 +, 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
Re: [mkgmap-dev] default style improvements
Hi Ticker, I've made a few modifications discussed before. For me this version would be OK. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin 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 +, 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] defaultStyleTidy3d.patch Description: defaultStyleTidy3d.patch ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 +, 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]Index: resources/styles/default/inc/access_country
===
--- resources/styles/default/inc/access_country (revision 4261)
+++ resources/styles/default/inc/access_country (working copy)
@@ -4,19 +4,26 @@
# Belgium (BEL)
-highway=trunk & mkgmap:country=BEL { add bicycle=no; add foot=no }
-highway=cycleway & mkgmap:country=BEL { add foot=yes }
-highway=bridleway & mkgmap:country=BEL { add foot=yes }
+highway=trunk & mkgmap:country=BEL {add bicycle=no; add foot=no}
+highway=cycleway & mkgmap:country=BEL {add foot=yes}
+highway=bridleway & mkgmap:country=BEL {add foot=yes}
# The Netherlands (NLD)
-highway=trunk & mkgmap:country=NLD { add bicycle=no; add foot=no }
-highway=cycleway & mkgmap:country=NLD { add foot=yes }
-highway=bridleway & mkgmap:country=NLD { add foot=yes }
+highway=trunk & mkgmap:country=NLD {add bicycle=no; add foot=no}
+highway=cycleway & mkgmap:country=NLD {add foot=yes}
+highway=bridleway & mkgmap:country=NLD {add foot=yes}
# Spain (ESP)
-highway=trunk & mkgmap:country=ESP { add bicycle=yes; add foot=yes }
-highway=bridleway & mkgmap:country=ESP { add bicycle=yes; add foot=yes }
+highway=trunk & mkgmap:country=ESP {add bicycle=yes; add foot=yes}
+highway=bridleway & mkgmap:country=ESP {add bicycle=yes; add foot=yes}
+# United Kingdom (GBR)
+highway=cycleway & mkgmap:country=GBR {add foot=yes}
+highway=bridleway & mkgmap:country=GBR {
+add bicycle=yes;
+add foot=yes;
+add motor_vehicle=private
+}
Index: resources/styles/default/lines
===
--- resources/styles/default/lines (revision 4261)
+++ resources/styles/default/lines (working copy)
@@ -10,9 +10,12 @@
addr:housenumber=* {set mkgmap:execute_finalize_rules=true}
-aeroway=runway & highway!=* & is_closed()=false {name '${ref}'} [0x27 resolution 20]
-(aeroway=taxiway | aeroway=taxilane) & highway!=* & is_closed()=false {name '${ref}'} [0x27 resolution 24]
+abandoned=yes {deletealltags} # old, depreciated, ambiguous, method of handling abandoned
+# do these as lines regardless of being closed unless explicity marked as area. continue in case also a highway
+aeroway=runway & area!=yes {name '${ref}'} [0x27 resolution 20 continue]
+(aeroway=taxiway | aeroway=taxilane) & area!=yes {name '${ref}'} [0x27 resolution 24 continue]
+
# Assign the street name for house number search
highway=* & name=* {set mkgmap:street='${name}'}
@@ -19,22 +22,21 @@
# Mark highways with the toll flag
highway=* & (toll=yes | toll=true) {set mkgmap:toll=yes}
-# mark multipolygons as area
-highway=* & mkgmap:mp_created=true {add area=yes}
-
# Hide proposed ways
highway=proposed | highway=proposal | highway=planned | highway~'.*proposed.*' {delete highway; delete junction}
# Hide removed ways
-highway=razed | highway=dismantled {deletealltags}
+highway=razed | highway=dismantled | highway=disused | highway=demolished {delete highway; delete junction}
# Hide abandoned ways. Abandoned highways have some evidence of their former existence but are no longer used. These
# abandoned highways could be useful in topographical maps.
# https://wiki.openstreetmap.org/wiki/Key:abandoned:
-(abandoned:highway=* & highway!=*) | highway=abandoned {deletealltags}
+(abandoned:highway=* & (highway!=* | highway=yes)) | highway=abandoned {delete highway; delete junction}
# Hide other non-existent ways
highway=unbuilt | highway=neverbuilt | highway=rejected | highway~'x-.*' {delete highway; delete junction}
# Remove highway tag from ways which are not suitable for routing
-highway=traffic_signals | highway=junction | highway=island | highway=centre_line | highway=traffic_island | highway=stopline
+highway=traffic_signals | highway=junction | highway=island | highway=centre_line | highway=traffic_island | highway=stopline |
+highway=bus_stop | highway=bus_guideway | highway=emergency_access_point | highway=ohm:military:Trench
{delete highway}
+highway=via_ferrata {delete highway} # this shouldn't show as routable on default map: path only for specialists
highway=piste | highway=ski {delete highway}
highway=no | highway=none {delete highway}
@@ -89,7 +91,7 @@
(highway=bridleway | highway=path | highway=track) & mkgmap:unpaved!=0 {add mkgmap:unpaved=1}
(highway=unsurfaced | highway=via_ferrata) {set mkgmap:unpaved=1}
-highway=* & mkgmap:unpaved!=1 & smoothness~'.*(bad|horrible|impassable)' {add mkgmap:road-speed='-2'}
+highway=* & mkgmap:unpaved!=1 &
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Ticker Berkin 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 +, 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-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin < rwb-mkg...@jagit.co.uk<mailto:rwb-mkg...@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 +, 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 +, 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 rendere
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 +, 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-boun...@lists.mkgmap.org.uk > > > im Auftrag von Ticker Berkin < > > rwb-mkg...@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 +, 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 +, Ticker Berkin ha > > > > > scritto: > > > > > > Hi Lorenzo > > > > > > > > > > > > I know that the OSM
Re: [mkgmap-dev] default style improvements
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 +, 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-boun...@lists.mkgmap.org.uk > > im Auftrag von Ticker Berkin < > rwb-mkg...@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 +, 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 +, 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 > > > > > > > > > >
Re: [mkgmap-dev] default style improvements
Hi On Sun, 2019-01-06 at 08:50 -0500, Greg Troxel wrote: > Bernhard Hiller 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Ticker Berkin 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 +, 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 +, 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 > > > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 +, 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 +, 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 > > > > > > 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
Re: [mkgmap-dev] default style improvements
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 +, 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 +, 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 > > > > 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
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Ticker Berkin 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 +, 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 im Auftrag > von Lorenzo Mastrogiacomi > 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 +, 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 > 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
Re: [mkgmap-dev] default style improvements
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 +, 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 > 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
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 +, 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 im Auftrag > von Lorenzo Mastrogiacomi > 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 +, 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 > 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
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Lorenzo Mastrogiacomi 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 +, 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 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
Re: [mkgmap-dev] default style improvements
Il giorno dom, 06/01/2019 alle 12.45 +, 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 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Hi Gerd see embedded answers Regards Ticker On Sun, 2019-01-06 at 09:11 +, 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Bernhard Hiller 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.) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Ticker Berkin 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. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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 +, 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Ticker
Berkin
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 +, 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
Re: [mkgmap-dev] default style improvements
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 +, Gerd Petermann wrote:
Hi Ticker,
yes please, my understanding was that the patch was not accepted.
Gerd
Von: mkgmap-dev im Auftrag
von Ticker Berkin
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 +, 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 +, 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
Re: [mkgmap-dev] default style improvements
Il giorno sab, 05/01/2019 alle 17.18 +, 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
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > yes please, my understanding was that the patch was not accepted.
> >
> > Gerd
> >
> > ________________
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Donnerstag, 3. Januar 2019 11:59
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] default style improvements
&g
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Ticker
Berkin
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 +, Gerd Petermann wrote:
> Hi Ticker,
>
> yes please, my understanding was that the patch was not accepted.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> 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 +, 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 +, 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
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 +, Gerd Petermann wrote:
> Hi Ticker,
>
> yes please, my understanding was that the patch was not accepted.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> 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 +, 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 +, 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-devIndex: resources/styles/default/inc/access_country
===
--- resources/styles/default/inc/access_country (revision 4258)
+++ resources/styles/default/inc/access_country (working copy)
@@ -4,19 +4,26 @@
# Belgium (BEL)
-highway=trunk & mkgmap:country=BEL { add bicycle=no; add foot=no }
-highway=cycleway & mkgmap:country=BEL { add foot=yes }
-highway=bridleway & mkgmap:country=BEL { add foot=yes }
+highway=trunk & mkgmap:country=BEL {add bicycle=no; add foot=no}
+highway=cycleway & mkgmap:country=BEL {add foot=yes}
+highway=bridleway & mkgmap:country=BEL {add foot=yes}
# The Netherlands (NLD)
-highway=trunk & mkgmap:country=NLD { add bicycle=no; add foot=no }
-highway=cycleway & mkgmap:country=NLD { add foot=yes }
-highway=bridleway & mkgmap:country=NLD { add foot=yes }
+highway=trunk & mkgmap:country=NLD {add bicycle=no; add foot=no}
+highway=cycleway & mkgmap:country=NLD {add foot=yes}
+highway=bridleway & mkgmap:country=NLD {add foot=yes}
# Spain (ESP)
-highway=trunk & mkgmap:country=ESP { add bicycle=yes; add foot=yes }
Re: [mkgmap-dev] default style improvements
Hi Ticker,
yes please, my understanding was that the patch was not accepted.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
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 +, 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 +, 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
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 +, 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 +, 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
Re: [mkgmap-dev] default style improvements
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 +, 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 im Auftrag
> von Ticker Berkin
> 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
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Ticker
Berkin
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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
Index: resources/styles/default/inc/access_country
===
--- resources/styles/default/inc/access_country (revision 4258)
+++ resources/styles/default/inc/access_country (working copy)
@@ -4,19 +4,26 @@
# Belgium (BEL)
-highway=trunk & mkgmap:country=BEL { add bicycle=no; add foot=no }
-highway=cycleway & mkgmap:country=BEL { add foot=yes }
-highway=bridleway & mkgmap:country=BEL { add foot=yes }
+highway=trunk & mkgmap:country=BEL {add bicycle=no; add foot=no}
+highway=cycleway & mkgmap:country=BEL {add foot=yes}
+highway=bridleway & mkgmap:country=BEL {add foot=yes}
# The Netherlands (NLD)
-highway=trunk & mkgmap:country=NLD { add bicycle=no; add foot=no }
-highway=cycleway & mkgmap:country=NLD { add foot=yes }
-highway=bridleway & mkgmap:country=NLD { add foot=yes }
+highway=trunk & mkgmap:country=NLD {add bicycle=no; add foot=no}
+highway=cycleway & mkgmap:country=NLD {add foot=yes}
+highway=bridleway & mkgmap:country=NLD {add foot=yes}
# Spain (ESP)
-highway=trunk & mkgmap:country=ESP { add bicycle=yes; add foot=yes }
-highway=bridleway & mkgmap:country=ESP { add bicycle=yes; add foot=yes }
+highway=trunk & mkgmap:country=ESP {add bicycle=yes; add foot=yes}
+highway=bridleway & mkgmap:country=ESP {add bicycle=yes; add foot=yes}
+# United Kingdom (GBR)
+highway=cycleway & mkgmap:country=GBR {add foot=yes}
+highway=bridleway & mkgmap:country=GBR {
+add bicycle=yes;
+add foot=yes;
+add motor_vehicle=private
+}
Index: resources/styles/default/lines
===
--- resources/styles/default/lines (revision 4258)
+++ resources/styles/default/lines (working copy)
@@ -10,9 +10,12 @@
addr:housenumber=* {set mkgmap:execute_finalize_rules=true}
-aeroway=runway & highway!=* & is_closed()=false {name '${ref}'} [0x27 resolution 20]
-(aeroway=taxiway | aeroway=taxilane) & highway!=* & is_closed()=false {name '${ref}'} [0x27 resolution 24]
+abandoned=yes {deletealltags} # old, depreciated, ambiguous, method of handling abandoned
+# do these as lines regardless of being closed unless explicity marked as area. continue in case also a highway
+aeroway=runway & area!=yes {name '${ref}'} [0x27 resolution 20 continue]
+(aeroway=taxiway | aeroway=taxilane) & area!=yes {name '${ref}'} [0x27 resolution 24 continue]
+
# Assign the street name for house number search
highway=* & name=* {set mkgmap:street='${name}'}
@@ -19,22 +22,22 @@
# Mark highways with the toll flag
highway=* & (toll=yes | toll=true) {set mkgmap:toll=yes}
-# mark multipolygons as area
-highway=* & mkgmap:mp_created=true {add area=yes}
-
# Hide proposed ways
highway=proposed | highway=proposal | highway=planned | highway~'.*proposed.*' {delete highway; delete junction}
# Hide removed ways
-highway=razed | highway=dismantled {deletealltags}
+highway=razed | highway=dismantled | highway=disused | highway=demolished {delete highway; delete junction}
# Hide abandoned ways. Abandoned highways have some evidence of their former existence but are no longer used. These
# abandoned highways could be useful in topographical maps.
# https://wiki.openstreetmap.org/wiki/Key:abandoned:
-(abandoned:highway=* & highway!=*) | highway=abandoned {deletealltags}
+(abandoned:highway=* & (highway!=* | highway=yes)) | highway=abandoned {delete highway; delete junction}
# Hide other non-existent ways
highway=unbuilt | highway=neverbuilt | highway=rejected | highway~'x-.*' {delete highway; delete junction}
# Remove highway tag from ways which are not suitable for routing
-highway=traffic_signals | highway=junction | highway=island | highway=centre_line | highway=traffic_island | highway=stopline
+highway=traffic_signals | highway=junction | highway=island | highway=centre_line | highway=traffic_island | highway=stopline |
+highway=bus_stop | highway=bus_guideway | highway=escape | highway=emergency_bay | highway=emergency_access_point |
+highway=ohm:military:Trench
{delete highway}
+highway=via_ferrata {delete highway} # this shouldn't show as routable on default map: path only for specialists
highway=piste | highway=ski {delete highway}
highway=no | highway=none {delete highway}
@@ -89,7 +92,7 @@
(highway=bridleway | highway=path | highway=track) & mkgmap:unpaved!=0 {add mkgmap:unpaved=1}
(highway=unsurfaced | highway=via_ferrata) {set mkgmap:unpaved=1}
-highway=* & mkgmap:unpaved!=1 & smoothness~'.*(bad|horrible|impassable)' {add mkgmap:road-speed='-2'}
+highway=* & mkgmap:unpaved!=1 & smoothness~'.*(bad|horrible|impassable)' {add mkgmap:road-speed=-2}
# Good ways without relation
highway=* & mkgmap:fast_road!=* & (int_ref=* | network=e-road | network=AH
Re: [mkgmap-dev] default style improvements
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. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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 +, 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Ticker
Berkin
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, 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 im Auftrag
> > von Ticker Berkin
> > 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 +, 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 im
> > > Auftrag
> > > von Ticker Berkin
> > > 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:
> >
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, 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 im Auftrag
> > von Ticker Berkin
> > 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 +, 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 im
> > > Auftrag
> > > von Ticker Berkin
> > > 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
> > >
> > &g
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Ticker
Berkin
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, 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 im Auftrag
> > von Ticker Berkin
> > 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 i
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, 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 im Auftrag
> > von Ticker Berkin
> > 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 T
Re: [mkgmap-dev] default style improvements
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 +, 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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 +, Joris Bo wrote: > Hello > > I updated a typ-file up to these changes of Ticker > Kind regards, Joris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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/984b5ce9c8a9e9aacc61d0cd022e9768006408c9 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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 +, 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-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin
> 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 +, 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-boun...@lists.mkgmap.org.uk> im Auftragvon Ticker Berkin
> > 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 m
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Ticker
Berkin
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 +, 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 im Auftrag
> von Ticker Berkin
> 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
>
> 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 d
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 +, 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 im Auftrag
> von Ticker Berkin
> 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
>
> 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
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Ticker
Berkin
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
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
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
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
Index: resources/styles/default/inc/access_country
===
--- resources/styles/default/inc/access_country (revision 4258)
+++ resources/styles/default/inc/access_country (working copy)
@@ -4,19 +4,26 @@
# Belgium (BEL)
-highway=trunk & mkgmap:country=BEL { add bicycle=no; add foot=no }
-highway=cycleway & mkgmap:country=BEL { add foot=yes }
-highway=bridleway & mkgmap:country=BEL { add foot=yes }
+highway=trunk & mkgmap:country=BEL {add bicycle=no; add foot=no}
+highway=cycleway & mkgmap:country=BEL {add foot=yes}
+highway=bridleway & mkgmap:country=BEL {add foot=yes}
# The Netherlands (NLD)
-highway=trunk & mkgmap:country=NLD { add bicycle=no; add foot=no }
-highway=cycleway & mkgmap:country=NLD { add foot=yes }
-highway=bridleway & mkgmap:country=NLD { add foot=yes }
+highway=trunk & mkgmap:country=NLD {add bicycle=no; add foot=no}
+highway=cycleway & mkgmap:country=NLD {add foot=yes}
+highway=bridleway & mkgmap:country=NLD {add foot=yes}
# Spain (ESP)
-highway=trunk & mkgmap:country=ESP { add bicycle=yes; add foot=yes }
-highway=bridleway & mkgmap:country=ESP { add bicycle=yes; add foot=yes }
+highway=trunk & mkgmap:country=ESP {add bicycle=yes; add foot=yes}
+highway=bridleway & mkgmap:country=ESP {add bicycle=yes; add foot=yes}
+# United Kingdom (GBR)
+highway=cycleway & mkgmap:country=GBR {add foot=yes}
+highway=bridleway & mkgmap:country=GBR {
+add bicycle=yes;
+add foot=yes;
+add motor_vehicle=private
+}
Index: resources/styles/default/lines
===
--- resources/styles/default/lines (revision 4258)
+++ resources/styles/default/lines (working copy)
@@ -10,9 +10,12 @@
addr:housenumber=* {set mkgmap:execute_finalize_rules=true}
-aeroway=runway & highway!=* & is_closed()=false {name '${ref}'} [0x27 resolution 20]
-(aeroway=taxiway | aeroway=taxilane) & highway!=* & is_closed()=false {name '${ref}'} [0x27 resolution 24]
+abandoned=yes {deletealltags} # old, depreciated, ambiguous, method of handling abandoned
+# do these as lines regardless of being closed unless explicity marked as area. continue in case also a highway
+aeroway=runway & area!=yes {name '${ref}'} [0x27 resolution 20 continue]
+(aeroway=taxiway | aeroway=taxilane) & area!=yes {name
Re: [mkgmap-dev] default style improvements
Hi Ticker,
yes, your are right. I was a bit distracted because of some work for JOSM...
Committed now .
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
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 +, 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 +, 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
Re: [mkgmap-dev] default style improvements
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
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
Index: resources/styles/default/lines
===
--- resources/styles/default/lines (revision 4255)
+++ resources/styles/default/lines (working copy)
@@ -17,21 +17,21 @@
highway=* & name=* {set mkgmap:street='${name}'}
# Mark highways with the toll flag
-highway=* & (toll=yes|toll=true) {set mkgmap:toll=yes}
+highway=* & (toll=yes | toll=true) {set mkgmap:toll=yes}
# mark multipolygons as area
highway=* & mkgmap:mp_created=true {add area=yes}
# Hide proposed ways
-(highway=proposed | highway=proposal | highway=planned | highway~'.*proposed.*') {delete highway; delete junction}
+highway=proposed | highway=proposal | highway=planned | highway~'.*proposed.*' {delete highway; delete junction}
# Hide removed ways
-(highway=razed | highway=dismantled) {deletealltags}
+highway=razed | highway=dismantled {deletealltags}
# Hide abandoned ways. Abandoned highways have some evidence of their former existence but are no longer used. These
# abandoned highways could be useful in topographical maps.
# https://wiki.openstreetmap.org/wiki/Key:abandoned:
-((abandoned:highway=* & highway!=*) | highway=abandoned) {deletealltags}
+(abandoned:highway=* & highway!=*) | highway=abandoned {deletealltags}
# Hide other non-existent ways
-(highway=unbuilt | highway=neverbuilt | highway=rejected | highway~'x-.*') {delete highway; delete junction}
+highway=unbuilt | highway=neverbuilt | highway=rejected | highway~'x-.*' {delete highway; delete junction}
# Remove highway tag from ways which are not suitable for routing
highway=traffic_signals | highway=junction | highway=island | highway=centre_line | highway=traffic_island | highway=stopline
{delete highway}
@@ -41,7 +41,7 @@
# Hide unaccessible tunnels
highway=* & tunnel=yes & (access=private | access=no) & foot!=* & bicycle!=* {delete highway; delete junction}
# Disable dead-end-checks for unaccessible oneways
-highway=* & oneway=yes & (access=private|access=no) {add mkgmap:dead-end-check=false}
+highway=* & oneway=yes & (access=private | access=no) {add mkgmap:dead-end-check=false}
# Validation-like checks (uncomment to enable)
#highway=motorway_link & oneway!=yes & oneway!=no {echo "motorway_link lacks oneway"}
highway=motorway | highway=motorway_link {add oneway=yes; add mkgmap:numbers=false}
@@ -51,21 +51,20 @@
# motorway_link, trunk_link, primary_link, secondary_link, tertiary_link
# build destination hint
mkgmap:dest_hint=* {
-set dest_hint='${destination:ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' |
- '${ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' |
- '${mkgmap:dest_hint|subst:;=> |subst:/=> }';
+set tmp:dest_hint='${destination:ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' |
+ '${ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' |
+ '${mkgmap:dest_hint|subst:;=> |subst:/=> }';
}
# build exit hint
mkgmap:exit_hint=true {
-set exit_hint='Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_name}' |
- 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_exit_to}' |
- 'Exit ${mkgmap:exit_hint_exit_to}' |
- 'Exit ${mkgmap:exit_hint_name}' |
- 'Exit ${mkgmap:exit_hint_ref}';
+set tmp:exit_hint='Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_name}' |
+ 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_exit_to}' |
+ 'Exit ${mkgmap:exit_hint_exit_to}' |
+ 'Exit ${mkgmap:exit_hint_name}' |
+ 'Exit ${mkgmap:exit_hint_ref}';
}
-
# use destination hint and/or exit hint to build name
-(mkgmap:exit_hint=true | mkgmap:dest_hint=*) {name '${exit_hint} ${dest_hint}' | '${dest_hint}' | '${exit_hint}'}
+mkgmap:exit_hint=true |
Re: [mkgmap-dev] default style improvements
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 Namens Ticker Berkin
Verzonden: dinsdag 13 november 2018 18:26
Aan: Development list for mkgmap
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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
Re: [mkgmap-dev] default style improvements
Hi Ticker,
OK, got your point. If no one complains I'll commit that patch on thursday.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
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 +, 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 +, 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
Re: [mkgmap-dev] default style improvements
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 im Auftrag von Ticker
Berkin
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 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
