[mkgmap-dev] nearby-POI: named / unnamed

Fri May 8 12:37:03 BST 2020

Hi Gerd

I was considering this mostly from the point-of-view of searching, with
map declutter a secondary consideration.

I was assuming that a rule has gathered a cloud of POI with the same
type/subtype that had resolved as "nearby" somehow.

Then some action clause on the rule to is used to guide the following
possible actions:

- If none are named: find a central one to keep and delete the others

- If any named, keep the name on the central for each distinct name and
un-name the rest

- If one is named: keep this and delete the unnamed

- If any are named, keep these and delete the unnamed

- If multiple with the same name, keep the central one for each
distinct name and delete the rest, including unnamed.

I think this should all be done after the style has been interpreted
and act on the resultant POI. I don't like the idea of new mkgmap tags
to control the interpretation.

In the case you mention where barrier POI, using the same type/subtype
are given a name to indicate the barrier type, it is entirely up to a
matching rule as to how it should be handled (see above). 

Another rule clause could be string that is appended to the POI name
with a substitution for the number deleted, eg
--nearby-poi-rules=0x6605:30:delete-poi:"{numdel} others within 30
metres"

As has been said earlier, the new is_in() function is good for avoiding
the initial generation of some POI, but it can't do the full job.
For
instance, 'points' could contain:
  tourism=picnic_site [0x4a00
resolution 24]
  leisure=picnic_table &
is_in(tourism,picnic_site,in_or_on)=false
     [0x4a00 resolution 24]
but
a mechanism to suppress 0x4a00 for multiple tables not in a picnic site
is still needed.

Ticker

On Fri, 2020-05-08 at 05:30 +0000, Gerd Petermann wrote:
> Hi all,
> 
> in (1) Ticker suggested "I'd like to see a method that deletes all
> unnamed POI within {distance}
> of a named one. 
> I guess this is also close to the meaning of "declutter" (I don't
> know how that works in Garmin devices, my Oregon doesn't have such an
> option)
> 
> I don't fully understand the idea. I assume it is about overlapping
> icons?
> @Ticker: Should this be done for a given list of POI types or for all
> named POI? The default style often adds names to POI, e.g. for a
> barrier=bollard. 
> Is this the name of the POI? An alternative would be to use the
> name=* tag of the corresponding node. Or we could introduce a new tag
> mkgmap:treat-as-unnamed=true which could be used in the style to mark
> generated names.
> Should it be done before or after the existing rules were applied?
> Remember that we have the "delete-name" action.
> 
> Gerd 
> 
> (1) http://gis.19327.n8.nabble.com/nearby-POIs-tp5964757p5964995.html
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev