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

Mon May 18 09:00:39 BST 2020

Hi Gerd, Mike & others

In the absence of other feedback and if other mkgmapers concerned with
this feature are reasonably happy with your fixed version, it is
probably simplest to keep the close to existing interface with just
minor tidy-ups etc.

Some thoughts:

1/ When making a group of POI, grouping should be consistent regardless
of the order in which POI are processed, ie there should not be a group
that contains a POI within :length: of a POI in another group.

2/ Should a POI with a given type/subType be subject to more that one
rule, the rules differing in the :length: or /name-matching? 

3/ Following on from 2/; if a set of rules like:
    0x4a00/named:30:action
    0x4a00/unnamed:50:another-action
    0x4a00/all:40:action
   is allowed, the implementation logic needs careful consideration and
will probably be expensive in terms of definition, writing the code and
processing time & memory, for not much benefit. 

4/ Continuing from /3, rule checking could forbid a mixture of /all
with /named or /unnamed for a given type/subtype

5/ Some of the more complication actions I was suggesting are only
relevant to /all, which might contain a mix of named and unnamed POI

6/ Is there a case for a grouping of same-named POI?

Ticker

On Sun, 2020-05-17 at 06:16 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> not sure how to process here. I expected some feedback from the
> others, also for the current version in the branch.
> Why is it so quiet now?
> 
> Gerd
> 
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Freitag, 8. Mai 2020 13:37
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] nearby-POI: named / unnamed
> 
> 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
> _______________________________________________
> 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