[mkgmap-dev] Nearby poi feature

Fri Jun 19 11:13:56 BST 2020

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 at lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo at 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 at lists.mkgmap.org.uk> Namens Gerd Petermann
Verzonden: vrijdag 19 juni 2020 10:37
Aan: Development list for mkgmap <mkgmap-dev at 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-tp5967043p5968143.html
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 at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at 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 at lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo at 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 at lists.mkgmap.org.uk> Namens Gerd Petermann
Verzonden: donderdag 18 juni 2020 15:25
Aan: Development list for mkgmap <mkgmap-dev at 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 at lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo at 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 at lists.mkgmap.org.uk> Namens Gerd Petermann
Verzonden: donderdag 18 juni 2020 12:58
Aan: Development list for mkgmap <mkgmap-dev at 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 at lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo at 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 at lists.mkgmap.org.uk> Namens Gerd Petermann
Verzonden: donderdag 18 juni 2020 12:08
Aan: Development list for mkgmap <mkgmap-dev at 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 at lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo at 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 at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev