Nearby poi feature
Hello, I'm struggling with the nearby poi rules. As far as I understand from the manual there are 3 options named: triggered if the type code and the name is the same unnamed: triggered if the type code is the same and the name is empty no specification: triggered if the type code is the same regardless of the name being the same But if I use 0x3002:10 on a docters clinic with 9 doctors all having different names, obvious closer together then 10 meters nothing happens When adding multiple rules for the same typ-code I get a SEVERE error message (which is correct and proofs the correct nearby - config-rules - file is in use) When hiding trees next to the doctors (just to be sure the correct code is triggered) the unnamed trees are hidden as expected When rendering the doctors as typ-code trees, again nothing happens. So it's not in the the typ-code used and I can only assume that I just can't hide poi's when the name is different? Maybe somebody could help explain what can be expected If interested in the test area: https://www.openstreetmap.org/#map=19/49.75947/6.64167 https://www.openstreetmap.org/#map=19/49.75841/6.64698 Kind regards, Joris
Hi Joris, The current code always groups the POI by type AND name. What result would you expect for the different doctors? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 11:46 An: Development list for mkgmap Betreff: [mkgmap-dev] Nearby poi feature Hello, I’m struggling with the nearby poi rules. As far as I understand from the manual there are 3 options named: triggered if the type code and the name is the same unnamed: triggered if the type code is the same and the name is empty no specification: triggered if the type code is the same regardless of the name being the same But if I use 0x3002:10 on a docters clinic with 9 doctors all having different names, obvious closer together then 10 meters nothing happens When adding multiple rules for the same typ-code I get a SEVERE error message (which is correct and proofs the correct nearby - config-rules - file is in use) When hiding trees next to the doctors (just to be sure the correct code is triggered) the unnamed trees are hidden as expected When rendering the doctors as typ-code trees, again nothing happens. So it’s not in the the typ-code used and I can only assume that I just can’t hide poi’s when the name is different? Maybe somebody could help explain what can be expected If interested in the test area: https://www.openstreetmap.org/#map=19/49.75947/6.64167 https://www.openstreetmap.org/#map=19/49.75841/6.64698 Kind regards, Joris
Hi Gerd, I tried to unclutter the bunge of symbols by just hiding a couple of them allowing other poi's and lables to come through and be displayed in stead of 'pushed away' by a clutter of the same symbols. That works perfect for bins, benches, parkings , silo's etc. because they rarely have names. So its not directly related to the "doctors office". My eye fell on them as an example because I expected them to be filtered out. It's no big deal, just would be nice. It is because the manual really gave me the idea that it works that way that I spent time on it. Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:08 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, The current code always groups the POI by type AND name. What result would you expect for the different doctors? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 11:46 An: Development list for mkgmap Betreff: [mkgmap-dev] Nearby poi feature Hello, I'm struggling with the nearby poi rules. As far as I understand from the manual there are 3 options named: triggered if the type code and the name is the same unnamed: triggered if the type code is the same and the name is empty no specification: triggered if the type code is the same regardless of the name being the same But if I use 0x3002:10 on a docters clinic with 9 doctors all having different names, obvious closer together then 10 meters nothing happens When adding multiple rules for the same typ-code I get a SEVERE error message (which is correct and proofs the correct nearby - config-rules - file is in use) When hiding trees next to the doctors (just to be sure the correct code is triggered) the unnamed trees are hidden as expected When rendering the doctors as typ-code trees, again nothing happens. So it's not in the the typ-code used and I can only assume that I just can't hide poi's when the name is different? Maybe somebody could help explain what can be expected If interested in the test area: https://www.openstreetmap.org/#map=19/49.75947/6.64167 https://www.openstreetmap.org/#map=19/49.75841/6.64698 Kind regards, Joris _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Joris, again, what would be the result? Remember that a POI is more than just the icon on the map. Besides the name I may have an address, a phone number and so on. If we replace them by a single POI, what would be the content of those fields? Thinking of it the code should probably be changed to compare those fields as well and to prefer the one that has more information. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 12:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, I tried to unclutter the bunge of symbols by just hiding a couple of them allowing other poi's and lables to come through and be displayed in stead of 'pushed away' by a clutter of the same symbols. That works perfect for bins, benches, parkings , silo's etc. because they rarely have names. So its not directly related to the "doctors office". My eye fell on them as an example because I expected them to be filtered out. It's no big deal, just would be nice. It is because the manual really gave me the idea that it works that way that I spent time on it. Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:08 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, The current code always groups the POI by type AND name. What result would you expect for the different doctors? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 11:46 An: Development list for mkgmap Betreff: [mkgmap-dev] Nearby poi feature Hello, I'm struggling with the nearby poi rules. As far as I understand from the manual there are 3 options named: triggered if the type code and the name is the same unnamed: triggered if the type code is the same and the name is empty no specification: triggered if the type code is the same regardless of the name being the same But if I use 0x3002:10 on a docters clinic with 9 doctors all having different names, obvious closer together then 10 meters nothing happens When adding multiple rules for the same typ-code I get a SEVERE error message (which is correct and proofs the correct nearby - config-rules - file is in use) When hiding trees next to the doctors (just to be sure the correct code is triggered) the unnamed trees are hidden as expected When rendering the doctors as typ-code trees, again nothing happens. So it's not in the the typ-code used and I can only assume that I just can't hide poi's when the name is different? Maybe somebody could help explain what can be expected If interested in the test area: https://www.openstreetmap.org/#map=19/49.75947/6.64167 https://www.openstreetmap.org/#map=19/49.75841/6.64698 Kind regards, Joris _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, Thanks for your reply. I fully understand that there would be side affects or that it even could be 'impossible' because the way things are organised in he past. (Or because it just doesn't fit in what has been the philosophy for years). And so its no big deal either. Starting from a blank piece of paper I would say that mkgmap should render everything and the Garmin or Basecamp Gui should hide poi's and names as soon as it becomes too crowdy to keep the map readable. (In a way, this is already happening when the device decides to show street and text lables). Since there is no way of asking garmin to further improve their gui, the only way would be through a mechanism in mkgmap. I don't say you/we should, but a possibility could be to not really merge/remove pois with the nearby function but to just tag the ones that would normally apply to the filter. In the style rules you could use that to catch them and decide what to do. For example render them as transparent dot without a lable. Then they do end up in the poi index search etc, but visually they are gone. Second thought could be to just remove them because 'the mapmaker' has decided that it would improve his map and forget that there is pois and address data getting lost because of the filter. This already is the case where the mapmaker decided to render or not render certain elements from the osm.pbf sources and also applies to filters like --polygon-size-limits and --min-size-polygon where mkgmap decides to filter out things. Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:58 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, again, what would be the result? Remember that a POI is more than just the icon on the map. Besides the name I may have an address, a phone number and so on. If we replace them by a single POI, what would be the content of those fields? Thinking of it the code should probably be changed to compare those fields as well and to prefer the one that has more information. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 12:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, I tried to unclutter the bunge of symbols by just hiding a couple of them allowing other poi's and lables to come through and be displayed in stead of 'pushed away' by a clutter of the same symbols. That works perfect for bins, benches, parkings , silo's etc. because they rarely have names. So its not directly related to the "doctors office". My eye fell on them as an example because I expected them to be filtered out. It's no big deal, just would be nice. It is because the manual really gave me the idea that it works that way that I spent time on it. Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:08 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, The current code always groups the POI by type AND name. What result would you expect for the different doctors? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 11:46 An: Development list for mkgmap Betreff: [mkgmap-dev] Nearby poi feature Hello, I'm struggling with the nearby poi rules. As far as I understand from the manual there are 3 options named: triggered if the type code and the name is the same unnamed: triggered if the type code is the same and the name is empty no specification: triggered if the type code is the same regardless of the name being the same But if I use 0x3002:10 on a docters clinic with 9 doctors all having different names, obvious closer together then 10 meters nothing happens When adding multiple rules for the same typ-code I get a SEVERE error message (which is correct and proofs the correct nearby - config-rules - file is in use) When hiding trees next to the doctors (just to be sure the correct code is triggered) the unnamed trees are hidden as expected When rendering the doctors as typ-code trees, again nothing happens. So it's not in the the typ-code used and I can only assume that I just can't hide poi's when the name is different? Maybe somebody could help explain what can be expected If interested in the test area: https://www.openstreetmap.org/#map=19/49.75947/6.64167 https://www.openstreetmap.org/#map=19/49.75841/6.64698 Kind regards, Joris _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Joris, you still didn't say what you want instead of the multiple POI with different names. One POI with the same type but without name or other fields filled? Seems you concentrate on rendering, but named POIs also appear in the index. Think about the result when you search for doctors, or even more problematic, when you search for Doctor XYZ and it is not found. I think you have to use some kind of trick to have the complete information in the index, but only one icon in the map. Maybe create two POI for each Doctor, one that is rendered (without a name), another that is indexed and not rendered. Don't know if that is possible with the TYP file? The rendered one could be reduced to a single POI by the nearby poi feature. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 15:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, Thanks for your reply. I fully understand that there would be side affects or that it even could be 'impossible' because the way things are organised in he past. (Or because it just doesn't fit in what has been the philosophy for years). And so its no big deal either. Starting from a blank piece of paper I would say that mkgmap should render everything and the Garmin or Basecamp Gui should hide poi's and names as soon as it becomes too crowdy to keep the map readable. (In a way, this is already happening when the device decides to show street and text lables). Since there is no way of asking garmin to further improve their gui, the only way would be through a mechanism in mkgmap. I don't say you/we should, but a possibility could be to not really merge/remove pois with the nearby function but to just tag the ones that would normally apply to the filter. In the style rules you could use that to catch them and decide what to do. For example render them as transparent dot without a lable. Then they do end up in the poi index search etc, but visually they are gone. Second thought could be to just remove them because 'the mapmaker' has decided that it would improve his map and forget that there is pois and address data getting lost because of the filter. This already is the case where the mapmaker decided to render or not render certain elements from the osm.pbf sources and also applies to filters like --polygon-size-limits and --min-size-polygon where mkgmap decides to filter out things. Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:58 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, again, what would be the result? Remember that a POI is more than just the icon on the map. Besides the name I may have an address, a phone number and so on. If we replace them by a single POI, what would be the content of those fields? Thinking of it the code should probably be changed to compare those fields as well and to prefer the one that has more information. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 12:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, I tried to unclutter the bunge of symbols by just hiding a couple of them allowing other poi's and lables to come through and be displayed in stead of 'pushed away' by a clutter of the same symbols. That works perfect for bins, benches, parkings , silo's etc. because they rarely have names. So its not directly related to the "doctors office". My eye fell on them as an example because I expected them to be filtered out. It's no big deal, just would be nice. It is because the manual really gave me the idea that it works that way that I spent time on it. Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:08 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, The current code always groups the POI by type AND name. What result would you expect for the different doctors? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 11:46 An: Development list for mkgmap Betreff: [mkgmap-dev] Nearby poi feature Hello, I'm struggling with the nearby poi rules. As far as I understand from the manual there are 3 options named: triggered if the type code and the name is the same unnamed: triggered if the type code is the same and the name is empty no specification: triggered if the type code is the same regardless of the name being the same But if I use 0x3002:10 on a docters clinic with 9 doctors all having different names, obvious closer together then 10 meters nothing happens When adding multiple rules for the same typ-code I get a SEVERE error message (which is correct and proofs the correct nearby - config-rules - file is in use) When hiding trees next to the doctors (just to be sure the correct code is triggered) the unnamed trees are hidden as expected When rendering the doctors as typ-code trees, again nothing happens. So it's not in the the typ-code used and I can only assume that I just can't hide poi's when the name is different? Maybe somebody could help explain what can be expected If interested in the test area: https://www.openstreetmap.org/#map=19/49.75947/6.64167 https://www.openstreetmap.org/#map=19/49.75841/6.64698 Kind regards, Joris _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, Mmmm there is some noise, and I doubt if its worth clearing it out, so feel free to end the conversation anytime. At least, after reading your suggestions, now I think that you say that the code for finding the nearby poi is executed after the poi is processed in the points style file where I thought this was done before it is passed to the points style file? What I have in mind { what you want instead of the multiple POI with different names } Option 1) tag the second one with: <mkgmap:another_poi_of_same_type_found_within = 10 meters> (and then pass it to the points style rules) Option 2) remove this second one because already another one existed. This is done before the points file can see it and ignore the fact that this data is lost forever. The 'randomly' first poi was lucky to be the first and stays unaltered. As far is I can see now that also happens if the poi does not have a name at all. Kind regards, Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 15:25 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, you still didn't say what you want instead of the multiple POI with different names. One POI with the same type but without name or other fields filled? Seems you concentrate on rendering, but named POIs also appear in the index. Think about the result when you search for doctors, or even more problematic, when you search for Doctor XYZ and it is not found. I think you have to use some kind of trick to have the complete information in the index, but only one icon in the map. Maybe create two POI for each Doctor, one that is rendered (without a name), another that is indexed and not rendered. Don't know if that is possible with the TYP file? The rendered one could be reduced to a single POI by the nearby poi feature. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 15:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, Thanks for your reply. I fully understand that there would be side affects or that it even could be 'impossible' because the way things are organised in he past. (Or because it just doesn't fit in what has been the philosophy for years). And so its no big deal either. Starting from a blank piece of paper I would say that mkgmap should render everything and the Garmin or Basecamp Gui should hide poi's and names as soon as it becomes too crowdy to keep the map readable. (In a way, this is already happening when the device decides to show street and text lables). Since there is no way of asking garmin to further improve their gui, the only way would be through a mechanism in mkgmap. I don't say you/we should, but a possibility could be to not really merge/remove pois with the nearby function but to just tag the ones that would normally apply to the filter. In the style rules you could use that to catch them and decide what to do. For example render them as transparent dot without a lable. Then they do end up in the poi index search etc, but visually they are gone. Second thought could be to just remove them because 'the mapmaker' has decided that it would improve his map and forget that there is pois and address data getting lost because of the filter. This already is the case where the mapmaker decided to render or not render certain elements from the osm.pbf sources and also applies to filters like --polygon-size-limits and --min-size-polygon where mkgmap decides to filter out things. Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:58 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, again, what would be the result? Remember that a POI is more than just the icon on the map. Besides the name I may have an address, a phone number and so on. If we replace them by a single POI, what would be the content of those fields? Thinking of it the code should probably be changed to compare those fields as well and to prefer the one that has more information. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 12:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, I tried to unclutter the bunge of symbols by just hiding a couple of them allowing other poi's and lables to come through and be displayed in stead of 'pushed away' by a clutter of the same symbols. That works perfect for bins, benches, parkings , silo's etc. because they rarely have names. So its not directly related to the "doctors office". My eye fell on them as an example because I expected them to be filtered out. It's no big deal, just would be nice. It is because the manual really gave me the idea that it works that way that I spent time on it. Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:08 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, The current code always groups the POI by type AND name. What result would you expect for the different doctors? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 11:46 An: Development list for mkgmap Betreff: [mkgmap-dev] Nearby poi feature Hello, I'm struggling with the nearby poi rules. As far as I understand from the manual there are 3 options named: triggered if the type code and the name is the same unnamed: triggered if the type code is the same and the name is empty no specification: triggered if the type code is the same regardless of the name being the same But if I use 0x3002:10 on a docters clinic with 9 doctors all having different names, obvious closer together then 10 meters nothing happens When adding multiple rules for the same typ-code I get a SEVERE error message (which is correct and proofs the correct nearby - config-rules - file is in use) When hiding trees next to the doctors (just to be sure the correct code is triggered) the unnamed trees are hidden as expected When rendering the doctors as typ-code trees, again nothing happens. So it's not in the the typ-code used and I can only assume that I just can't hide poi's when the name is different? Maybe somebody could help explain what can be expected If interested in the test area: https://www.openstreetmap.org/#map=19/49.75947/6.64167 https://www.openstreetmap.org/#map=19/49.75841/6.64698 Kind regards, Joris _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Joris, ah, sure, the nearby POI rules are executed after the points file was processed. Isn't it obvious since you specify garmin types which are only known after the style was processed? I see no way to change that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 17:43 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, Mmmm there is some noise, and I doubt if its worth clearing it out, so feel free to end the conversation anytime. At least, after reading your suggestions, now I think that you say that the code for finding the nearby poi is executed after the poi is processed in the points style file where I thought this was done before it is passed to the points style file? What I have in mind { what you want instead of the multiple POI with different names } Option 1) tag the second one with: <mkgmap:another_poi_of_same_type_found_within = 10 meters> (and then pass it to the points style rules) Option 2) remove this second one because already another one existed. This is done before the points file can see it and ignore the fact that this data is lost forever. The 'randomly' first poi was lucky to be the first and stays unaltered. As far is I can see now that also happens if the poi does not have a name at all. Kind regards, Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 15:25 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, you still didn't say what you want instead of the multiple POI with different names. One POI with the same type but without name or other fields filled? Seems you concentrate on rendering, but named POIs also appear in the index. Think about the result when you search for doctors, or even more problematic, when you search for Doctor XYZ and it is not found. I think you have to use some kind of trick to have the complete information in the index, but only one icon in the map. Maybe create two POI for each Doctor, one that is rendered (without a name), another that is indexed and not rendered. Don't know if that is possible with the TYP file? The rendered one could be reduced to a single POI by the nearby poi feature. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 15:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, Thanks for your reply. I fully understand that there would be side affects or that it even could be 'impossible' because the way things are organised in he past. (Or because it just doesn't fit in what has been the philosophy for years). And so its no big deal either. Starting from a blank piece of paper I would say that mkgmap should render everything and the Garmin or Basecamp Gui should hide poi's and names as soon as it becomes too crowdy to keep the map readable. (In a way, this is already happening when the device decides to show street and text lables). Since there is no way of asking garmin to further improve their gui, the only way would be through a mechanism in mkgmap. I don't say you/we should, but a possibility could be to not really merge/remove pois with the nearby function but to just tag the ones that would normally apply to the filter. In the style rules you could use that to catch them and decide what to do. For example render them as transparent dot without a lable. Then they do end up in the poi index search etc, but visually they are gone. Second thought could be to just remove them because 'the mapmaker' has decided that it would improve his map and forget that there is pois and address data getting lost because of the filter. This already is the case where the mapmaker decided to render or not render certain elements from the osm.pbf sources and also applies to filters like --polygon-size-limits and --min-size-polygon where mkgmap decides to filter out things. Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:58 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, again, what would be the result? Remember that a POI is more than just the icon on the map. Besides the name I may have an address, a phone number and so on. If we replace them by a single POI, what would be the content of those fields? Thinking of it the code should probably be changed to compare those fields as well and to prefer the one that has more information. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 12:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, I tried to unclutter the bunge of symbols by just hiding a couple of them allowing other poi's and lables to come through and be displayed in stead of 'pushed away' by a clutter of the same symbols. That works perfect for bins, benches, parkings , silo's etc. because they rarely have names. So its not directly related to the "doctors office". My eye fell on them as an example because I expected them to be filtered out. It's no big deal, just would be nice. It is because the manual really gave me the idea that it works that way that I spent time on it. Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:08 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, The current code always groups the POI by type AND name. What result would you expect for the different doctors? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 11:46 An: Development list for mkgmap Betreff: [mkgmap-dev] Nearby poi feature Hello, I'm struggling with the nearby poi rules. As far as I understand from the manual there are 3 options named: triggered if the type code and the name is the same unnamed: triggered if the type code is the same and the name is empty no specification: triggered if the type code is the same regardless of the name being the same But if I use 0x3002:10 on a docters clinic with 9 doctors all having different names, obvious closer together then 10 meters nothing happens When adding multiple rules for the same typ-code I get a SEVERE error message (which is correct and proofs the correct nearby - config-rules - file is in use) When hiding trees next to the doctors (just to be sure the correct code is triggered) the unnamed trees are hidden as expected When rendering the doctors as typ-code trees, again nothing happens. So it's not in the the typ-code used and I can only assume that I just can't hide poi's when the name is different? Maybe somebody could help explain what can be expected If interested in the test area: https://www.openstreetmap.org/#map=19/49.75947/6.64167 https://www.openstreetmap.org/#map=19/49.75841/6.64698 Kind regards, Joris _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Joris, BTW: I am still waiting for a final feedback reg. the patch poi-tagged-v3.patch (mkgmap:from-node:). Not sure what version you use, the patch was not committed yet. My last post to this thread was http://gis.19327.n8.nabble.com/is-in-function-for-point-on-line-tp5967043p59... Due to the attached pictures the posts got stuck. I think Steve still has to give his OK before such a post to the list is forwarded. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 17:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Joris, ah, sure, the nearby POI rules are executed after the points file was processed. Isn't it obvious since you specify garmin types which are only known after the style was processed? I see no way to change that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 17:43 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, Mmmm there is some noise, and I doubt if its worth clearing it out, so feel free to end the conversation anytime. At least, after reading your suggestions, now I think that you say that the code for finding the nearby poi is executed after the poi is processed in the points style file where I thought this was done before it is passed to the points style file? What I have in mind { what you want instead of the multiple POI with different names } Option 1) tag the second one with: <mkgmap:another_poi_of_same_type_found_within = 10 meters> (and then pass it to the points style rules) Option 2) remove this second one because already another one existed. This is done before the points file can see it and ignore the fact that this data is lost forever. The 'randomly' first poi was lucky to be the first and stays unaltered. As far is I can see now that also happens if the poi does not have a name at all. Kind regards, Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 15:25 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, you still didn't say what you want instead of the multiple POI with different names. One POI with the same type but without name or other fields filled? Seems you concentrate on rendering, but named POIs also appear in the index. Think about the result when you search for doctors, or even more problematic, when you search for Doctor XYZ and it is not found. I think you have to use some kind of trick to have the complete information in the index, but only one icon in the map. Maybe create two POI for each Doctor, one that is rendered (without a name), another that is indexed and not rendered. Don't know if that is possible with the TYP file? The rendered one could be reduced to a single POI by the nearby poi feature. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 15:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, Thanks for your reply. I fully understand that there would be side affects or that it even could be 'impossible' because the way things are organised in he past. (Or because it just doesn't fit in what has been the philosophy for years). And so its no big deal either. Starting from a blank piece of paper I would say that mkgmap should render everything and the Garmin or Basecamp Gui should hide poi's and names as soon as it becomes too crowdy to keep the map readable. (In a way, this is already happening when the device decides to show street and text lables). Since there is no way of asking garmin to further improve their gui, the only way would be through a mechanism in mkgmap. I don't say you/we should, but a possibility could be to not really merge/remove pois with the nearby function but to just tag the ones that would normally apply to the filter. In the style rules you could use that to catch them and decide what to do. For example render them as transparent dot without a lable. Then they do end up in the poi index search etc, but visually they are gone. Second thought could be to just remove them because 'the mapmaker' has decided that it would improve his map and forget that there is pois and address data getting lost because of the filter. This already is the case where the mapmaker decided to render or not render certain elements from the osm.pbf sources and also applies to filters like --polygon-size-limits and --min-size-polygon where mkgmap decides to filter out things. Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:58 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, again, what would be the result? Remember that a POI is more than just the icon on the map. Besides the name I may have an address, a phone number and so on. If we replace them by a single POI, what would be the content of those fields? Thinking of it the code should probably be changed to compare those fields as well and to prefer the one that has more information. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 12:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, I tried to unclutter the bunge of symbols by just hiding a couple of them allowing other poi's and lables to come through and be displayed in stead of 'pushed away' by a clutter of the same symbols. That works perfect for bins, benches, parkings , silo's etc. because they rarely have names. So its not directly related to the "doctors office". My eye fell on them as an example because I expected them to be filtered out. It's no big deal, just would be nice. It is because the manual really gave me the idea that it works that way that I spent time on it. Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:08 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, The current code always groups the POI by type AND name. What result would you expect for the different doctors? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 11:46 An: Development list for mkgmap Betreff: [mkgmap-dev] Nearby poi feature Hello, I'm struggling with the nearby poi rules. As far as I understand from the manual there are 3 options named: triggered if the type code and the name is the same unnamed: triggered if the type code is the same and the name is empty no specification: triggered if the type code is the same regardless of the name being the same But if I use 0x3002:10 on a docters clinic with 9 doctors all having different names, obvious closer together then 10 meters nothing happens When adding multiple rules for the same typ-code I get a SEVERE error message (which is correct and proofs the correct nearby - config-rules - file is in use) When hiding trees next to the doctors (just to be sure the correct code is triggered) the unnamed trees are hidden as expected When rendering the doctors as typ-code trees, again nothing happens. So it's not in the the typ-code used and I can only assume that I just can't hide poi's when the name is different? Maybe somebody could help explain what can be expected If interested in the test area: https://www.openstreetmap.org/#map=19/49.75947/6.64167 https://www.openstreetmap.org/#map=19/49.75841/6.64698 Kind regards, Joris _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Sorry, I did not know that. I did used it very intensily to get access tags to barriers linked to highways. It works as assumed to 'catch' the poi's and use them. I made some 'unittests' based on the values and also they work fine as well. So I think it's a go. Nevertheless my initial goal of applying the access tags to barriers did not work for now. Because there are two poi's passing by, the original osm node stil gets access = no The access I set to the poi derived from the line based on the from-node code is ignored by basecamp routing. I can only tell the routing mechanism to use the barrier if I set access = yes on the original osm node. I stopped further testing because of my lack of indept mkgmap logic and the many changes I had to make to my style. Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: vrijdag 19 juni 2020 10:37 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, BTW: I am still waiting for a final feedback reg. the patch poi-tagged-v3.patch (mkgmap:from-node:). Not sure what version you use, the patch was not committed yet. My last post to this thread was http://gis.19327.n8.nabble.com/is-in-function-for-point-on-line-tp5967043p59... Due to the attached pictures the posts got stuck. I think Steve still has to give his OK before such a post to the list is forwarded. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 17:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Joris, ah, sure, the nearby POI rules are executed after the points file was processed. Isn't it obvious since you specify garmin types which are only known after the style was processed? I see no way to change that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 17:43 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, Mmmm there is some noise, and I doubt if its worth clearing it out, so feel free to end the conversation anytime. At least, after reading your suggestions, now I think that you say that the code for finding the nearby poi is executed after the poi is processed in the points style file where I thought this was done before it is passed to the points style file? What I have in mind { what you want instead of the multiple POI with different names } Option 1) tag the second one with: <mkgmap:another_poi_of_same_type_found_within = 10 meters> (and then pass it to the points style rules) Option 2) remove this second one because already another one existed. This is done before the points file can see it and ignore the fact that this data is lost forever. The 'randomly' first poi was lucky to be the first and stays unaltered. As far is I can see now that also happens if the poi does not have a name at all. Kind regards, Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 15:25 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, you still didn't say what you want instead of the multiple POI with different names. One POI with the same type but without name or other fields filled? Seems you concentrate on rendering, but named POIs also appear in the index. Think about the result when you search for doctors, or even more problematic, when you search for Doctor XYZ and it is not found. I think you have to use some kind of trick to have the complete information in the index, but only one icon in the map. Maybe create two POI for each Doctor, one that is rendered (without a name), another that is indexed and not rendered. Don't know if that is possible with the TYP file? The rendered one could be reduced to a single POI by the nearby poi feature. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 15:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, Thanks for your reply. I fully understand that there would be side affects or that it even could be 'impossible' because the way things are organised in he past. (Or because it just doesn't fit in what has been the philosophy for years). And so its no big deal either. Starting from a blank piece of paper I would say that mkgmap should render everything and the Garmin or Basecamp Gui should hide poi's and names as soon as it becomes too crowdy to keep the map readable. (In a way, this is already happening when the device decides to show street and text lables). Since there is no way of asking garmin to further improve their gui, the only way would be through a mechanism in mkgmap. I don't say you/we should, but a possibility could be to not really merge/remove pois with the nearby function but to just tag the ones that would normally apply to the filter. In the style rules you could use that to catch them and decide what to do. For example render them as transparent dot without a lable. Then they do end up in the poi index search etc, but visually they are gone. Second thought could be to just remove them because 'the mapmaker' has decided that it would improve his map and forget that there is pois and address data getting lost because of the filter. This already is the case where the mapmaker decided to render or not render certain elements from the osm.pbf sources and also applies to filters like --polygon-size-limits and --min-size-polygon where mkgmap decides to filter out things. Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:58 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, again, what would be the result? Remember that a POI is more than just the icon on the map. Besides the name I may have an address, a phone number and so on. If we replace them by a single POI, what would be the content of those fields? Thinking of it the code should probably be changed to compare those fields as well and to prefer the one that has more information. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 12:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, I tried to unclutter the bunge of symbols by just hiding a couple of them allowing other poi's and lables to come through and be displayed in stead of 'pushed away' by a clutter of the same symbols. That works perfect for bins, benches, parkings , silo's etc. because they rarely have names. So its not directly related to the "doctors office". My eye fell on them as an example because I expected them to be filtered out. It's no big deal, just would be nice. It is because the manual really gave me the idea that it works that way that I spent time on it. Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:08 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, The current code always groups the POI by type AND name. What result would you expect for the different doctors? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 11:46 An: Development list for mkgmap Betreff: [mkgmap-dev] Nearby poi feature Hello, I'm struggling with the nearby poi rules. As far as I understand from the manual there are 3 options named: triggered if the type code and the name is the same unnamed: triggered if the type code is the same and the name is empty no specification: triggered if the type code is the same regardless of the name being the same But if I use 0x3002:10 on a docters clinic with 9 doctors all having different names, obvious closer together then 10 meters nothing happens When adding multiple rules for the same typ-code I get a SEVERE error message (which is correct and proofs the correct nearby - config-rules - file is in use) When hiding trees next to the doctors (just to be sure the correct code is triggered) the unnamed trees are hidden as expected When rendering the doctors as typ-code trees, again nothing happens. So it's not in the the typ-code used and I can only assume that I just can't hide poi's when the name is different? Maybe somebody could help explain what can be expected If interested in the test area: https://www.openstreetmap.org/#map=19/49.75947/6.64167 https://www.openstreetmap.org/#map=19/49.75841/6.64698 Kind regards, Joris _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Joris, yes, the --link-pois-to-ways feature can be quite confusing, esp. in combination with --add-pois-to-lines. The original barrier node is used by the --link-pois-to-ways feature to possibly create a route restriction (after the style rules were applied to both the barrier node and the way). The POIs which are generated by the --add-pois-to-x feature do not have any influence on routing. I think you get the best results when you don't change the access tag for the barrier node. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Freitag, 19. Juni 2020 11:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd Sorry, I did not know that. I did used it very intensily to get access tags to barriers linked to highways. It works as assumed to 'catch' the poi's and use them. I made some 'unittests' based on the values and also they work fine as well. So I think it's a go. Nevertheless my initial goal of applying the access tags to barriers did not work for now. Because there are two poi's passing by, the original osm node stil gets access = no The access I set to the poi derived from the line based on the from-node code is ignored by basecamp routing. I can only tell the routing mechanism to use the barrier if I set access = yes on the original osm node. I stopped further testing because of my lack of indept mkgmap logic and the many changes I had to make to my style. Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: vrijdag 19 juni 2020 10:37 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, BTW: I am still waiting for a final feedback reg. the patch poi-tagged-v3.patch (mkgmap:from-node:). Not sure what version you use, the patch was not committed yet. My last post to this thread was http://gis.19327.n8.nabble.com/is-in-function-for-point-on-line-tp5967043p59... Due to the attached pictures the posts got stuck. I think Steve still has to give his OK before such a post to the list is forwarded. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 17:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Joris, ah, sure, the nearby POI rules are executed after the points file was processed. Isn't it obvious since you specify garmin types which are only known after the style was processed? I see no way to change that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 17:43 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, Mmmm there is some noise, and I doubt if its worth clearing it out, so feel free to end the conversation anytime. At least, after reading your suggestions, now I think that you say that the code for finding the nearby poi is executed after the poi is processed in the points style file where I thought this was done before it is passed to the points style file? What I have in mind { what you want instead of the multiple POI with different names } Option 1) tag the second one with: <mkgmap:another_poi_of_same_type_found_within = 10 meters> (and then pass it to the points style rules) Option 2) remove this second one because already another one existed. This is done before the points file can see it and ignore the fact that this data is lost forever. The 'randomly' first poi was lucky to be the first and stays unaltered. As far is I can see now that also happens if the poi does not have a name at all. Kind regards, Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 15:25 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, you still didn't say what you want instead of the multiple POI with different names. One POI with the same type but without name or other fields filled? Seems you concentrate on rendering, but named POIs also appear in the index. Think about the result when you search for doctors, or even more problematic, when you search for Doctor XYZ and it is not found. I think you have to use some kind of trick to have the complete information in the index, but only one icon in the map. Maybe create two POI for each Doctor, one that is rendered (without a name), another that is indexed and not rendered. Don't know if that is possible with the TYP file? The rendered one could be reduced to a single POI by the nearby poi feature. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 15:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, Thanks for your reply. I fully understand that there would be side affects or that it even could be 'impossible' because the way things are organised in he past. (Or because it just doesn't fit in what has been the philosophy for years). And so its no big deal either. Starting from a blank piece of paper I would say that mkgmap should render everything and the Garmin or Basecamp Gui should hide poi's and names as soon as it becomes too crowdy to keep the map readable. (In a way, this is already happening when the device decides to show street and text lables). Since there is no way of asking garmin to further improve their gui, the only way would be through a mechanism in mkgmap. I don't say you/we should, but a possibility could be to not really merge/remove pois with the nearby function but to just tag the ones that would normally apply to the filter. In the style rules you could use that to catch them and decide what to do. For example render them as transparent dot without a lable. Then they do end up in the poi index search etc, but visually they are gone. Second thought could be to just remove them because 'the mapmaker' has decided that it would improve his map and forget that there is pois and address data getting lost because of the filter. This already is the case where the mapmaker decided to render or not render certain elements from the osm.pbf sources and also applies to filters like --polygon-size-limits and --min-size-polygon where mkgmap decides to filter out things. Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:58 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, again, what would be the result? Remember that a POI is more than just the icon on the map. Besides the name I may have an address, a phone number and so on. If we replace them by a single POI, what would be the content of those fields? Thinking of it the code should probably be changed to compare those fields as well and to prefer the one that has more information. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 12:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Hi Gerd, I tried to unclutter the bunge of symbols by just hiding a couple of them allowing other poi's and lables to come through and be displayed in stead of 'pushed away' by a clutter of the same symbols. That works perfect for bins, benches, parkings , silo's etc. because they rarely have names. So its not directly related to the "doctors office". My eye fell on them as an example because I expected them to be filtered out. It's no big deal, just would be nice. It is because the manual really gave me the idea that it works that way that I spent time on it. Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 18 juni 2020 12:08 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, The current code always groups the POI by type AND name. What result would you expect for the different doctors? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 18. Juni 2020 11:46 An: Development list for mkgmap Betreff: [mkgmap-dev] Nearby poi feature Hello, I'm struggling with the nearby poi rules. As far as I understand from the manual there are 3 options named: triggered if the type code and the name is the same unnamed: triggered if the type code is the same and the name is empty no specification: triggered if the type code is the same regardless of the name being the same But if I use 0x3002:10 on a docters clinic with 9 doctors all having different names, obvious closer together then 10 meters nothing happens When adding multiple rules for the same typ-code I get a SEVERE error message (which is correct and proofs the correct nearby - config-rules - file is in use) When hiding trees next to the doctors (just to be sure the correct code is triggered) the unnamed trees are hidden as expected When rendering the doctors as typ-code trees, again nothing happens. So it's not in the the typ-code used and I can only assume that I just can't hide poi's when the name is different? Maybe somebody could help explain what can be expected If interested in the test area: https://www.openstreetmap.org/#map=19/49.75947/6.64167 https://www.openstreetmap.org/#map=19/49.75841/6.64698 Kind regards, Joris _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi I have this in my style: # stop routing on service roads (esp. service=parking_aisle) if there might be a gate highway=service & mkgmap:way-has-pois=true {add access=destination} It isn't foolproof. Elsewhere (in points) I don't make any assumptions about a barrier=gate... restricting access over what the access= tag specfies. Ticker On Fri, 2020-06-19 at 10:13 +0000, Gerd Petermann wrote:
Hi Joris,
yes, the --link-pois-to-ways feature can be quite confusing, esp. in combination with --add-pois-to-lines. The original barrier node is used by the --link-pois-to-ways feature to possibly create a route restriction (after the style rules were applied to both the barrier node and the way). The POIs which are generated by the --add-pois-to-x feature do not have any influence on routing. I think you get the best results when you don't change the access tag for the barrier node.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Freitag, 19. Juni 2020 11:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature
Hi Gerd
Sorry, I did not know that. I did used it very intensily to get access tags to barriers linked to highways. It works as assumed to 'catch' the poi's and use them. I made some 'unittests' based on the values and also they work fine as well. So I think it's a go.
Nevertheless my initial goal of applying the access tags to barriers did not work for now. Because there are two poi's passing by, the original osm node stil gets access = no The access I set to the poi derived from the line based on the from -node code is ignored by basecamp routing. I can only tell the routing mechanism to use the barrier if I set access = yes on the original osm node. I stopped further testing because of my lack of indept mkgmap logic and the many changes I had to make to my style.
Kind regards Joris
Thnx for the tip Ticker -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Ticker Berkin Verzonden: vrijdag 19 juni 2020 14:01 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi I have this in my style: # stop routing on service roads (esp. service=parking_aisle) if there might be a gate highway=service & mkgmap:way-has-pois=true {add access=destination} It isn't foolproof. Elsewhere (in points) I don't make any assumptions about a barrier=gate... restricting access over what the access= tag specfies. Ticker On Fri, 2020-06-19 at 10:13 +0000, Gerd Petermann wrote:
Hi Joris,
yes, the --link-pois-to-ways feature can be quite confusing, esp. in combination with --add-pois-to-lines. The original barrier node is used by the --link-pois-to-ways feature to possibly create a route restriction (after the style rules were applied to both the barrier node and the way). The POIs which are generated by the --add-pois-to-x feature do not have any influence on routing. I think you get the best results when you don't change the access tag for the barrier node.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Freitag, 19. Juni 2020 11:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature
Hi Gerd
Sorry, I did not know that. I did used it very intensily to get access tags to barriers linked to highways. It works as assumed to 'catch' the poi's and use them. I made some 'unittests' based on the values and also they work fine as well. So I think it's a go.
Nevertheless my initial goal of applying the access tags to barriers did not work for now. Because there are two poi's passing by, the original osm node stil gets access = no The access I set to the poi derived from the line based on the from -node code is ignored by basecamp routing. I can only tell the routing mechanism to use the barrier if I set access = yes on the original osm node. I stopped further testing because of my lack of indept mkgmap logic and the many changes I had to make to my style.
Kind regards Joris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Joris, I think I'll not commit the poi-tagged-v3.patch. If I got you right it doesn't help to solve problems. On the other hand it is very difficult to understand and even more difficult to document. Maybe I find a better solution when I am back from a cycling trip which will start in the next days. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Freitag, 19. Juni 2020 14:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Thnx for the tip Ticker -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Ticker Berkin Verzonden: vrijdag 19 juni 2020 14:01 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi I have this in my style: # stop routing on service roads (esp. service=parking_aisle) if there might be a gate highway=service & mkgmap:way-has-pois=true {add access=destination} It isn't foolproof. Elsewhere (in points) I don't make any assumptions about a barrier=gate... restricting access over what the access= tag specfies. Ticker On Fri, 2020-06-19 at 10:13 +0000, Gerd Petermann wrote:
Hi Joris,
yes, the --link-pois-to-ways feature can be quite confusing, esp. in combination with --add-pois-to-lines. The original barrier node is used by the --link-pois-to-ways feature to possibly create a route restriction (after the style rules were applied to both the barrier node and the way). The POIs which are generated by the --add-pois-to-x feature do not have any influence on routing. I think you get the best results when you don't change the access tag for the barrier node.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Freitag, 19. Juni 2020 11:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature
Hi Gerd
Sorry, I did not know that. I did used it very intensily to get access tags to barriers linked to highways. It works as assumed to 'catch' the poi's and use them. I made some 'unittests' based on the values and also they work fine as well. So I think it's a go.
Nevertheless my initial goal of applying the access tags to barriers did not work for now. Because there are two poi's passing by, the original osm node stil gets access = no The access I set to the poi derived from the line based on the from -node code is ignored by basecamp routing. I can only tell the routing mechanism to use the barrier if I set access = yes on the original osm node. I stopped further testing because of my lack of indept mkgmap logic and the many changes I had to make to my style.
Kind regards Joris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Oke, I did use it to echotags mistagged barriers on cycleroutes so I could fix them. But no big deal. Enjoy your trip and have fun with the result of your work on your Oregon 😊 Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: vrijdag 19 juni 2020 14:30 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, I think I'll not commit the poi-tagged-v3.patch. If I got you right it doesn't help to solve problems. On the other hand it is very difficult to understand and even more difficult to document. Maybe I find a better solution when I am back from a cycling trip which will start in the next days. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Freitag, 19. Juni 2020 14:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Thnx for the tip Ticker -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Ticker Berkin Verzonden: vrijdag 19 juni 2020 14:01 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi I have this in my style: # stop routing on service roads (esp. service=parking_aisle) if there might be a gate highway=service & mkgmap:way-has-pois=true {add access=destination} It isn't foolproof. Elsewhere (in points) I don't make any assumptions about a barrier=gate... restricting access over what the access= tag specfies. Ticker On Fri, 2020-06-19 at 10:13 +0000, Gerd Petermann wrote:
Hi Joris,
yes, the --link-pois-to-ways feature can be quite confusing, esp. in combination with --add-pois-to-lines. The original barrier node is used by the --link-pois-to-ways feature to possibly create a route restriction (after the style rules were applied to both the barrier node and the way). The POIs which are generated by the --add-pois-to-x feature do not have any influence on routing. I think you get the best results when you don't change the access tag for the barrier node.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Freitag, 19. Juni 2020 11:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature
Hi Gerd
Sorry, I did not know that. I did used it very intensily to get access tags to barriers linked to highways. It works as assumed to 'catch' the poi's and use them. I made some 'unittests' based on the values and also they work fine as well. So I think it's a go.
Nevertheless my initial goal of applying the access tags to barriers did not work for now. Because there are two poi's passing by, the original osm node stil gets access = no The access I set to the poi derived from the line based on the from -node code is ignored by basecamp routing. I can only tell the routing mechanism to use the barrier if I set access = yes on the original osm node. I stopped further testing because of my lack of indept mkgmap logic and the many changes I had to make to my style.
Kind regards Joris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Joris, if you are interested in the routing effect of POIs you should enable info level logging for uk.me.parabola.mkgmap.osmstyle.StyledConverter. Look for messages containing the text "Access restriction in POI node " Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Freitag, 19. Juni 2020 17:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Oke, I did use it to echotags mistagged barriers on cycleroutes so I could fix them. But no big deal. Enjoy your trip and have fun with the result of your work on your Oregon 😊 Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: vrijdag 19 juni 2020 14:30 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi Joris, I think I'll not commit the poi-tagged-v3.patch. If I got you right it doesn't help to solve problems. On the other hand it is very difficult to understand and even more difficult to document. Maybe I find a better solution when I am back from a cycling trip which will start in the next days. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Freitag, 19. Juni 2020 14:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature Thnx for the tip Ticker -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Ticker Berkin Verzonden: vrijdag 19 juni 2020 14:01 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Nearby poi feature Hi I have this in my style: # stop routing on service roads (esp. service=parking_aisle) if there might be a gate highway=service & mkgmap:way-has-pois=true {add access=destination} It isn't foolproof. Elsewhere (in points) I don't make any assumptions about a barrier=gate... restricting access over what the access= tag specfies. Ticker On Fri, 2020-06-19 at 10:13 +0000, Gerd Petermann wrote:
Hi Joris,
yes, the --link-pois-to-ways feature can be quite confusing, esp. in combination with --add-pois-to-lines. The original barrier node is used by the --link-pois-to-ways feature to possibly create a route restriction (after the style rules were applied to both the barrier node and the way). The POIs which are generated by the --add-pois-to-x feature do not have any influence on routing. I think you get the best results when you don't change the access tag for the barrier node.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Freitag, 19. Juni 2020 11:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Nearby poi feature
Hi Gerd
Sorry, I did not know that. I did used it very intensily to get access tags to barriers linked to highways. It works as assumed to 'catch' the poi's and use them. I made some 'unittests' based on the values and also they work fine as well. So I think it's a go.
Nevertheless my initial goal of applying the access tags to barriers did not work for now. Because there are two poi's passing by, the original osm node stil gets access = no The access I set to the poi derived from the line based on the from -node code is ignored by basecamp routing. I can only tell the routing mechanism to use the barrier if I set access = yes on the original osm node. I stopped further testing because of my lack of indept mkgmap logic and the many changes I had to make to my style.
Kind regards Joris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
Gerd Petermann -
Joris Bo -
Ticker Berkin