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 <[email protected]> Namens Gerd Petermann
Verzonden: donderdag 18 juni 2020 15:25
Aan: Development list for mkgmap <[email protected]>
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 <[email protected]> im Auftrag von Joris
Bo <[email protected]>
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 <[email protected]> Namens Gerd Petermann
Verzonden: donderdag 18 juni 2020 12:58
Aan: Development list for mkgmap <[email protected]>
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 <[email protected]> im Auftrag von Joris
Bo <[email protected]>
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 <[email protected]> Namens Gerd Petermann
Verzonden: donderdag 18 juni 2020 12:08
Aan: Development list for mkgmap <[email protected]>
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 <[email protected]> im Auftrag von Joris
Bo <[email protected]>
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
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
