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

Mon May 25 08:59:46 BST 2020

Hi Joris,

you probably missed this post:
http://gis.19327.n8.nabble.com/new-branch-nearby-POI-tt5965004.html

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo at hotmail.com>
Gesendet: Montag, 25. Mai 2020 09:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] nearby-POI: named / unnamed

Hi

I got /download a mkgmap version called "mkgmap-r4485.patch" date 5-5-2020
This worked fine for me.
When start testing r4495 for the is_in() , these versions did not have the nearby poi feature anymore, so I skipped looking at it and temporarily removed the option from my tests.

I'll use the new version immediately with both 'is_in' and 'nearby poi'  and let you know if i encounter unexpected behavior.

Kind regards
Joris

-----Oorspronkelijk bericht-----
Van: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> Namens Gerd Petermann
Verzonden: maandag 25 mei 2020 08:47
Aan: Development list for mkgmap <mkgmap-dev at lists.mkgmap.org.uk>
Onderwerp: Re: [mkgmap-dev] nearby-POI: named / unnamed

Hi Joris,

I don't know what 4885.patch means. Anyway, seems that most users don't like to try branch versions, so I have merged the branch.
Let's see what happens.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo at hotmail.com>
Gesendet: Montag, 25. Mai 2020 07:44
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] nearby-POI: named / unnamed

Hi Gerd

I used the option up to 4885.patch and that worked perfectly for me.
Thank you for the effort.

Kind regards
Joris

-----Oorspronkelijk bericht-----
Van: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> Namens Gerd Petermann
Verzonden: zondag 24 mei 2020 09:22
Aan: Development list for mkgmap <mkgmap-dev at lists.mkgmap.org.uk>
Onderwerp: Re: [mkgmap-dev] nearby-POI: named / unnamed

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