mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side? For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path. -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, sounds reasonable. I'll have a look at the code, it is already quite complex because of the --report-dead-ends option. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 2. September 2017 15:41:50 An: Development list for mkgmap Betreff: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side? For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path. -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
thanks - if it's not too complicated it would be handy to remove "clutter" On 3 September 2017 at 09:42, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:
Hi Felix,
sounds reasonable. I'll have a look at the code, it is already quite complex because of the --report-dead-ends option.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 2. September 2017 15:41:50 An: Development list for mkgmap Betreff: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side?
For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path.
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, do you have a suggestion for the tag value? Up to now we have mkgmap:set_unconnected_type=none or mkgmap:set_unconnected_type=0x??? Maybe we use a colon or semicolon to list two values ? mkgmap:set_unconnected_type=0x07:0x10007 1st value is used if road leads to other way, 2nd if not Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 3. September 2017 18:51:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only thanks - if it's not too complicated it would be handy to remove "clutter" On 3 September 2017 at 09:42, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix, sounds reasonable. I'll have a look at the code, it is already quite complex because of the --report-dead-ends option. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Samstag, 2. September 2017 15:41:50 An: Development list for mkgmap Betreff: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side? For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path. -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
either that - or create mkgmap:set_unconnected2=0x?? both is fine. (and I think semicolon is better than colon regarding other OSM nomination). Felix On 4 September 2017 at 09:24, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:
Hi Felix,
do you have a suggestion for the tag value? Up to now we have mkgmap:set_unconnected_type=none or mkgmap:set_unconnected_type=0x???
Maybe we use a colon or semicolon to list two values ? mkgmap:set_unconnected_type=0x07:0x10007 1st value is used if road leads to other way, 2nd if not
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 3. September 2017 18:51:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
thanks - if it's not too complicated it would be handy to remove "clutter"
On 3 September 2017 at 09:42, Gerd Petermann <GPetermann_muenchen@hotmail. com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix,
sounds reasonable. I'll have a look at the code, it is already quite complex because of the --report-dead-ends option.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap- dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Samstag, 2. September 2017 15:41:50 An: Development list for mkgmap Betreff: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side?
For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path.
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, attached is a patch that implements a new special tag mkgmap:set_semi_connected which works like mkgmap:set_unconnected_type when a road is only connected to other roads in a single node. Please check if it does what you want. I hope it still works as before for the --report-dead-ends option and the mkgmap:set_unconnected tag. If others also want to test: A binary is here: http://files.mkgmap.org.uk/download/357/mkgmap.jar I also thought about other names for the tag, e.g. mkgmap:set_deadend_type Maybe better ? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 4. September 2017 10:30:03 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only either that - or create mkgmap:set_unconnected2=0x?? both is fine. (and I think semicolon is better than colon regarding other OSM nomination). Felix On 4 September 2017 at 09:24, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix, do you have a suggestion for the tag value? Up to now we have mkgmap:set_unconnected_type=none or mkgmap:set_unconnected_type=0x??? Maybe we use a colon or semicolon to list two values ? mkgmap:set_unconnected_type=0x07:0x10007 1st value is used if road leads to other way, 2nd if not Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Sonntag, 3. September 2017 18:51:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only thanks - if it's not too complicated it would be handy to remove "clutter" On 3 September 2017 at 09:42, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>> wrote: Hi Felix, sounds reasonable. I'll have a look at the code, it is already quite complex because of the --report-dead-ends option. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Samstag, 2. September 2017 15:41:50 An: Development list for mkgmap Betreff: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side? For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path. -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
I will properly test it in around 14 days - I cannot access my computer to compile mkgmap right now. I will try to give it a quick test in the coming days - thanks. On 5 September 2017 at 07:53, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:
Hi Felix,
attached is a patch that implements a new special tag mkgmap:set_semi_connected which works like mkgmap:set_unconnected_type when a road is only connected to other roads in a single node. Please check if it does what you want. I hope it still works as before for the --report-dead-ends option and the mkgmap:set_unconnected tag.
If others also want to test: A binary is here: http://files.mkgmap.org.uk/download/357/mkgmap.jar
I also thought about other names for the tag, e.g. mkgmap:set_deadend_type Maybe better ?
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 4. September 2017 10:30:03 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
either that - or create mkgmap:set_unconnected2=0x?? both is fine. (and I think semicolon is better than colon regarding other OSM nomination).
Felix
On 4 September 2017 at 09:24, Gerd Petermann <GPetermann_muenchen@hotmail. com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix,
do you have a suggestion for the tag value? Up to now we have mkgmap:set_unconnected_type=none or mkgmap:set_unconnected_type=0x???
Maybe we use a colon or semicolon to list two values ? mkgmap:set_unconnected_type=0x07:0x10007 1st value is used if road leads to other way, 2nd if not
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap- dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Sonntag, 3. September 2017 18:51:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
thanks - if it's not too complicated it would be handy to remove "clutter"
On 3 September 2017 at 09:42, Gerd Petermann <GPetermann_muenchen@hotmail. com<mailto:GPetermann_muenchen@hotmail.com><mailto:G Petermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
sounds reasonable. I'll have a look at the code, it is already quite complex because of the --report-dead-ends option.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap- dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@ lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> Gesendet: Samstag, 2. September 2017 15:41:50 An: Development list for mkgmap Betreff: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side?
For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path.
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists. mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
So here are my findings - only use case c) works (which means the same behaviour as before - so the patch does not break anything as far as I found out while playing around). in lines file: a) ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway & (mkgmap:set_semi_connected_type=none | mkgmap:set_unconnected_type=none) {delete highway; delete service; delete access; delete name;} highway=path & service=driveway [0x13 road_class=0 road_speed=0 resolution 24 ] Will end up with all service=driveway & highway=path lines deleted, no only those that are unconnected or semi_connected. b) ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} # service=driveway & (mkgmap:set_semi_connected_type=none | mkgmap:set_unconnected_type=none) {delete highway; delete service; delete access; delete name;} highway=path & service=driveway [0x13 road_class=0 road_speed=0 resolution 24 ] Will not do anything. c) highway=path & service=driveway {set mkgmap:set_unconnected_type=none; set mkgmap:set_unconnected_type=none } [0x01 road_class=0 road_speed=0 resolution 24 ] works. It would be great if either a) or b) approach could be taken also. Or if would be possible to simply write a line like: ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=delete; set mkgmap:set_unconnected_type=delete} So you could delete those lines without placing many many of set mkgmap:set_semi_connected_type=none in each line in your styles file where you need it. Another thing about the type which I consider a bit buggy is the following mkgmap:set_semi_connected_type=0x27 or mkgmap:set_unconnected_type=0x1f will throw the error no routable type should be used, while AFAIK the only routable types are 0x01-0x16 plus with special consideration 0x1a-0x1c. 0x2? is never routable. So it should not be treated like none. This is not really important though. Felix On 5 September 2017 at 10:56, Felix Hartmann <extremecarver@gmail.com> wrote:
I will properly test it in around 14 days - I cannot access my computer to compile mkgmap right now. I will try to give it a quick test in the coming days - thanks.
On 5 September 2017 at 07:53, Gerd Petermann <GPetermann_muenchen@hotmail. com> wrote:
Hi Felix,
attached is a patch that implements a new special tag mkgmap:set_semi_connected which works like mkgmap:set_unconnected_type when a road is only connected to other roads in a single node. Please check if it does what you want. I hope it still works as before for the --report-dead-ends option and the mkgmap:set_unconnected tag.
If others also want to test: A binary is here: http://files.mkgmap.org.uk/download/357/mkgmap.jar
I also thought about other names for the tag, e.g. mkgmap:set_deadend_type Maybe better ?
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 4. September 2017 10:30:03 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
either that - or create mkgmap:set_unconnected2=0x?? both is fine. (and I think semicolon is better than colon regarding other OSM nomination).
Felix
On 4 September 2017 at 09:24, Gerd Petermann < GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix,
do you have a suggestion for the tag value? Up to now we have mkgmap:set_unconnected_type=none or mkgmap:set_unconnected_type=0x???
Maybe we use a colon or semicolon to list two values ? mkgmap:set_unconnected_type=0x07:0x10007 1st value is used if road leads to other way, 2nd if not
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Sonntag, 3. September 2017 18:51:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
thanks - if it's not too complicated it would be handy to remove "clutter"
On 3 September 2017 at 09:42, Gerd Petermann < GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com
<mailto:GPetermann_muenchen@hotmail.com<mailto:G Petermann_muenchen@hotmail.com>>> wrote: Hi Felix,
sounds reasonable. I'll have a look at the code, it is already quite complex because of the --report-dead-ends option.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@list s.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> Gesendet: Samstag, 2. September 2017 15:41:50 An: Development list for mkgmap Betreff: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side?
For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path.
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkg map-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, it seems you do not yet understand how the special tag works. Thet ag is evaluated after all elements were processed by the style rules. It is not possible to do this earlier because mkgmap cannot know which ways will end up as routable lines before style processing is done. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 14:49:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only So here are my findings - only use case c) works (which means the same behaviour as before - so the patch does not break anything as far as I found out while playing around). in lines file: a) ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway & (mkgmap:set_semi_connected_type=none | mkgmap:set_unconnected_type=none) {delete highway; delete service; delete access; delete name;} highway=path & service=driveway [0x13 road_class=0 road_speed=0 resolution 24 ] Will end up with all service=driveway & highway=path lines deleted, no only those that are unconnected or semi_connected. b) ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} # service=driveway & (mkgmap:set_semi_connected_type=none | mkgmap:set_unconnected_type=none) {delete highway; delete service; delete access; delete name;} highway=path & service=driveway [0x13 road_class=0 road_speed=0 resolution 24 ] Will not do anything. c) highway=path & service=driveway {set mkgmap:set_unconnected_type=none; set mkgmap:set_unconnected_type=none } [0x01 road_class=0 road_speed=0 resolution 24 ] works. It would be great if either a) or b) approach could be taken also. Or if would be possible to simply write a line like: ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=delete; set mkgmap:set_unconnected_type=delete} So you could delete those lines without placing many many of set mkgmap:set_semi_connected_type=none in each line in your styles file where you need it. Another thing about the type which I consider a bit buggy is the following mkgmap:set_semi_connected_type=0x27 or mkgmap:set_unconnected_type=0x1f will throw the error no routable type should be used, while AFAIK the only routable types are 0x01-0x16 plus with special consideration 0x1a-0x1c. 0x2? is never routable. So it should not be treated like none. This is not really important though. Felix On 5 September 2017 at 10:56, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: I will properly test it in around 14 days - I cannot access my computer to compile mkgmap right now. I will try to give it a quick test in the coming days - thanks. On 5 September 2017 at 07:53, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix, attached is a patch that implements a new special tag mkgmap:set_semi_connected which works like mkgmap:set_unconnected_type when a road is only connected to other roads in a single node. Please check if it does what you want. I hope it still works as before for the --report-dead-ends option and the mkgmap:set_unconnected tag. If others also want to test: A binary is here: http://files.mkgmap.org.uk/download/357/mkgmap.jar I also thought about other names for the tag, e.g. mkgmap:set_deadend_type Maybe better ? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 4. September 2017 10:30:03 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only either that - or create mkgmap:set_unconnected2=0x?? both is fine. (and I think semicolon is better than colon regarding other OSM nomination). Felix On 4 September 2017 at 09:24, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>> wrote: Hi Felix, do you have a suggestion for the tag value? Up to now we have mkgmap:set_unconnected_type=none or mkgmap:set_unconnected_type=0x??? Maybe we use a colon or semicolon to list two values ? mkgmap:set_unconnected_type=0x07:0x10007 1st value is used if road leads to other way, 2nd if not Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Sonntag, 3. September 2017 18:51:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only thanks - if it's not too complicated it would be handy to remove "clutter" On 3 September 2017 at 09:42, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>>> wrote: Hi Felix, sounds reasonable. I'll have a look at the code, it is already quite complex because of the --report-dead-ends option. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Samstag, 2. September 2017 15:41:50 An: Development list for mkgmap Betreff: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side? For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path. -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
well maybe not fully - but why is it then not possible to use it as given in example b). First define a condition and then make sure that all ways that fullfill it won't be routable. I mean b) and c) are very similar in notation - why can not both notations work? a) won't work if it is evaluated last - I get that now. c) is much more complicated in the lines style-file compared to b). On 17 September 2017 at 16:42, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:
Hi Felix,
it seems you do not yet understand how the special tag works. Thet ag is evaluated after all elements were processed by the style rules. It is not possible to do this earlier because mkgmap cannot know which ways will end up as routable lines before style processing is done.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 14:49:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
So here are my findings - only use case c) works (which means the same behaviour as before - so the patch does not break anything as far as I found out while playing around).
in lines file: a) ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway & (mkgmap:set_semi_connected_type=none | mkgmap:set_unconnected_type=none) {delete highway; delete service; delete access; delete name;} highway=path & service=driveway [0x13 road_class=0 road_speed=0 resolution 24 ]
Will end up with all service=driveway & highway=path lines deleted, no only those that are unconnected or semi_connected.
b) ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} # service=driveway & (mkgmap:set_semi_connected_type=none | mkgmap:set_unconnected_type=none) {delete highway; delete service; delete access; delete name;} highway=path & service=driveway [0x13 road_class=0 road_speed=0 resolution 24 ]
Will not do anything.
c) highway=path & service=driveway {set mkgmap:set_unconnected_type=none; set mkgmap:set_unconnected_type=none } [0x01 road_class=0 road_speed=0 resolution 24 ] works.
It would be great if either a) or b) approach could be taken also. Or if would be possible to simply write a line like: ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=delete; set mkgmap:set_unconnected_type=delete} So you could delete those lines without placing many many of set mkgmap:set_semi_connected_type=none in each line in your styles file where you need it.
Another thing about the type which I consider a bit buggy is the following mkgmap:set_semi_connected_type=0x27 or mkgmap:set_unconnected_type=0x1f will throw the error no routable type should be used, while AFAIK the only routable types are 0x01-0x16 plus with special consideration 0x1a-0x1c. 0x2? is never routable. So it should not be treated like none. This is not really important though. Felix
On 5 September 2017 at 10:56, Felix Hartmann <extremecarver@gmail.com< mailto:extremecarver@gmail.com>> wrote: I will properly test it in around 14 days - I cannot access my computer to compile mkgmap right now. I will try to give it a quick test in the coming days - thanks.
On 5 September 2017 at 07:53, Gerd Petermann <GPetermann_muenchen@hotmail. com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix,
attached is a patch that implements a new special tag mkgmap:set_semi_connected which works like mkgmap:set_unconnected_type when a road is only connected to other roads in a single node. Please check if it does what you want. I hope it still works as before for the --report-dead-ends option and the mkgmap:set_unconnected tag.
If others also want to test: A binary is here: http://files.mkgmap.org.uk/download/357/mkgmap.jar
I also thought about other names for the tag, e.g. mkgmap:set_deadend_type Maybe better ?
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap- dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 4. September 2017 10:30:03 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
either that - or create mkgmap:set_unconnected2=0x?? both is fine. (and I think semicolon is better than colon regarding other OSM nomination).
Felix
On 4 September 2017 at 09:24, Gerd Petermann <GPetermann_muenchen@hotmail. com<mailto:GPetermann_muenchen@hotmail.com><mailto:G Petermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
do you have a suggestion for the tag value? Up to now we have mkgmap:set_unconnected_type=none or mkgmap:set_unconnected_type=0x???
Maybe we use a colon or semicolon to list two values ? mkgmap:set_unconnected_type=0x07:0x10007 1st value is used if road leads to other way, 2nd if not
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap- dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@ lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> Gesendet: Sonntag, 3. September 2017 18:51:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
thanks - if it's not too complicated it would be handy to remove "clutter"
On 3 September 2017 at 09:42, Gerd Petermann <GPetermann_muenchen@hotmail. com<mailto:GPetermann_muenchen@hotmail.com><mailto:G Petermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com
<mailto:GPetermann_muenchen@hotmail.com<mailto: GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com <mailto:GPetermann_muenchen@hotmail.com>>>> wrote: Hi Felix,
sounds reasonable. I'll have a look at the code, it is already quite complex because of the --report-dead-ends option.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap- dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@ lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk
<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mk gmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev- bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremec arver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Samstag, 2. September 2017 15:41:50 An: Development list for mkgmap Betreff: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side?
For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path.
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists. mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk< mailto:mkgmap-dev@lists.mkgmap.org.uk>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists. mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
_______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
I agree, b) should work as well. Are you sure that there is a road with the rare combination of highway=path & service=driveway ? I would say that it is an ill-taged way. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 17:02:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only well maybe not fully - but why is it then not possible to use it as given in example b). First define a condition and then make sure that all ways that fullfill it won't be routable. I mean b) and c) are very similar in notation - why can not both notations work? a) won't work if it is evaluated last - I get that now. c) is much more complicated in the lines style-file compared to b). On 17 September 2017 at 16:42, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix, it seems you do not yet understand how the special tag works. Thet ag is evaluated after all elements were processed by the style rules. It is not possible to do this earlier because mkgmap cannot know which ways will end up as routable lines before style processing is done. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Sonntag, 17. September 2017 14:49:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only So here are my findings - only use case c) works (which means the same behaviour as before - so the patch does not break anything as far as I found out while playing around). in lines file: a) ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway & (mkgmap:set_semi_connected_type=none | mkgmap:set_unconnected_type=none) {delete highway; delete service; delete access; delete name;} highway=path & service=driveway [0x13 road_class=0 road_speed=0 resolution 24 ] Will end up with all service=driveway & highway=path lines deleted, no only those that are unconnected or semi_connected. b) ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} # service=driveway & (mkgmap:set_semi_connected_type=none | mkgmap:set_unconnected_type=none) {delete highway; delete service; delete access; delete name;} highway=path & service=driveway [0x13 road_class=0 road_speed=0 resolution 24 ] Will not do anything. c) highway=path & service=driveway {set mkgmap:set_unconnected_type=none; set mkgmap:set_unconnected_type=none } [0x01 road_class=0 road_speed=0 resolution 24 ] works. It would be great if either a) or b) approach could be taken also. Or if would be possible to simply write a line like: ( highway=service | highway=track | highway=path | highway=footway ) & service=driveway {set mkgmap:set_semi_connected_type=delete; set mkgmap:set_unconnected_type=delete} So you could delete those lines without placing many many of set mkgmap:set_semi_connected_type=none in each line in your styles file where you need it. Another thing about the type which I consider a bit buggy is the following mkgmap:set_semi_connected_type=0x27 or mkgmap:set_unconnected_type=0x1f will throw the error no routable type should be used, while AFAIK the only routable types are 0x01-0x16 plus with special consideration 0x1a-0x1c. 0x2? is never routable. So it should not be treated like none. This is not really important though. Felix On 5 September 2017 at 10:56, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: I will properly test it in around 14 days - I cannot access my computer to compile mkgmap right now. I will try to give it a quick test in the coming days - thanks. On 5 September 2017 at 07:53, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>> wrote: Hi Felix, attached is a patch that implements a new special tag mkgmap:set_semi_connected which works like mkgmap:set_unconnected_type when a road is only connected to other roads in a single node. Please check if it does what you want. I hope it still works as before for the --report-dead-ends option and the mkgmap:set_unconnected tag. If others also want to test: A binary is here: http://files.mkgmap.org.uk/download/357/mkgmap.jar I also thought about other names for the tag, e.g. mkgmap:set_deadend_type Maybe better ? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Montag, 4. September 2017 10:30:03 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only either that - or create mkgmap:set_unconnected2=0x?? both is fine. (and I think semicolon is better than colon regarding other OSM nomination). Felix On 4 September 2017 at 09:24, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>>> wrote: Hi Felix, do you have a suggestion for the tag value? Up to now we have mkgmap:set_unconnected_type=none or mkgmap:set_unconnected_type=0x??? Maybe we use a colon or semicolon to list two values ? mkgmap:set_unconnected_type=0x07:0x10007 1st value is used if road leads to other way, 2nd if not Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Sonntag, 3. September 2017 18:51:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only thanks - if it's not too complicated it would be handy to remove "clutter" On 3 September 2017 at 09:42, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>>>> wrote: Hi Felix, sounds reasonable. I'll have a look at the code, it is already quite complex because of the --report-dead-ends option. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Samstag, 2. September 2017 15:41:50 An: Development list for mkgmap Betreff: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Would it be possible to have the mkgmap:set_unconnected_type=... differentiate between conncected on both sides for lines and only connected on one side? For example I would like to delete all service=driveway shorther than 100m length if they are connected only on one side to another routable line - if they are in between I would like to keep them. (in some countries - e.g. Switzerland and France) often highway=service&service=driveway leads not only to a house but also connects e.g. to a highway=track or highway=path. -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Gerd In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath. r Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little). do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too. Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not). On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk> wrote:
Hi Gerd
In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath.
r
Nick
-- 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, did not try it, but b) should already work. The tag is different to any other tag, it just triggers special treatment after style processing. Do you have an example file that shows that it doesn't work? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 18:14:46 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little). do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too. Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not). On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk<mailto:osm@pinns.co.uk>> wrote: Hi Gerd In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath. r Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private. On 17 September 2017 at 18:14, Felix Hartmann <extremecarver@gmail.com> wrote:
I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little).
do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too.
Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not).
On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk> wrote:
Hi Gerd
In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath.
r
Nick
-- 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours. also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible. On 17 September 2017 at 18:26, Felix Hartmann <extremecarver@gmail.com> wrote:
b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm
oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private.
On 17 September 2017 at 18:14, Felix Hartmann <extremecarver@gmail.com> wrote:
I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little).
do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too.
Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=no ne} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not).
On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk> wrote:
Hi Gerd
In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath.
r
Nick
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.h tml _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, I see the same result for b) and c) despite that one uses 0x01 and the other 0x13. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 18:40:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours. also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible. On 17 September 2017 at 18:26, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private. On 17 September 2017 at 18:14, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little). do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too. Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not). On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk<mailto:osm@pinns.co.uk>> wrote: Hi Gerd In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath. r Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, just in case it is not yet obvious: Some ways in your test data have highway=path but no service=driveway. Your rules don't add a road for it, so you probably don't get what you expect from the patch. Gerd ________________________________________ Von: Gerd Petermann Gesendet: Sonntag, 17. September 2017 19:39:02 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Felix, I see the same result for b) and c) despite that one uses 0x01 and the other 0x13. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 18:40:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours. also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible. On 17 September 2017 at 18:26, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private. On 17 September 2017 at 18:14, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little). do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too. Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not). On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk<mailto:osm@pinns.co.uk>> wrote: Hi Gerd In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath. r Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Gerd, sorry I should have tested better. Ì actually just inserted the rules into my normal ruleset and only used a clean lines file with example c) after noticing nothings seems to work - should have done that for b) too. So it seems there is some problem with *continue *following this statement! My testfile an the following lines file: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24] leads to: unconnected driveway, as well as semi_connected driveway both ending up in the map as 0x1040c. However the first 0x13 road is not in the map (neither unconnected, nor semi_connected). So it seems like after the continue command the previous (1. line of rules) ruleset is simply ignored. And yes - my testfile was intentional designed this way because I wanted to test out if roads being joined could change something. Changing the lines file to: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24] leads to: same result. even this: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway {set mkgmap:set_unconnected_type=none} [0x1040c resolution 24] leads to the 0x1040c line still being present in the final map. So the continue statement somehow havocs both the mkgmap:set_unconnected_type as well as the mkgmap:set_semi_connected_tye. Felix On 17 September 2017 at 19:52, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:
Hi Felix,
just in case it is not yet obvious: Some ways in your test data have highway=path but no service=driveway. Your rules don't add a road for it, so you probably don't get what you expect from the patch.
Gerd ________________________________________ Von: Gerd Petermann Gesendet: Sonntag, 17. September 2017 19:39:02 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Felix,
I see the same result for b) and c) despite that one uses 0x01 and the other 0x13.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 18:40:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours.
also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible.
On 17 September 2017 at 18:26, Felix Hartmann <extremecarver@gmail.com< mailto:extremecarver@gmail.com>> wrote: b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm
oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private.
On 17 September 2017 at 18:14, Felix Hartmann <extremecarver@gmail.com< mailto:extremecarver@gmail.com>> wrote: I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little).
do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too.
Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not).
On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk<mailto:osm@ pinns.co.uk>> wrote: Hi Gerd
In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath.
r
Nick
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, I think you wanted to use continue with_actions ? Besides that the special tags have no effect on the overlay lines . Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 22:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Gerd, sorry I should have tested better. Ì actually just inserted the rules into my normal ruleset and only used a clean lines file with example c) after noticing nothings seems to work - should have done that for b) too. So it seems there is some problem with continue following this statement! My testfile an the following lines file: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24] leads to: unconnected driveway, as well as semi_connected driveway both ending up in the map as 0x1040c. However the first 0x13 road is not in the map (neither unconnected, nor semi_connected). So it seems like after the continue command the previous (1. line of rules) ruleset is simply ignored. And yes - my testfile was intentional designed this way because I wanted to test out if roads being joined could change something. Changing the lines file to: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24] leads to: same result. even this: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway {set mkgmap:set_unconnected_type=none} [0x1040c resolution 24] leads to the 0x1040c line still being present in the final map. So the continue statement somehow havocs both the mkgmap:set_unconnected_type as well as the mkgmap:set_semi_connected_tye. Felix On 17 September 2017 at 19:52, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix, just in case it is not yet obvious: Some ways in your test data have highway=path but no service=driveway. Your rules don't add a road for it, so you probably don't get what you expect from the patch. Gerd ________________________________________ Von: Gerd Petermann Gesendet: Sonntag, 17. September 2017 19:39:02 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Felix, I see the same result for b) and c) despite that one uses 0x01 and the other 0x13. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Sonntag, 17. September 2017 18:40:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours. also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible. On 17 September 2017 at 18:26, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private. On 17 September 2017 at 18:14, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little). do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too. Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not). On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk<mailto:osm@pinns.co.uk><mailto:osm@pinns.co.uk<mailto:osm@pinns.co.uk>>> wrote: Hi Gerd In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath. r Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
well no - I did not want to use continue_with_actions - I mean that special tag is already set before - even If I set it on the line itself it seems to have no effect. The tag once set should apply to all iterations created by continue of the way, not just to the first (if set in a rule without action). Only if set in the same rule using continue alone it should make a difference vs continue_with_actions - so this is clearly not the intended behavior right now. Addendum: I just tested using continue with_actions --- same problem. The second line is not type=non but simply processed. Maybe the filter thinks it is connected to it's underlying original line? In my understanding the special tag should be worked down for the overlying lines exactly like the underlying lines (I use continue often 3-4 times on the same way - this case it's only matching once). Normal tags will also be evaluated for overlying ways. On 17 September 2017 at 22:56, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I think you wanted to use continue with_actions ? Besides that the special tags have no effect on the overlay lines .
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 22:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Gerd, sorry I should have tested better. Ì actually just inserted the rules into my normal ruleset and only used a clean lines file with example c) after noticing nothings seems to work - should have done that for b) too. So it seems there is some problem with continue following this statement! My testfile an the following lines file:
service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24]
leads to: unconnected driveway, as well as semi_connected driveway both ending up in the map as 0x1040c. However the first 0x13 road is not in the map (neither unconnected, nor semi_connected). So it seems like after the continue command the previous (1. line of rules) ruleset is simply ignored. And yes - my testfile was intentional designed this way because I wanted to test out if roads being joined could change something.
Changing the lines file to: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24]
leads to: same result.
even this: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway {set mkgmap:set_unconnected_type=none} [0x1040c resolution 24]
leads to the 0x1040c line still being present in the final map. So the continue statement somehow havocs both the mkgmap:set_unconnected_type as well as the mkgmap:set_semi_connected_tye.
Felix
On 17 September 2017 at 19:52, Gerd Petermann < GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix,
just in case it is not yet obvious: Some ways in your test data have highway=path but no service=driveway. Your rules don't add a road for it, so you probably don't get what you expect from the patch.
Gerd ________________________________________ Von: Gerd Petermann Gesendet: Sonntag, 17. September 2017 19:39:02 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Felix,
I see the same result for b) and c) despite that one uses 0x01 and the other 0x13.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap- dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Sonntag, 17. September 2017 18:40:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours.
also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible.
On 17 September 2017 at 18:26, Felix Hartmann <extremecarver@gmail.com< mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm
oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private.
On 17 September 2017 at 18:14, Felix Hartmann <extremecarver@gmail.com< mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little).
do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too.
Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not).
On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk<mailto:osm@ pinns.co.uk><mailto:osm@pinns.co.uk<mailto:osm@pinns.co.uk>>> wrote: Hi Gerd
In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath.
r
Nick
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists. mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, yes, you are right, when you create two or more routable lines from the same OSM way the algo counts them as connected on each point. I'll try catch this special case with a new patch. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 23:19:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only well no - I did not want to use continue_with_actions - I mean that special tag is already set before - even If I set it on the line itself it seems to have no effect. The tag once set should apply to all iterations created by continue of the way, not just to the first (if set in a rule without action). Only if set in the same rule using continue alone it should make a difference vs continue_with_actions - so this is clearly not the intended behavior right now. Addendum: I just tested using continue with_actions --- same problem. The second line is not type=non but simply processed. Maybe the filter thinks it is connected to it's underlying original line? In my understanding the special tag should be worked down for the overlying lines exactly like the underlying lines (I use continue often 3-4 times on the same way - this case it's only matching once). Normal tags will also be evaluated for overlying ways. On 17 September 2017 at 22:56, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix, I think you wanted to use continue with_actions ? Besides that the special tags have no effect on the overlay lines . Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Sonntag, 17. September 2017 22:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Gerd, sorry I should have tested better. Ì actually just inserted the rules into my normal ruleset and only used a clean lines file with example c) after noticing nothings seems to work - should have done that for b) too. So it seems there is some problem with continue following this statement! My testfile an the following lines file: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24] leads to: unconnected driveway, as well as semi_connected driveway both ending up in the map as 0x1040c. However the first 0x13 road is not in the map (neither unconnected, nor semi_connected). So it seems like after the continue command the previous (1. line of rules) ruleset is simply ignored. And yes - my testfile was intentional designed this way because I wanted to test out if roads being joined could change something. Changing the lines file to: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24] leads to: same result. even this: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway {set mkgmap:set_unconnected_type=none} [0x1040c resolution 24] leads to the 0x1040c line still being present in the final map. So the continue statement somehow havocs both the mkgmap:set_unconnected_type as well as the mkgmap:set_semi_connected_tye. Felix On 17 September 2017 at 19:52, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>> wrote: Hi Felix, just in case it is not yet obvious: Some ways in your test data have highway=path but no service=driveway. Your rules don't add a road for it, so you probably don't get what you expect from the patch. Gerd ________________________________________ Von: Gerd Petermann Gesendet: Sonntag, 17. September 2017 19:39:02 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Felix, I see the same result for b) and c) despite that one uses 0x01 and the other 0x13. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Sonntag, 17. September 2017 18:40:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours. also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible. On 17 September 2017 at 18:26, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private. On 17 September 2017 at 18:14, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little). do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too. Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not). On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk<mailto:osm@pinns.co.uk><mailto:osm@pinns.co.uk<mailto:osm@pinns.co.uk>><mailto:osm@pinns.co.uk<mailto:osm@pinns.co.uk><mailto:osm@pinns.co.uk<mailto:osm@pinns.co.uk>>>> wrote: Hi Gerd In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath. r Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, sorry, was too fast. The algo counts each OSM way only once, so I think regarding the routable ways it works fine. The algo is simply not used for non-routable ines. If I got you right you also want that the overlaying non-routable line is removed when it has mkgmap:set_semi_connected_type=none ? What should happen if the style adds the same OSM way multiple times as routable line, sometimes with mkgmap:set_semi_connected_type=none , sometimes without? Or with different values for the tag mkgmap:set_semi_connected_type? What would be the meaning of mkgmap:set_semi_connected_type=0x10806 for such an overlay line? Sounds too complex for me. I think we need a different logic here. My understanding is that you only want the non-routable overlay line(s) if at least one routable line was created for the same OSM way. So, we need a method to tell mkgmap that a given non-routable line should be ignored if no routable way line exists for the same OSM way. I think we should not use the special tags mkgmap:set_semi_connected_type or mkgmap:set_unconnected_type for this. Do you agree? Gerd ________________________________________ Von: Gerd Petermann Gesendet: Montag, 18. September 2017 06:47:12 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Felix, yes, you are right, when you create two or more routable lines from the same OSM way the algo counts them as connected on each point. I'll try catch this special case with a new patch. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 23:19:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only well no - I did not want to use continue_with_actions - I mean that special tag is already set before - even If I set it on the line itself it seems to have no effect. The tag once set should apply to all iterations created by continue of the way, not just to the first (if set in a rule without action). Only if set in the same rule using continue alone it should make a difference vs continue_with_actions - so this is clearly not the intended behavior right now. Addendum: I just tested using continue with_actions --- same problem. The second line is not type=non but simply processed. Maybe the filter thinks it is connected to it's underlying original line? In my understanding the special tag should be worked down for the overlying lines exactly like the underlying lines (I use continue often 3-4 times on the same way - this case it's only matching once). Normal tags will also be evaluated for overlying ways. On 17 September 2017 at 22:56, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix, I think you wanted to use continue with_actions ? Besides that the special tags have no effect on the overlay lines . Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Sonntag, 17. September 2017 22:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Gerd, sorry I should have tested better. Ì actually just inserted the rules into my normal ruleset and only used a clean lines file with example c) after noticing nothings seems to work - should have done that for b) too. So it seems there is some problem with continue following this statement! My testfile an the following lines file: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24] leads to: unconnected driveway, as well as semi_connected driveway both ending up in the map as 0x1040c. However the first 0x13 road is not in the map (neither unconnected, nor semi_connected). So it seems like after the continue command the previous (1. line of rules) ruleset is simply ignored. And yes - my testfile was intentional designed this way because I wanted to test out if roads being joined could change something. Changing the lines file to: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24] leads to: same result. even this: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway {set mkgmap:set_unconnected_type=none} [0x1040c resolution 24] leads to the 0x1040c line still being present in the final map. So the continue statement somehow havocs both the mkgmap:set_unconnected_type as well as the mkgmap:set_semi_connected_tye. Felix On 17 September 2017 at 19:52, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>> wrote: Hi Felix, just in case it is not yet obvious: Some ways in your test data have highway=path but no service=driveway. Your rules don't add a road for it, so you probably don't get what you expect from the patch. Gerd ________________________________________ Von: Gerd Petermann Gesendet: Sonntag, 17. September 2017 19:39:02 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Felix, I see the same result for b) and c) despite that one uses 0x01 and the other 0x13. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Sonntag, 17. September 2017 18:40:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours. also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible. On 17 September 2017 at 18:26, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private. On 17 September 2017 at 18:14, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little). do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too. Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not). On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk<mailto:osm@pinns.co.uk><mailto:osm@pinns.co.uk<mailto:osm@pinns.co.uk>><mailto:osm@pinns.co.uk<mailto:osm@pinns.co.uk><mailto:osm@pinns.co.uk<mailto:osm@pinns.co.uk>>>> wrote: Hi Gerd In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath. r Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
thanks for the clarification. Well in my opinion the algo should treat it as close as similar as possible to normal tags. x=* {set mkgmap:set_semi_connected_type=*} as above without [] ---> applies to all objects that follow. also okay if due to the special way it applies simply to all objects no matter if before or after x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class.. continue with_actions] same as above x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class.. continue] only apply to the object created x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class] only apply to the object created The problem is simply that we don't have enough routable types - so many styles use an invisible routable line overlaid with the visible line of the road/street - so both should be removed. Or take a bridge - if you decide to not show the road for that semi_connected_bridge - you may also want to not show the bridge. I don't need this for fully non routable lines - but manybe other people see sense in also applying the semi_connected or unconnected tags to fully non routable objects. E.g. stairs - maybe someone does not want them to be routable in his map - but only show them if they are connected to a routable way. Right now that's not possible. Same maybe for ferry lines, gondolas or public transport platforms. And yes - if it were possible to use it as a standard tag instaed of the special tag - even better. I thought that was not possible due to the way the tag works. Right now it definitely is a bit confusing as it's more or less the only tag that works differently. On 18 September 2017 at 08:11, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:
Hi Felix,
sorry, was too fast. The algo counts each OSM way only once, so I think regarding the routable ways it works fine. The algo is simply not used for non-routable ines. If I got you right you also want that the overlaying non-routable line is removed when it has mkgmap:set_semi_connected_type=none ?
What should happen if the style adds the same OSM way multiple times as routable line, sometimes with mkgmap:set_semi_connected_type=none , sometimes without? Or with different values for the tag mkgmap:set_semi_connected_type? What would be the meaning of mkgmap:set_semi_connected_type=0x10806 for such an overlay line?
Sounds too complex for me.
I think we need a different logic here. My understanding is that you only want the non-routable overlay line(s) if at least one routable line was created for the same OSM way. So, we need a method to tell mkgmap that a given non-routable line should be ignored if no routable way line exists for the same OSM way. I think we should not use the special tags mkgmap:set_semi_connected_type or mkgmap:set_unconnected_type for this. Do you agree?
Gerd ________________________________________ Von: Gerd Petermann Gesendet: Montag, 18. September 2017 06:47:12 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Felix,
yes, you are right, when you create two or more routable lines from the same OSM way the algo counts them as connected on each point. I'll try catch this special case with a new patch.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Sonntag, 17. September 2017 23:19:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
well no - I did not want to use continue_with_actions - I mean that special tag is already set before - even If I set it on the line itself it seems to have no effect.
The tag once set should apply to all iterations created by continue of the way, not just to the first (if set in a rule without action). Only if set in the same rule using continue alone it should make a difference vs continue_with_actions - so this is clearly not the intended behavior right now.
Addendum: I just tested using continue with_actions --- same problem. The second line is not type=non but simply processed. Maybe the filter thinks it is connected to it's underlying original line?
In my understanding the special tag should be worked down for the overlying lines exactly like the underlying lines (I use continue often 3-4 times on the same way - this case it's only matching once). Normal tags will also be evaluated for overlying ways.
On 17 September 2017 at 22:56, Gerd Petermann < GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix,
I think you wanted to use continue with_actions ? Besides that the special tags have no effect on the overlay lines .
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap- dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Sonntag, 17. September 2017 22:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Gerd, sorry I should have tested better. Ì actually just inserted the rules into my normal ruleset and only used a clean lines file with example c) after noticing nothings seems to work - should have done that for b) too. So it seems there is some problem with continue following this statement! My testfile an the following lines file:
service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24]
leads to: unconnected driveway, as well as semi_connected driveway both ending up in the map as 0x1040c. However the first 0x13 road is not in the map (neither unconnected, nor semi_connected). So it seems like after the continue command the previous (1. line of rules) ruleset is simply ignored. And yes - my testfile was intentional designed this way because I wanted to test out if roads being joined could change something.
Changing the lines file to: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24]
leads to: same result.
even this: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway {set mkgmap:set_unconnected_type=none} [0x1040c resolution 24]
leads to the 0x1040c line still being present in the final map. So the continue statement somehow havocs both the mkgmap:set_unconnected_type as well as the mkgmap:set_semi_connected_tye.
Felix
On 17 September 2017 at 19:52, Gerd Petermann < GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com
<mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@ hotmail.com>>> wrote: Hi Felix,
just in case it is not yet obvious: Some ways in your test data have highway=path but no service=driveway. Your rules don't add a road for it, so you probably don't get what you expect from the patch.
Gerd ________________________________________ Von: Gerd Petermann Gesendet: Sonntag, 17. September 2017 19:39:02 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Felix,
I see the same result for b) and c) despite that one uses 0x01 and the other 0x13.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap- dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@ lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> Gesendet: Sonntag, 17. September 2017 18:40:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours.
also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible.
On 17 September 2017 at 18:26, Felix Hartmann <extremecarver@gmail.com< mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecar ver@gmail.com><mailto:extremecarver@gmail.com<mailto:extreme carver@gmail.com>>>> wrote: b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm
oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private.
On 17 September 2017 at 18:14, Felix Hartmann <extremecarver@gmail.com< mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecar ver@gmail.com><mailto:extremecarver@gmail.com<mailto:extreme carver@gmail.com>>>> wrote: I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little).
do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too.
Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not).
On 17 September 2017 at 17:33, nwillink <osm@pinns.co.uk<mailto:osm@ pinns.co.uk><mailto:osm@pinns.co.uk<mailto:osm@pinns.co.uk>><mailto: osm@pinns.co.uk<mailto:osm@pinns.co.uk><mailto:osm@pinns.co.uk<mailto: osm@pinns.co.uk>>>> wrote: Hi Gerd
In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath.
r
Nick
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists. mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk< mailto:mkgmap-dev@lists.mkgmap.org.uk>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists. mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, 1) the tag mkgmap:set_semi_connected_type is only special because it starts with the mkgmap: prefix, within the style processing it is treated like any other tag. The tag is first evaluated by mkgmap after all elements where processed by the style. 2) I agree that the new function doesn't work well for a style that creates multiple lines for a single OSM way. I also think that this is the case with mkgmap:set_unconnected_type. 3) You suggested to implement the new tag similar to mkgmap:set_unconnected_type, but it seems you never used it? It is easy to change the code so that it removes an overlay line when there is no routable line for the same OSM way. I have already coded this on my system. I can change the code to check if also the overlay line has a special tag, I just don't like the idea that mkgmap:set_unconnected_type or mkgmap:set_semi_connected_type should be used for this. Gerd Felix Hartmann-2 wrote
thanks for the clarification.
Well in my opinion the algo should treat it as close as similar as possible to normal tags.
x=* {set mkgmap:set_semi_connected_type=*} as above without [] ---> applies to all objects that follow. also okay if due to the special way it applies simply to all objects no matter if before or after
x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class.. continue with_actions] same as above
x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class.. continue] only apply to the object created
x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class] only apply to the object created
The problem is simply that we don't have enough routable types - so many styles use an invisible routable line overlaid with the visible line of the road/street - so both should be removed. Or take a bridge - if you decide to not show the road for that semi_connected_bridge - you may also want to not show the bridge. I don't need this for fully non routable lines - but manybe other people see sense in also applying the semi_connected or unconnected tags to fully non routable objects.
E.g. stairs - maybe someone does not want them to be routable in his map - but only show them if they are connected to a routable way. Right now that's not possible. Same maybe for ferry lines, gondolas or public transport platforms.
And yes - if it were possible to use it as a standard tag instaed of the special tag - even better. I thought that was not possible due to the way the tag works. Right now it definitely is a bit confusing as it's more or less the only tag that works differently.
On 18 September 2017 at 08:11, Gerd Petermann <
GPetermann_muenchen@
wrote:
Hi Felix,
sorry, was too fast. The algo counts each OSM way only once, so I think regarding the routable ways it works fine. The algo is simply not used for non-routable ines. If I got you right you also want that the overlaying non-routable line is removed when it has mkgmap:set_semi_connected_type=none ?
What should happen if the style adds the same OSM way multiple times as routable line, sometimes with mkgmap:set_semi_connected_type=none , sometimes without? Or with different values for the tag mkgmap:set_semi_connected_type? What would be the meaning of mkgmap:set_semi_connected_type=0x10806 for such an overlay line?
Sounds too complex for me.
I think we need a different logic here. My understanding is that you only want the non-routable overlay line(s) if at least one routable line was created for the same OSM way. So, we need a method to tell mkgmap that a given non-routable line should be ignored if no routable way line exists for the same OSM way. I think we should not use the special tags mkgmap:set_semi_connected_type or mkgmap:set_unconnected_type for this. Do you agree?
Gerd ________________________________________ Von: Gerd Petermann Gesendet: Montag, 18. September 2017 06:47:12 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Felix,
yes, you are right, when you create two or more routable lines from the same OSM way the algo counts them as connected on each point. I'll try catch this special case with a new patch.
Gerd ________________________________________ Von: mkgmap-dev <
mkgmap-dev-bounces@.org
> im Auftrag von
Felix Hartmann <
extremecarver@
>
Gesendet: Sonntag, 17. September 2017 23:19:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
well no - I did not want to use continue_with_actions - I mean that special tag is already set before - even If I set it on the line itself it seems to have no effect.
The tag once set should apply to all iterations created by continue of the way, not just to the first (if set in a rule without action). Only if set in the same rule using continue alone it should make a difference vs continue_with_actions - so this is clearly not the intended behavior right now.
Addendum: I just tested using continue with_actions --- same problem. The second line is not type=non but simply processed. Maybe the filter thinks it is connected to it's underlying original line?
In my understanding the special tag should be worked down for the overlying lines exactly like the underlying lines (I use continue often 3-4 times on the same way - this case it's only matching once). Normal tags will also be evaluated for overlying ways.
On 17 September 2017 at 22:56, Gerd Petermann <
GPetermann_muenchen@
<mailto:
GPetermann_muenchen@
>>
wrote: Hi Felix,
I think you wanted to use continue with_actions ? Besides that the special tags have no effect on the overlay lines .
Gerd ________________________________________ Von: mkgmap-dev <
mkgmap-dev-bounces@.org
<mailto:mkgmap- >
dev-bounces@.org
im Auftrag von Felix Hartmann <
extremecarver@
<mailto:
extremecarver@
>>
Gesendet: Sonntag, 17. September 2017 22:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Gerd, sorry I should have tested better. Ì actually just inserted the rules into my normal ruleset and only used a clean lines file with example c) after noticing nothings seems to work - should have done that for b) too. So it seems there is some problem with continue following this statement! My testfile an the following lines file:
service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24]
leads to: unconnected driveway, as well as semi_connected driveway both ending up in the map as 0x1040c. However the first 0x13 road is not in the map (neither unconnected, nor semi_connected). So it seems like after the continue command the previous (1. line of rules) ruleset is simply ignored. And yes - my testfile was intentional designed this way because I wanted to test out if roads being joined could change something.
Changing the lines file to: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24]
leads to: same result.
even this: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway {set mkgmap:set_unconnected_type=none} [0x1040c resolution 24]
leads to the 0x1040c line still being present in the final map. So the continue statement somehow havocs both the mkgmap:set_unconnected_type as well as the mkgmap:set_semi_connected_tye.
Felix
On 17 September 2017 at 19:52, Gerd Petermann <
GPetermann_muenchen@
<mailto:
GPetermann_muenchen@
> ><mailto:
GPetermann_muenchen@
<mailto:GPetermann_muenchen@ > hotmail.com>>> wrote:
Hi Felix,
just in case it is not yet obvious: Some ways in your test data have highway=path but no service=driveway. Your rules don't add a road for it, so you probably don't get what you expect from the patch.
Gerd ________________________________________ Von: Gerd Petermann Gesendet: Sonntag, 17. September 2017 19:39:02 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Felix,
I see the same result for b) and c) despite that one uses 0x01 and the other 0x13.
Gerd ________________________________________ Von: mkgmap-dev <
mkgmap-dev-bounces@.org
<mailto:mkgmap- >
dev-bounces@.org
<mailto:mkgmap-dev-bounces@ > lists.mkgmap.org.uk<mailto:
mkgmap-dev-bounces@.org
>>> im
Auftrag von Felix Hartmann <
extremecarver@
<mailto: >
extremecarver@
<mailto:
extremecarver@
<mailto: >
extremecarver@
Gesendet: Sonntag, 17. September 2017 18:40:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours.
also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible.
On 17 September 2017 at 18:26, Felix Hartmann <
extremecarver@
< > mailto:
extremecarver@
<mailto:
extremecarver@
<mailto: >
extremecarver@
<mailto:
extremecarver@
<mailto:extremecar >
ver@
<mailto:
extremecarver@
<mailto:extreme >
carver@
wrote: b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm
oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private.
On 17 September 2017 at 18:14, Felix Hartmann <
extremecarver@
< > mailto:
extremecarver@
<mailto:
extremecarver@
<mailto: >
extremecarver@
<mailto:
extremecarver@
<mailto:extremecar >
ver@
<mailto:
extremecarver@
<mailto:extreme >
carver@
wrote: I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little).
do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too.
Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not).
On 17 September 2017 at 17:33, nwillink <
osm@.co
<mailto:osm@ > pinns.co.uk><mailto:
osm@.co
<mailto:
osm@.co
>> <mailto:
osm@.co
<mailto:
osm@.co
><mailto:
osm@.co
<mailto: >
osm@.co
wrote: Hi Gerd
In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath.
r
Nick
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
> ><mailto:
mkgmap-dev@.org
<mailto:mkgmap-dev@lists. > mkgmap.org.uk>><mailto:
mkgmap-dev@.org
<mailto: >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
< > mailto:
mkgmap-dev@.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
> ><mailto:
mkgmap-dev@.org
<mailto:mkgmap-dev@lists. > mkgmap.org.uk>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
Hi Gerd, 2. yes it's the case for both tags. 3. I'm fine with another name - maybe mkgmap:set_semi_connected_line=none and mkgmap:set_unconnected_line=none? Well I actually already went through my style and added mkgmap:set_semi_connected_type=none - I'm just missing the overlays also being removed as explained to fully use it. I actually had not noticed that mkgmap:set_unconnected_type=none did not remove all the lines that I intended to be removed by it because I never properly checked it using a test file - and there are not many unconnected ways in real OSM data (while there are far more semi_connected lines/ways). Actually I think it should be semiconnected as we alo use unconnected and not un_connected (even though it is two words in proper spelling). On 18 September 2017 at 19:49, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
1) the tag mkgmap:set_semi_connected_type is only special because it starts with the mkgmap: prefix, within the style processing it is treated like any other tag. The tag is first evaluated by mkgmap after all elements where processed by the style. 2) I agree that the new function doesn't work well for a style that creates multiple lines for a single OSM way. I also think that this is the case with mkgmap:set_unconnected_type. 3) You suggested to implement the new tag similar to mkgmap:set_unconnected_type, but it seems you never used it?
It is easy to change the code so that it removes an overlay line when there is no routable line for the same OSM way. I have already coded this on my system. I can change the code to check if also the overlay line has a special tag, I just don't like the idea that mkgmap:set_unconnected_type or mkgmap:set_semi_connected_type should be used for this.
Gerd
thanks for the clarification.
Well in my opinion the algo should treat it as close as similar as possible to normal tags.
x=* {set mkgmap:set_semi_connected_type=*} as above without [] ---> applies to all objects that follow. also okay if due to the special way it applies simply to all objects no matter if before or after
x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class.. continue with_actions] same as above
x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class.. continue] only apply to the object created
x=* {set mkgmap:set_semi_connected_type=*} [0x01 road-class] only apply to the object created
The problem is simply that we don't have enough routable types - so many styles use an invisible routable line overlaid with the visible line of the road/street - so both should be removed. Or take a bridge - if you decide to not show the road for that semi_connected_bridge - you may also want to not show the bridge. I don't need this for fully non routable lines - but manybe other people see sense in also applying the semi_connected or unconnected tags to fully non routable objects.
E.g. stairs - maybe someone does not want them to be routable in his map
Felix Hartmann-2 wrote -
but only show them if they are connected to a routable way. Right now that's not possible. Same maybe for ferry lines, gondolas or public transport platforms.
And yes - if it were possible to use it as a standard tag instaed of the special tag - even better. I thought that was not possible due to the way the tag works. Right now it definitely is a bit confusing as it's more or less the only tag that works differently.
On 18 September 2017 at 08:11, Gerd Petermann <
GPetermann_muenchen@
wrote:
Hi Felix,
sorry, was too fast. The algo counts each OSM way only once, so I think regarding the routable ways it works fine. The algo is simply not used for non-routable ines. If I got you right you also want that the overlaying non-routable line is removed when it has mkgmap:set_semi_connected_type=none ?
What should happen if the style adds the same OSM way multiple times as routable line, sometimes with mkgmap:set_semi_connected_type=none , sometimes without? Or with different values for the tag mkgmap:set_semi_connected_type? What would be the meaning of mkgmap:set_semi_connected_type=0x10806 for such an overlay line?
Sounds too complex for me.
I think we need a different logic here. My understanding is that you only want the non-routable overlay line(s) if at least one routable line was created for the same OSM way. So, we need a method to tell mkgmap that a given non-routable line should be ignored if no routable way line exists for the same OSM way. I think we should not use the special tags mkgmap:set_semi_connected_type or mkgmap:set_unconnected_type for this. Do you agree?
Gerd ________________________________________ Von: Gerd Petermann Gesendet: Montag, 18. September 2017 06:47:12 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Felix,
yes, you are right, when you create two or more routable lines from the same OSM way the algo counts them as connected on each point. I'll try catch this special case with a new patch.
Gerd ________________________________________ Von: mkgmap-dev <
mkgmap-dev-bounces@.org
im Auftrag von Felix Hartmann <
extremecarver@
Gesendet: Sonntag, 17. September 2017 23:19:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
well no - I did not want to use continue_with_actions - I mean that special tag is already set before - even If I set it on the line itself it seems to have no effect.
The tag once set should apply to all iterations created by continue of the way, not just to the first (if set in a rule without action). Only if set in the same rule using continue alone it should make a difference vs continue_with_actions - so this is clearly not the
intended
behavior right now.
Addendum: I just tested using continue with_actions --- same problem. The second line is not type=non but simply processed. Maybe the filter thinks it is connected to it's underlying original line?
In my understanding the special tag should be worked down for the overlying lines exactly like the underlying lines (I use continue often 3-4 times on the same way - this case it's only matching once). Normal tags will also be evaluated for overlying ways.
On 17 September 2017 at 22:56, Gerd Petermann <
GPetermann_muenchen@
<mailto:
GPetermann_muenchen@
wrote: Hi Felix,
I think you wanted to use continue with_actions ? Besides that the special tags have no effect on the overlay lines .
Gerd ________________________________________ Von: mkgmap-dev <
mkgmap-dev-bounces@.org
<mailto:mkgmap-
dev-bounces@.org
im Auftrag von Felix Hartmann <
extremecarver@
<mailto:
extremecarver@
Gesendet: Sonntag, 17. September 2017 22:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Gerd, sorry I should have tested better. Ì actually just inserted the rules into my normal ruleset and only used a clean lines file with example c) after noticing nothings seems to work - should have done that for b) too. So it seems there is some problem with continue following this statement! My testfile an the following lines file:
service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24]
leads to: unconnected driveway, as well as semi_connected driveway both ending up in the map as 0x1040c. However the first 0x13 road is not in the map (neither unconnected, nor semi_connected). So it seems like after the continue command the previous (1. line of rules) ruleset is simply ignored. And yes - my testfile was intentional designed this way because I wanted to test out if roads being joined could change something.
Changing the lines file to: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway [0x1040c resolution 24]
leads to: same result.
even this: service=driveway & ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & access!=yes & access!=designated & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no | vehicle=private | vehicle!=* ) & foot!=private & foot!=yes & foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* & mtb:scale!=* {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} service=driveway {set mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0 resolution 24 continue] service=driveway {set mkgmap:set_unconnected_type=none} [0x1040c resolution 24]
leads to the 0x1040c line still being present in the final map. So the continue statement somehow havocs both the mkgmap:set_unconnected_type as well as the mkgmap:set_semi_connected_tye.
Felix
On 17 September 2017 at 19:52, Gerd Petermann <
GPetermann_muenchen@
<mailto:
GPetermann_muenchen@
<mailto:
GPetermann_muenchen@
<mailto:GPetermann_muenchen@
hotmail.com>>> wrote: Hi Felix,
just in case it is not yet obvious: Some ways in your test data have highway=path but no service=driveway. Your rules don't add a road for it, so you probably don't get what you expect from the patch.
Gerd ________________________________________ Von: Gerd Petermann Gesendet: Sonntag, 17. September 2017 19:39:02 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Hi Felix,
I see the same result for b) and c) despite that one uses 0x01 and the other 0x13.
Gerd ________________________________________ Von: mkgmap-dev <
mkgmap-dev-bounces@.org
<mailto:mkgmap-
dev-bounces@.org
<mailto:mkgmap-dev-bounces@ lists.mkgmap.org.uk<mailto:
mkgmap-dev-bounces@.org
im Auftrag von Felix Hartmann <
extremecarver@
<mailto:
extremecarver@
<mailto:
extremecarver@
<mailto:
extremecarver@
Gesendet: Sonntag, 17. September 2017 18:40:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
only 24% of service=driveway have access tagging (mostly access=private) - however I guess 99% of those that are semi-connected and 99.99% that are unconnected are really not needed in a general map (no matter if they are private or not) - however you just cannot drop all service=driveways without access tags except for an automotive map as that often leads to missing important connectors and thereby big detours.
also it could be worth a try if long distance autorouting worked better if a general rule in the finalize section or further in front like highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'} (or try with '-1') could improve routing results. But maybe they are penalized by the garmin algorithm already enough anyhow. Now that rule really won't work with the current way it works - and I don't even know it will help. It's just something,that i would try out if it were possible.
On 17 September 2017 at 18:26, Felix Hartmann <
extremecarver@
<
mailto:
extremecarver@
<mailto:
extremecarver@
<mailto:
extremecarver@
<mailto:
extremecarver@
<mailto:extremecar
ver@
<mailto:
extremecarver@
<mailto:extreme
carver@
wrote: b) did not work when I tried it. I have a test file here (very simple): https://openmtbmap.org/wp-content/images/debug/driveways.osm
oh yeah the idea why semi_connected is needed camp up because many (mainly highway=service & service=driveway and no other tags )in France and Switzerland are actually needed to get from roads for cars onto pathes/tracks. Often through a supermarket parking or similar while highway=service & service=driveway (likewise with no other tag) but mostly connected only on one side to public roads - are used to map ways to access a private house door or garden - they really clutter up the map hence I want to remove them. And yes - sadly far too little driveways add a foot=yes or foot=designated, or access=yes/access=designated while also far too many really private ways lack a access=private. Some people in OSM understand that service=driveway means it public without other tags, while others understand that it's private.
On 17 September 2017 at 18:14, Felix Hartmann <
extremecarver@
<
mailto:
extremecarver@
<mailto:
extremecarver@
<mailto:
extremecarver@
<mailto:
extremecarver@
<mailto:extremecar
ver@
<mailto:
extremecarver@
<mailto:extreme
carver@
wrote: I've seen a couple - but yes - according to taginfo it's really little, https://taginfo.openstreetmap.org/tags/service=driveway (most are highway=service, then residential and others are really really little).
do you think you can change the behavior that b) will also work? If not I'm just going to rewrite my rules for highway=service - and drop the idea to get rid of track,residential, footway and path with service=driveway tag (and hope this does not change in future). All other things that are specified in {} brackets also work like b) - that's why I thought it should work that way too.
Another possibility would be if it could be added to the finalize section instead. So have in finalize section ( highway=service | highway=track | highway=path | highway=footway | highway=residential ) & service=driveway {set mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none} which would then overrule rules given higher up. (I did not try if this will work already - but I guess not).
On 17 September 2017 at 17:33, nwillink <
osm@.co
<mailto:osm@
pinns.co.uk><mailto:
osm@.co
<mailto:
osm@.co
<mailto:
osm@.co
<mailto:
osm@.co
<mailto:
osm@.co
<mailto:
osm@.co
wrote: Hi Gerd
In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath.
r
Nick
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
<mailto:mkgmap-dev@lists.
mkgmap.org.uk>><mailto:
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
<
mailto:
mkgmap-dev@.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
<mailto:mkgmap-dev@lists.
mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi all, what do you think about a tag named mkgmap:remove-if-no-road=yes ? I would add code to check all non-routable lines for this tag. If no routable line is found for the same OSM way the line is removed. This check is performed after the processing of the 2 mkgmap:set_xxx_type tags and maybe other routines which remove routable lines because they are too short etc. Gerd Felix Hartmann-2 wrote
3. I'm fine with another name - maybe mkgmap:set_semi_connected_line=none and mkgmap:set_unconnected_line=none? Well I actually already went through my style and added mkgmap:set_semi_connected_type=none - I'm just missing the overlays also being removed as explained to fully use it. I actually had not noticed that mkgmap:set_unconnected_type=none did not remove all the lines that I intended to be removed by it because I never properly checked it using a test file - and there are not many unconnected ways in real OSM data (while there are far more semi_connected lines/ways). Actually I think it should be semiconnected as we alo use unconnected and not un_connected (even though it is two words in proper spelling).
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
But does it mean semi_connected or unconnected? I would like to have both as option if possible. On 18 September 2017 at 21:22, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi all,
what do you think about a tag named mkgmap:remove-if-no-road=yes ? I would add code to check all non-routable lines for this tag. If no routable line is found for the same OSM way the line is removed. This check is performed after the processing of the 2 mkgmap:set_xxx_type tags and maybe other routines which remove routable lines because they are too short etc.
Gerd
Felix Hartmann-2 wrote
3. I'm fine with another name - maybe mkgmap:set_semi_connected_ line=none and mkgmap:set_unconnected_line=none? Well I actually already went through my style and added mkgmap:set_semi_connected_type=none - I'm just missing the overlays also being removed as explained to fully use it. I actually had not noticed that mkgmap:set_unconnected_type=none did not remove all the lines that I intended to be removed by it because I never properly checked it using a test file - and there are not many unconnected ways in real OSM data (while there are far more semi_connected lines/ways). Actually I think it should be semiconnected as we alo use unconnected and not un_connected (even though it is two words in proper spelling).
-- 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Well, I just noticed that mkgmap:set_unconnected_type is not yet documented. When I implemented it with r2599 I decided to remove all overlay lines if the road is unconnected and mkgmap:set_unconnected_type=none is used. Later, Steve changed this in r2707, the reason was that you complained about the old behaviour. Please read these old threads carefully: http://gis.19327.n8.nabble.com/Serious-mkgmap-Bug-set-unconnected-type-not-r... http://gis.19327.n8.nabble.com/Commit-r2707-Don-t-complete-remove-an-unconne... My understanding of these discussions is that we need is an option or tag that controls what to do with an overlay line when the underlying road was removed. Gerd Felix Hartmann-2 wrote
But does it mean semi_connected or unconnected? I would like to have both as option if possible.
On 18 September 2017 at 21:22, Gerd Petermann <
gpetermann_muenchen@
wrote:
Hi all,
what do you think about a tag named mkgmap:remove-if-no-road=yes ? I would add code to check all non-routable lines for this tag. If no routable line is found for the same OSM way the line is removed. This check is performed after the processing of the 2 mkgmap:set_xxx_type tags and maybe other routines which remove routable lines because they are too short etc.
Gerd
Felix Hartmann-2 wrote
3. I'm fine with another name - maybe mkgmap:set_semi_connected_ line=none and mkgmap:set_unconnected_line=none? Well I actually already went through my style and added mkgmap:set_semi_connected_type=none - I'm just missing the overlays also being removed as explained to fully use it. I actually had not noticed that mkgmap:set_unconnected_type=none did not remove all the lines that I intended to be removed by it because I never properly checked it using a test file - and there are not many unconnected ways in real OSM data (while there are far more semi_connected lines/ways). Actually I think it should be semiconnected as we alo use unconnected and not un_connected (even though it is two words in proper spelling).
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
oh yeah - I remember. The problem ist neither the old nor the current behaviour works correctly in comparison to other tags. I complained that it applies to all occurences - even though using continue (i only used a line like highway=abc {set mkgmap:set_unconnected_type=none} [0x?? road_class=? road_speed=? continue] ) I really think the best solution if strict sticking to rules without [] block, and respecting continue vs continue with_actions is not possible would be to have to different special tags - one removing also all non routable overlay lines, while the other tag does not. Back then I only used mkgmap_set_unconnected_type=none to remove unconnected roads that make autorouting go crazy (it's unconnected - someone starts a route there - and the route just breaks - mainly because people did not connect the road correctly - and it has nearly invisible gaps on both side - which Potlach v1 was a bit famous for) - now the use case is more to filter out clutter for the semi_connected so I rather want to have it also filter out all overlays. (I'm fine using continue with_actions as supposed). On 19 September 2017 at 08:16, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Well, I just noticed that mkgmap:set_unconnected_type is not yet documented. When I implemented it with r2599 I decided to remove all overlay lines if the road is unconnected and mkgmap:set_unconnected_type=none is used. Later, Steve changed this in r2707, the reason was that you complained about the old behaviour. Please read these old threads carefully: http://gis.19327.n8.nabble.com/Serious-mkgmap-Bug-set- unconnected-type-not-respecting-continue-command-tp5775051.html http://gis.19327.n8.nabble.com/Commit-r2707-Don-t-complete-remove-an- unconnected-road-tp5777740.html
My understanding of these discussions is that we need is an option or tag that controls what to do with an overlay line when the underlying road was removed.
Gerd
Felix Hartmann-2 wrote
But does it mean semi_connected or unconnected? I would like to have both as option if possible.
On 18 September 2017 at 21:22, Gerd Petermann <
gpetermann_muenchen@
wrote:
Hi all,
what do you think about a tag named mkgmap:remove-if-no-road=yes ? I would add code to check all non-routable lines for this tag. If no routable line is found for the same OSM way the line is removed. This check is performed after the processing of the 2 mkgmap:set_xxx_type tags and maybe other routines which remove routable lines because they are too short etc.
Gerd
Felix Hartmann-2 wrote
3. I'm fine with another name - maybe mkgmap:set_semi_connected_ line=none and mkgmap:set_unconnected_line=none? Well I actually already went through my style and added mkgmap:set_semi_connected_type=none - I'm just missing the overlays also being removed as explained to fully use it. I actually had not noticed that mkgmap:set_unconnected_type=none did not remove all the lines that I intended to be removed by it because I never properly checked it using a test file - and there are not many unconnected ways in real OSM data (while there are far more semi_connected lines/ways). Actually I think it should be semiconnected as we alo use unconnected and not un_connected (even though it is two words in proper spelling).
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Feix, again: There REALLY is no problem with continue or continue with_actions here and there never was. The function triggered by the tag just doesn't do what you expect. I try again to make clear how mkgmap:set_unconnected_type works: The code in mkgmap keeps routable lines separated from non-routable lines. Each line is based on a way that was processed by the style rules in the lines file. If the style adds e.g. 4 different lines for the same OSM way you have 4 line instances refering to the same OSM id, each may be routable or not. After (!) all OSM elements are processed by the style rules mkgmap computes the nodes which are shared by routable lines (or short roads). If a road is not connected to any other road (one with a different OSM id) and the tag mkgmap:set_unconnected_type=none is set this routable line is not added to the map. The line instance is removed. In r2599 this also triggered the removal of all non-routable lines for the same OSM way. This triggering was removed with r2707 so that now the overlay line is still added to the map. My understanding is that you want to control this triggering somehow and we have to think about a situation where the style adds e.g. 2 roads and one overlay line for the same OSM way and only one road has the tag mkgmap:set_unconnected_type=none. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Dienstag, 19. September 2017 09:29:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only oh yeah - I remember. The problem ist neither the old nor the current behaviour works correctly in comparison to other tags. I complained that it applies to all occurences - even though using continue (i only used a line like highway=abc {set mkgmap:set_unconnected_type=none} [0x?? road_class=? road_speed=? continue] ) I really think the best solution if strict sticking to rules without [] block, and respecting continue vs continue with_actions is not possible would be to have to different special tags - one removing also all non routable overlay lines, while the other tag does not. Back then I only used mkgmap_set_unconnected_type=none to remove unconnected roads that make autorouting go crazy (it's unconnected - someone starts a route there - and the route just breaks - mainly because people did not connect the road correctly - and it has nearly invisible gaps on both side - which Potlach v1 was a bit famous for) - now the use case is more to filter out clutter for the semi_connected so I rather want to have it also filter out all overlays. (I'm fine using continue with_actions as supposed). On 19 September 2017 at 08:16, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Well, I just noticed that mkgmap:set_unconnected_type is not yet documented. When I implemented it with r2599 I decided to remove all overlay lines if the road is unconnected and mkgmap:set_unconnected_type=none is used. Later, Steve changed this in r2707, the reason was that you complained about the old behaviour. Please read these old threads carefully: http://gis.19327.n8.nabble.com/Serious-mkgmap-Bug-set-unconnected-type-not-r... http://gis.19327.n8.nabble.com/Commit-r2707-Don-t-complete-remove-an-unconne... My understanding of these discussions is that we need is an option or tag that controls what to do with an overlay line when the underlying road was removed. Gerd Felix Hartmann-2 wrote
But does it mean semi_connected or unconnected? I would like to have both as option if possible.
On 18 September 2017 at 21:22, Gerd Petermann <
gpetermann_muenchen@
wrote:
Hi all,
what do you think about a tag named mkgmap:remove-if-no-road=yes ? I would add code to check all non-routable lines for this tag. If no routable line is found for the same OSM way the line is removed. This check is performed after the processing of the 2 mkgmap:set_xxx_type tags and maybe other routines which remove routable lines because they are too short etc.
Gerd
Felix Hartmann-2 wrote
3. I'm fine with another name - maybe mkgmap:set_semi_connected_ line=none and mkgmap:set_unconnected_line=none? Well I actually already went through my style and added mkgmap:set_semi_connected_type=none - I'm just missing the overlays also being removed as explained to fully use it. I actually had not noticed that mkgmap:set_unconnected_type=none did not remove all the lines that I intended to be removed by it because I never properly checked it using a test file - and there are not many unconnected ways in real OSM data (while there are far more semi_connected lines/ways). Actually I think it should be semiconnected as we alo use unconnected and not un_connected (even though it is two words in proper spelling).
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess). Before 2707 if I remember right all copies were removed no matter if you used continue, continue with_actions or no continue. On Sep 19, 2017 10:07 AM, "Gerd Petermann" <GPetermann_muenchen@hotmail.com> wrote:
Hi Feix, again: There REALLY is no problem with continue or continue with_actions here and there never was. The function triggered by the tag just doesn't do what you expect.
I try again to make clear how mkgmap:set_unconnected_type works: The code in mkgmap keeps routable lines separated from non-routable lines. Each line is based on a way that was processed by the style rules in the lines file. If the style adds e.g. 4 different lines for the same OSM way you have 4 line instances refering to the same OSM id, each may be routable or not. After (!) all OSM elements are processed by the style rules mkgmap computes the nodes which are shared by routable lines (or short roads). If a road is not connected to any other road (one with a different OSM id) and the tag mkgmap:set_unconnected_type=none is set this routable line is not added to the map. The line instance is removed. In r2599 this also triggered the removal of all non-routable lines for the same OSM way. This triggering was removed with r2707 so that now the overlay line is still added to the map.
My understanding is that you want to control this triggering somehow and we have to think about a situation where the style adds e.g. 2 roads and one overlay line for the same OSM way and only one road has the tag mkgmap:set_unconnected_type=none.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Dienstag, 19. September 2017 09:29:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
oh yeah - I remember.
The problem ist neither the old nor the current behaviour works correctly in comparison to other tags. I complained that it applies to all occurences - even though using continue (i only used a line like highway=abc {set mkgmap:set_unconnected_type=none} [0x?? road_class=? road_speed=? continue] )
I really think the best solution if strict sticking to rules without [] block, and respecting continue vs continue with_actions is not possible would be to have to different special tags - one removing also all non routable overlay lines, while the other tag does not. Back then I only used mkgmap_set_unconnected_type=none to remove unconnected roads that make autorouting go crazy (it's unconnected - someone starts a route there - and the route just breaks - mainly because people did not connect the road correctly - and it has nearly invisible gaps on both side - which Potlach v1 was a bit famous for) - now the use case is more to filter out clutter for the semi_connected so I rather want to have it also filter out all overlays. (I'm fine using continue with_actions as supposed).
On 19 September 2017 at 08:16, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Well, I just noticed that mkgmap:set_unconnected_type is not yet documented. When I implemented it with r2599 I decided to remove all overlay lines if the road is unconnected and mkgmap:set_unconnected_type=none is used. Later, Steve changed this in r2707, the reason was that you complained about the old behaviour. Please read these old threads carefully: http://gis.19327.n8.nabble.com/Serious-mkgmap-Bug-set- unconnected-type-not-respecting-continue-command-tp5775051.html http://gis.19327.n8.nabble.com/Commit-r2707-Don-t-complete-remove-an- unconnected-road-tp5777740.html
My understanding of these discussions is that we need is an option or tag that controls what to do with an overlay line when the underlying road was removed.
Gerd
Felix Hartmann-2 wrote
But does it mean semi_connected or unconnected? I would like to have both as option if possible.
On 18 September 2017 at 21:22, Gerd Petermann <
gpetermann_muenchen@
wrote:
Hi all,
what do you think about a tag named mkgmap:remove-if-no-road=yes ? I would add code to check all non-routable lines for this tag. If no routable line is found for the same OSM way the line is removed. This check is performed after the processing of the 2 mkgmap:set_xxx_type tags and maybe other routines which remove routable lines because they are too short etc.
Gerd
Felix Hartmann-2 wrote
3. I'm fine with another name - maybe mkgmap:set_semi_connected_ line=none and mkgmap:set_unconnected_line=none? Well I actually already went through my style and added mkgmap:set_semi_connected_type=none - I'm just missing the overlays also being removed as explained to fully use it. I actually had not noticed that mkgmap:set_unconnected_type=none did not remove all the lines that I intended to be removed by it because I never properly checked it using a test file - and there are not many unconnected ways in real OSM data (while there are far more semi_connected lines/ways). Actually I think it should be semiconnected as we alo use unconnected and not un_connected (even though it is two words in proper spelling).
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not. Gerd -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
That sounds good On Sep 19, 2017 11:23 AM, "Gerd Petermann" <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not.
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
Attached is v2 of the patch. It implements the removal of overlay lines when mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was found. I am still not sure what should be done if the tag has a value that gives another type instead of none. Assume your style uses highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] What would you expect for a semi connected way? We have 2 lines, the first is changed from 0x07 to 0x10806. It would not make much sense to change also the 2nd from 0x10106 to 0x10806. So, for now only the value none has an effect for the overlay line(s). semi_con-v2.patch <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch> Gerd Felix Hartmann-2 wrote
That sounds good
On Sep 19, 2017 11:23 AM, "Gerd Petermann" <
gpetermann_muenchen@
> wrote:
Hi Felix,
Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not.
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
Somthing seems to be wrong with the patch: java.lang.NullPointerException at uk.me.parabola.mkgmap.osmstyle.StyledConverter.findUnconnectedRoads(StyledConverter.java:1970) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:605) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:243) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:157) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could Not Find C:\OpenMTBMap\maps\ovm_6431*.img On 19 September 2017 at 15:53, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Attached is v2 of the patch. It implements the removal of overlay lines when mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was found.
I am still not sure what should be done if the tag has a value that gives another type instead of none. Assume your style uses highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
What would you expect for a semi connected way? We have 2 lines, the first is changed from 0x07 to 0x10806. It would not make much sense to change also the 2nd from 0x10106 to 0x10806. So, for now only the value none has an effect for the overlay line(s).
semi_con-v2.patch <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch>
Gerd
Felix Hartmann-2 wrote
That sounds good
On Sep 19, 2017 11:23 AM, "Gerd Petermann" <
gpetermann_muenchen@
wrote:
Hi Felix,
Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not.
-- 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
As for your example - yes I guess only changing first occurence to 0x* - further occurences to none makes most sense. In general I think such a rule should not be used. So good practice would be either: highway=service & service=driveway {set mkgmap:set_semi_connected_type=none} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service & oneway=yes [0x10106 resolution 24] but not your example and also not: highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue with_actions] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] On 21 September 2017 at 11:10, Felix Hartmann <extremecarver@gmail.com> wrote:
Somthing seems to be wrong with the patch:
java.lang.NullPointerException at uk.me.parabola.mkgmap.osmstyle.StyledConverter. findUnconnectedRoads(StyledConverter.java:1970) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end( StyledConverter.java:605) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert( ElementSaver.java:243) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load( OsmMapDataSource.java:157) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile( MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could Not Find C:\OpenMTBMap\maps\ovm_6431*.img
On 19 September 2017 at 15:53, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Attached is v2 of the patch. It implements the removal of overlay lines when mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was found.
I am still not sure what should be done if the tag has a value that gives another type instead of none. Assume your style uses highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
What would you expect for a semi connected way? We have 2 lines, the first is changed from 0x07 to 0x10806. It would not make much sense to change also the 2nd from 0x10106 to 0x10806. So, for now only the value none has an effect for the overlay line(s).
semi_con-v2.patch <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch>
Gerd
Felix Hartmann-2 wrote
That sounds good
On Sep 19, 2017 11:23 AM, "Gerd Petermann" <
gpetermann_muenchen@
wrote:
Hi Felix,
Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not.
-- 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, sorry, did not search for a solution for my example, what I wanted to point out is that the algo may produce unexpected results whenever the style adds multiple lines for one way with conflicting mkgmap:set_semi_connected_type values. In your style you can probably only use value "none". I wonder if anybody uses the variant with a value that gives a different type. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 21. September 2017 11:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only As for your example - yes I guess only changing first occurence to 0x* - further occurences to none makes most sense. In general I think such a rule should not be used. So good practice would be either: highway=service & service=driveway {set mkgmap:set_semi_connected_type=none} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service & oneway=yes [0x10106 resolution 24] but not your example and also not: highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue with_actions] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] On 21 September 2017 at 11:10, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: Somthing seems to be wrong with the patch: java.lang.NullPointerException at uk.me.parabola.mkgmap.osmstyle.StyledConverter.findUnconnectedRoads(StyledConverter.java:1970) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:605) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:243) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:157) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could Not Find C:\OpenMTBMap\maps\ovm_6431*.img On 19 September 2017 at 15:53, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Attached is v2 of the patch. It implements the removal of overlay lines when mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was found. I am still not sure what should be done if the tag has a value that gives another type instead of none. Assume your style uses highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] What would you expect for a semi connected way? We have 2 lines, the first is changed from 0x07 to 0x10806. It would not make much sense to change also the 2nd from 0x10106 to 0x10806. So, for now only the value none has an effect for the overlay line(s). semi_con-v2.patch <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch> Gerd Felix Hartmann-2 wrote
That sounds good
On Sep 19, 2017 11:23 AM, "Gerd Petermann" <
gpetermann_muenchen@
wrote:
Hi Felix,
Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not.
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Thanks for v3 - on a quick tryrout it works well now. I have not found time (and won't until Tuesday next week) to give it a full check. (and yes - I'm right now only using "none"). On 21 September 2017 at 11:56, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:
Hi Felix,
sorry, did not search for a solution for my example, what I wanted to point out is that the algo may produce unexpected results whenever the style adds multiple lines for one way with conflicting mkgmap:set_semi_connected_type values.
In your style you can probably only use value "none". I wonder if anybody uses the variant with a value that gives a different type.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 21. September 2017 11:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
As for your example - yes I guess only changing first occurence to 0x* - further occurences to none makes most sense. In general I think such a rule should not be used.
So good practice would be either: highway=service & service=driveway {set mkgmap:set_semi_connected_type=none} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service & oneway=yes [0x10106 resolution 24]
but not your example and also not: highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue with_actions] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
On 21 September 2017 at 11:10, Felix Hartmann <extremecarver@gmail.com< mailto:extremecarver@gmail.com>> wrote: Somthing seems to be wrong with the patch:
java.lang.NullPointerException at uk.me.parabola.mkgmap.osmstyle.StyledConverter. findUnconnectedRoads(StyledConverter.java:1970) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end( StyledConverter.java:605) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert( ElementSaver.java:243) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load( OsmMapDataSource.java:157) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile( MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could Not Find C:\OpenMTBMap\maps\ovm_6431*.img
On 19 September 2017 at 15:53, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Attached is v2 of the patch. It implements the removal of overlay lines when mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was found.
I am still not sure what should be done if the tag has a value that gives another type instead of none. Assume your style uses highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
What would you expect for a semi connected way? We have 2 lines, the first is changed from 0x07 to 0x10806. It would not make much sense to change also the 2nd from 0x10106 to 0x10806. So, for now only the value none has an effect for the overlay line(s).
semi_con-v2.patch <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch>
Gerd
Felix Hartmann-2 wrote
That sounds good
On Sep 19, 2017 11:23 AM, "Gerd Petermann" <
gpetermann_muenchen@
wrote:
Hi Felix,
Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not.
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Could semi_con-v3.patch so the semi_connected tag be merged to trunk? It was compatible until now and is of really good use. Unfortunately - it conflicts with todays mkgmap update. Sorry I forgot to answer back in 2017 confirming that it worked splendidly. Felix On Thu, 21 Sep 2017 at 15:02, Felix Hartmann <extremecarver@gmail.com> wrote:
Thanks for v3 - on a quick tryrout it works well now. I have not found time (and won't until Tuesday next week) to give it a full check. (and yes - I'm right now only using "none").
On 21 September 2017 at 11:56, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:
Hi Felix,
sorry, did not search for a solution for my example, what I wanted to point out is that the algo may produce unexpected results whenever the style adds multiple lines for one way with conflicting mkgmap:set_semi_connected_type values.
In your style you can probably only use value "none". I wonder if anybody uses the variant with a value that gives a different type.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 21. September 2017 11:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
As for your example - yes I guess only changing first occurence to 0x* - further occurences to none makes most sense. In general I think such a rule should not be used.
So good practice would be either: highway=service & service=driveway {set mkgmap:set_semi_connected_type=none} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service & oneway=yes [0x10106 resolution 24]
but not your example and also not: highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue with_actions] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
On 21 September 2017 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: Somthing seems to be wrong with the patch:
java.lang.NullPointerException at uk.me.parabola.mkgmap.osmstyle.StyledConverter.findUnconnectedRoads(StyledConverter.java:1970) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:605) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:243) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:157) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could Not Find C:\OpenMTBMap\maps\ovm_6431*.img
On 19 September 2017 at 15:53, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Attached is v2 of the patch. It implements the removal of overlay lines when mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was found.
I am still not sure what should be done if the tag has a value that gives another type instead of none. Assume your style uses highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
What would you expect for a semi connected way? We have 2 lines, the first is changed from 0x07 to 0x10806. It would not make much sense to change also the 2nd from 0x10106 to 0x10806. So, for now only the value none has an effect for the overlay line(s).
semi_con-v2.patch <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch>
Gerd
Felix Hartmann-2 wrote
That sounds good
On Sep 19, 2017 11:23 AM, "Gerd Petermann" <
gpetermann_muenchen@
wrote:
Hi Felix,
Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not.
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, I already wondered where this code has gone. :o Hard to say if it is still useful. I probably would not want to use it in combination with option --housenumbers. I am able to modify the patch. Are there any other patches from me or others that you use? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Mittwoch, 13. November 2019 17:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Could semi_con-v3.patch so the semi_connected tag be merged to trunk? It was compatible until now and is of really good use. Unfortunately - it conflicts with todays mkgmap update. Sorry I forgot to answer back in 2017 confirming that it worked splendidly. Felix On Thu, 21 Sep 2017 at 15:02, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: Thanks for v3 - on a quick tryrout it works well now. I have not found time (and won't until Tuesday next week) to give it a full check. (and yes - I'm right now only using "none"). On 21 September 2017 at 11:56, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix, sorry, did not search for a solution for my example, what I wanted to point out is that the algo may produce unexpected results whenever the style adds multiple lines for one way with conflicting mkgmap:set_semi_connected_type values. In your style you can probably only use value "none". I wonder if anybody uses the variant with a value that gives a different type. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Donnerstag, 21. September 2017 11:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only As for your example - yes I guess only changing first occurence to 0x* - further occurences to none makes most sense. In general I think such a rule should not be used. So good practice would be either: highway=service & service=driveway {set mkgmap:set_semi_connected_type=none} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service & oneway=yes [0x10106 resolution 24] but not your example and also not: highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue with_actions] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] On 21 September 2017 at 11:10, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: Somthing seems to be wrong with the patch: java.lang.NullPointerException at uk.me.parabola.mkgmap.osmstyle.StyledConverter.findUnconnectedRoads(StyledConverter.java:1970) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:605) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:243) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:157) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could Not Find C:\OpenMTBMap\maps\ovm_6431*.img On 19 September 2017 at 15:53, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Attached is v2 of the patch. It implements the removal of overlay lines when mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was found. I am still not sure what should be done if the tag has a value that gives another type instead of none. Assume your style uses highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] What would you expect for a semi connected way? We have 2 lines, the first is changed from 0x07 to 0x10806. It would not make much sense to change also the 2nd from 0x10106 to 0x10806. So, for now only the value none has an effect for the overlay line(s). semi_con-v2.patch <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch> Gerd Felix Hartmann-2 wrote
That sounds good
On Sep 19, 2017 11:23 AM, "Gerd Petermann" <
gpetermann_muenchen@
wrote:
Hi Felix,
Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not.
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Gerd, Nope that's the only one. Until yesterday I think it worked correctly. I never really check again in the last 1 year however. And I do not use --housenumber option so far. It's very useful to filter out private ways which are not marked access=private - I mainly use it on highway=footway/path/track and so on (which should not have housenumbers anyhow). (well and what I hardly call a patch - + minSizePolygon = props.getProperty("min-size-polygon", 14); value 14 instead of 8. I think 8 is too small in src/uk/me/parabola/mkgmap/build/MapBuilder.java On Wed, 13 Nov 2019 at 19:00, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I already wondered where this code has gone. :o Hard to say if it is still useful. I probably would not want to use it in combination with option --housenumbers. I am able to modify the patch. Are there any other patches from me or others that you use?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Mittwoch, 13. November 2019 17:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
Could semi_con-v3.patch so the semi_connected tag be merged to trunk? It was compatible until now and is of really good use. Unfortunately - it conflicts with todays mkgmap update. Sorry I forgot to answer back in 2017 confirming that it worked splendidly.
Felix
On Thu, 21 Sep 2017 at 15:02, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: Thanks for v3 - on a quick tryrout it works well now. I have not found time (and won't until Tuesday next week) to give it a full check. (and yes - I'm right now only using "none").
On 21 September 2017 at 11:56, Gerd Petermann < GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> wrote: Hi Felix,
sorry, did not search for a solution for my example, what I wanted to point out is that the algo may produce unexpected results whenever the style adds multiple lines for one way with conflicting mkgmap:set_semi_connected_type values.
In your style you can probably only use value "none". I wonder if anybody uses the variant with a value that gives a different type.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Donnerstag, 21. September 2017 11:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only
As for your example - yes I guess only changing first occurence to 0x* - further occurences to none makes most sense. In general I think such a rule should not be used.
So good practice would be either: highway=service & service=driveway {set mkgmap:set_semi_connected_type=none} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service & oneway=yes [0x10106 resolution 24]
but not your example and also not: highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue with_actions] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
On 21 September 2017 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: Somthing seems to be wrong with the patch:
java.lang.NullPointerException at uk.me.parabola.mkgmap.osmstyle.StyledConverter.findUnconnectedRoads(StyledConverter.java:1970) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:605) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:243) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:157) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could Not Find C:\OpenMTBMap\maps\ovm_6431*.img
On 19 September 2017 at 15:53, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Attached is v2 of the patch. It implements the removal of overlay lines when mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was found.
I am still not sure what should be done if the tag has a value that gives another type instead of none. Assume your style uses highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24]
What would you expect for a semi connected way? We have 2 lines, the first is changed from 0x07 to 0x10806. It would not make much sense to change also the 2nd from 0x10106 to 0x10806. So, for now only the value none has an effect for the overlay line(s).
semi_con-v2.patch <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch>
Gerd
Felix Hartmann-2 wrote
That sounds good
On Sep 19, 2017 11:23 AM, "Gerd Petermann" <
gpetermann_muenchen@
wrote:
Hi Felix,
Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not.
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ 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
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Hi Felix, no idea why you would modify to code instead of using option --min-size-polygon=14, so I agree this is not important. I was surprised to find that there is no documentation about mkgmap:set_unconnected_type. I found a lot of confusing posts about the expected behaviour, so it's very difficult to guess what it really should do. With the additional tag mkgmap:set_semi_connected_type it get's even more complicated. Since you wrote that the patch worked well for you I think we should just document what it does. The patch was written before option --add-boundary-nodes-at-admin-boundaries was implemented. A road with a node on a tile boundary is not removed when mkgmap:set_unconnected_type=none (or mkgmap:set_semi_connected_type=none) is found. I think we can ignore nodes on country borders here (like we do with the dead-end-check. My understanding so far, please improve: The algorithm first finds out how often a road (one OSM way) is connected to other roads. If there are zero connections and mkgmap:set_unconnected_type=none is set, the way is removed (not written to the map). If there are other (overlaying) lines for the same OSM way and they also have mkgmap:set_unconnected_type=none they are also removed. Similar things happen with tag mkgmap:set_semi_connected_type=none for roads with exactly one connection to another road. There is also an option to specify a different type instead of none, e.g. mkgmap:set_unconnected_type=0x10804. This type must be a non-routable line type. The effect is that the line is not added as a road with the original type, instead it is added as normal line with the fiven type when the road is not connected to other roads. Similar with mkgmap:set_semi_connected_type=0x10804. The current patch doesn't care about overlay lines when a replacement type is given for the road, means, they are neither removed nor changed. Looks wrong to me. If I got that right you only use tag values "none" and nobody else uses this feature, so I'd prefer to remove the type change. In that case it would be better to also rename the tags, e.g. mkgmap:remove-unconnected=true and mkgmap:remove_semi_connected=true Any thoughts? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Mittwoch, 13. November 2019 19:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Gerd, Nope that's the only one. Until yesterday I think it worked correctly. I never really check again in the last 1 year however. And I do not use --housenumber option so far. It's very useful to filter out private ways which are not marked access=private - I mainly use it on highway=footway/path/track and so on (which should not have housenumbers anyhow). (well and what I hardly call a patch - + minSizePolygon = props.getProperty("min-size-polygon", 14); value 14 instead of 8. I think 8 is too small in src/uk/me/parabola/mkgmap/build/MapBuilder.java On Wed, 13 Nov 2019 at 19:00, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I already wondered where this code has gone. :o Hard to say if it is still useful. I probably would not want to use it in combination with option --housenumbers. I am able to modify the patch. Are there any other patches from me or others that you use? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Mittwoch, 13. November 2019 17:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Could semi_con-v3.patch so the semi_connected tag be merged to trunk? It was compatible until now and is of really good use. Unfortunately - it conflicts with todays mkgmap update. Sorry I forgot to answer back in 2017 confirming that it worked splendidly. Felix On Thu, 21 Sep 2017 at 15:02, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: Thanks for v3 - on a quick tryrout it works well now. I have not found time (and won't until Tuesday next week) to give it a full check. (and yes - I'm right now only using "none"). On 21 September 2017 at 11:56, Gerd Petermann <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>>> wrote: Hi Felix, sorry, did not search for a solution for my example, what I wanted to point out is that the algo may produce unexpected results whenever the style adds multiple lines for one way with conflicting mkgmap:set_semi_connected_type values. In your style you can probably only use value "none". I wonder if anybody uses the variant with a value that gives a different type. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Donnerstag, 21. September 2017 11:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only As for your example - yes I guess only changing first occurence to 0x* - further occurences to none makes most sense. In general I think such a rule should not be used. So good practice would be either: highway=service & service=driveway {set mkgmap:set_semi_connected_type=none} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] or highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service & oneway=yes [0x10106 resolution 24] but not your example and also not: highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2 resolution 22 continue with_actions] highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] On 21 September 2017 at 11:10, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: Somthing seems to be wrong with the patch: java.lang.NullPointerException at uk.me.parabola.mkgmap.osmstyle.StyledConverter.findUnconnectedRoads(StyledConverter.java:1970) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:605) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:243) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:157) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could Not Find C:\OpenMTBMap\maps\ovm_6431*.img On 19 September 2017 at 15:53, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Attached is v2 of the patch. It implements the removal of overlay lines when mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was found. I am still not sure what should be done if the tag has a value that gives another type instead of none. Assume your style uses highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] What would you expect for a semi connected way? We have 2 lines, the first is changed from 0x07 to 0x10806. It would not make much sense to change also the 2nd from 0x10106 to 0x10806. So, for now only the value none has an effect for the overlay line(s). semi_con-v2.patch <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch> Gerd Felix Hartmann-2 wrote
That sounds good
On Sep 19, 2017 11:23 AM, "Gerd Petermann" <
gpetermann_muenchen@
wrote:
Hi Felix,
Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not.
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
Oops, forgot a null check. Here is v3. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Donnerstag, 21. September 2017 11:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Somthing seems to be wrong with the patch: java.lang.NullPointerException at uk.me.parabola.mkgmap.osmstyle.StyledConverter.findUnconnectedRoads(StyledConverter.java:1970) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:605) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:243) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:157) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could Not Find C:\OpenMTBMap\maps\ovm_6431*.img On 19 September 2017 at 15:53, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Attached is v2 of the patch. It implements the removal of overlay lines when mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was found. I am still not sure what should be done if the tag has a value that gives another type instead of none. Assume your style uses highway=service & service=driveway {set mkgmap:set_semi_connected_type=0x10806} highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue] highway=service & oneway=yes [0x10106 resolution 24] What would you expect for a semi connected way? We have 2 lines, the first is changed from 0x07 to 0x10806. It would not make much sense to change also the 2nd from 0x10106 to 0x10806. So, for now only the value none has an effect for the overlay line(s). semi_con-v2.patch <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch> Gerd Felix Hartmann-2 wrote
That sounds good
On Sep 19, 2017 11:23 AM, "Gerd Petermann" <
gpetermann_muenchen@
wrote:
Hi Felix,
Felix Hartmann-2 wrote
Well I would like it to apply to non routable lines too - if continue with_actions is used - basically just treat routable and non routable lines the same (the initial check should only look at routable lines though I guess).
OK, I think I can change the code so that it stores the information whether or not a road is connected (or "semi-connected") once for each OSM way that is at least added once as a road. In a further step mkgmap would check each line for the existence of the mkgmap:set_unconnected_type tag and check if the corresponding OSM way is connected or not.
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ 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 -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
I would expect a driveway that also has public access as a footpath to be tagged highway=service + service=driveway + designation=public_footpath + foot=designated. Regards, Mike -----Original Message----- From: nwillink [mailto:osm@pinns.co.uk] Sent: 17 September 2017 16:34 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only Hi Gerd In the UK , frequently public footpaths are linked to someone's driveway - I have to say it's often quite 'daunting' to walk up someone's drive in order to continue along a public footpath. r Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
participants (5)
-
Felix Hartmann -
Gerd Petermann -
Gerd Petermann
-
Mike Baggaley -
nwillink