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

Sun May 24 08:21:38 BST 2020

Hi all,

seems all are happy with the current implementation? I've merged the recent changes in trunk and slighty changed the docu (1)
I hope the docu matches the actual implementation now. If I hear no complains I want to merge the branch to trunk tomorrow.

ciao,
Gerd

(1) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4501

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at hotmail.com>
Gesendet: Montag, 18. Mai 2020 10:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] nearby-POI: named / unnamed

Hi all,

the current implementation detects only groups of POI with the same type AND name.
The groups are calculated after all POI were created.
A null in name is handled like an empty string.
Order of occurence in the input might matter, but I can change the code so that e.g. the lowest positive id is preferred.

So, the docu doesn't match the implementation and I wonder what needs to be changed.
If we want to handle a group of guesthouses where each has a different name, e.g. house1, house2, and house3 we need a different implementation or an additional one. Problem: How would mkgmap decide what name should be used?

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Montag, 18. Mai 2020 10:00
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] nearby-POI: named / unnamed

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
_______________________________________________
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