nearby-POI: named / unnamed
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
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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: zondag 24 mei 2020 09:22 Aan: Development list for mkgmap <mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@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@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: zondag 24 mei 2020 09:22 Aan: Development list for mkgmap <mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: maandag 25 mei 2020 08:47 Aan: Development list for mkgmap <mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@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@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: zondag 24 mei 2020 09:22 Aan: Development list for mkgmap <mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@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@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: maandag 25 mei 2020 08:47 Aan: Development list for mkgmap <mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@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@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: zondag 24 mei 2020 09:22 Aan: Development list for mkgmap <mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (4)
-
Gerd Petermann -
Gerd Petermann
-
Joris Bo -
Ticker Berkin