Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike
Hi Mike, I'd prefer to have the new code in a separate class, StyledConverter is already very complex. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike
Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike
HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike
Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike
Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike
Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike
Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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 Mike, okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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 Mike, I think there is an error in the logic regarding "merge-at-mid-point". When you have more than two POI with the same name and type the calculated position of the POI(s) depends on the order of occurance. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 22. April 2020 08:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Mike, okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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, the code does not find the centre of multiple points that are within range of each other. As you say, the final position will depend on the order in which the POIs are evaluated. The point will first move to a point midway between the first two points, then to a point midway between the moved point and the next point and so on. I think it would be quite difficult to be completely prescriptive when there are several points close together. Similarly, if a point is deleted, the one that gets deleted depends on the order the points are evaluated and in the case where several are close together could result in more than one being left. The approach would need to be completely different to properly work out whether or not a group of points are related. However, most duplicates I have encountered are just two POIS where a closed way (typically a building) and a point are tagged with the same information. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:52 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I think there is an error in the logic regarding "merge-at-mid-point". When you have more than two POI with the same name and type the calculated position of the POI(s) depends on the order of occurance. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 22. April 2020 08:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Mike, okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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 Mike, yes, the current approach will not work if we want to avoid this. The code would have to collect all POI first. You are probably right that OSM contains only a few POI which appear more than twice. Let's postpone this until someone finds a real world problem. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 21:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the code does not find the centre of multiple points that are within range of each other. As you say, the final position will depend on the order in which the POIs are evaluated. The point will first move to a point midway between the first two points, then to a point midway between the moved point and the next point and so on. I think it would be quite difficult to be completely prescriptive when there are several points close together. Similarly, if a point is deleted, the one that gets deleted depends on the order the points are evaluated and in the case where several are close together could result in more than one being left. The approach would need to be completely different to properly work out whether or not a group of points are related. However, most duplicates I have encountered are just two POIS where a closed way (typically a building) and a point are tagged with the same information. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:52 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I think there is an error in the logic regarding "merge-at-mid-point". When you have more than two POI with the same name and type the calculated position of the POI(s) depends on the order of occurance. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 22. April 2020 08:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Mike, okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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, To answer your points: 1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so. 2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this. 3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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, please find attached an updated patch that addresses the points below. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Gerd, To answer your points: 1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so. 2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this. 3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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 Mike, I did not try it, but it seems the configuration file doesn't allow the typical "#" as comment. This makes it rather useless. We should at least allow comment lines starting with a # to be ignored. I've added code to handle this, also untested. - What should happen when an error was found in the rules? + Ignore only the bad rule(s)? + Ignore all rules? + stop processing? We have this problem with other options like --style-option as well, so it's not directly related to the patch. I think It would be good to check this before any tile is processed, but the current implementation of the option handling makes this really difficult. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. April 2020 16:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that addresses the points below. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Gerd, To answer your points: 1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so. 2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this. 3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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, please find attached an updated patch that allows for # comments either as whole lines or as ends of a line. It also allows whitespace between the components of the rules. At the moment, if an error is found in a rule, this is reported as an error and that rule is ignored. This does result in duplicated error messages, one from each tile. I'm happy to change this to stop processing if you think that is better. I'm not keen on ignoring all rules if an error is found in a rule. If the rules file is not found then this will also just report an error and continue. Perhaps this one at least would be better if it caused termination? I did think about loading the rules at the beginning, prior to processing the tiles, but realised this would break the 'option before tile' convention which allows different options to be passed to each tile (does anyone do this for anything other than the description?). It would be pretty straightforward to cache the options and resulting rules and if the options are the same for the next tile, use the cached rules instead of reprocessing. What do you think? Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 April 2020 09:21 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I did not try it, but it seems the configuration file doesn't allow the typical "#" as comment. This makes it rather useless. We should at least allow comment lines starting with a # to be ignored. I've added code to handle this, also untested. - What should happen when an error was found in the rules? + Ignore only the bad rule(s)? + Ignore all rules? + stop processing? We have this problem with other options like --style-option as well, so it's not directly related to the patch. I think It would be good to check this before any tile is processed, but the current implementation of the option handling makes this really difficult. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. April 2020 16:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that addresses the points below. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Gerd, To answer your points: 1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so. 2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this. 3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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 Mike, regarding error handling I think we can wait for someone to complain. Each solution has its pros and cons. regarding option handling: - I have no idea what users do. It is possible to create very different maps with a single execution of mkgmap. I can't think of any good reason to do this, but I also see no way to find out if anybody does. I presume that many users don't read this list. - If you see a simple solution to cache the results which works fine with multiple threads using different options go ahead. - When I suggested --nearby-poi-rules-config=filename I thought that is should replace --nearby-poi-rules. Having both options simply complicates everything. If you think that it is unlikely to have more than two rules we should better remove --nearby-poi-rules-config=filename, else it should be documented that --nearby-poi-rules-config=filename overwrites --nearby-poi-rules. Sorry for suggesting it in the first place. - all those trim() statements in combination with substring() look error prone. If I got that right you could use rule.replaceAll("\\s+", "") once to remove all whitespace characters? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 28. April 2020 22:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that allows for # comments either as whole lines or as ends of a line. It also allows whitespace between the components of the rules. At the moment, if an error is found in a rule, this is reported as an error and that rule is ignored. This does result in duplicated error messages, one from each tile. I'm happy to change this to stop processing if you think that is better. I'm not keen on ignoring all rules if an error is found in a rule. If the rules file is not found then this will also just report an error and continue. Perhaps this one at least would be better if it caused termination? I did think about loading the rules at the beginning, prior to processing the tiles, but realised this would break the 'option before tile' convention which allows different options to be passed to each tile (does anyone do this for anything other than the description?). It would be pretty straightforward to cache the options and resulting rules and if the options are the same for the next tile, use the cached rules instead of reprocessing. What do you think? Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 April 2020 09:21 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I did not try it, but it seems the configuration file doesn't allow the typical "#" as comment. This makes it rather useless. We should at least allow comment lines starting with a # to be ignored. I've added code to handle this, also untested. - What should happen when an error was found in the rules? + Ignore only the bad rule(s)? + Ignore all rules? + stop processing? We have this problem with other options like --style-option as well, so it's not directly related to the patch. I think It would be good to check this before any tile is processed, but the current implementation of the option handling makes this really difficult. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. April 2020 16:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that addresses the points below. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Gerd, To answer your points: 1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so. 2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this. 3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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've replaced the trim statements with replaceAll in the attached updated patch. Having thought a bit more about caching the rules, I've realised in the multithreaded environment, there would need to be object locks and synchronisation, which would be unnecessarily complicated. Regarding the two options - I had 30 odd rules in my command line, so the config file is better for me, but I expect that most users will probably just use one or two rules. Your range suggestion has allowed me to reduce the number of rules to about 25. The config file option doesn't override the inline option; if both are provided then both sets of rules are applied - hence I don't think the documentation needs changing. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 29 April 2020 07:28 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, regarding error handling I think we can wait for someone to complain. Each solution has its pros and cons. regarding option handling: - I have no idea what users do. It is possible to create very different maps with a single execution of mkgmap. I can't think of any good reason to do this, but I also see no way to find out if anybody does. I presume that many users don't read this list. - If you see a simple solution to cache the results which works fine with multiple threads using different options go ahead. - When I suggested --nearby-poi-rules-config=filename I thought that is should replace --nearby-poi-rules. Having both options simply complicates everything. If you think that it is unlikely to have more than two rules we should better remove --nearby-poi-rules-config=filename, else it should be documented that --nearby-poi-rules-config=filename overwrites --nearby-poi-rules. Sorry for suggesting it in the first place. - all those trim() statements in combination with substring() look error prone. If I got that right you could use rule.replaceAll("\\s+", "") once to remove all whitespace characters? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 28. April 2020 22:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that allows for # comments either as whole lines or as ends of a line. It also allows whitespace between the components of the rules. At the moment, if an error is found in a rule, this is reported as an error and that rule is ignored. This does result in duplicated error messages, one from each tile. I'm happy to change this to stop processing if you think that is better. I'm not keen on ignoring all rules if an error is found in a rule. If the rules file is not found then this will also just report an error and continue. Perhaps this one at least would be better if it caused termination? I did think about loading the rules at the beginning, prior to processing the tiles, but realised this would break the 'option before tile' convention which allows different options to be passed to each tile (does anyone do this for anything other than the description?). It would be pretty straightforward to cache the options and resulting rules and if the options are the same for the next tile, use the cached rules instead of reprocessing. What do you think? Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 April 2020 09:21 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I did not try it, but it seems the configuration file doesn't allow the typical "#" as comment. This makes it rather useless. We should at least allow comment lines starting with a # to be ignored. I've added code to handle this, also untested. - What should happen when an error was found in the rules? + Ignore only the bad rule(s)? + Ignore all rules? + stop processing? We have this problem with other options like --style-option as well, so it's not directly related to the patch. I think It would be good to check this before any tile is processed, but the current implementation of the option handling makes this really difficult. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. April 2020 16:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that addresses the points below. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Gerd, To answer your points: 1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so. 2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this. 3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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 Mike, OK, did not see this line fileRules.addAll(Arrays.asList(rules)); So, I think I'll commit the patch tomorrow if nobody else suggests changes. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 29. April 2020 17:52 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, I've replaced the trim statements with replaceAll in the attached updated patch. Having thought a bit more about caching the rules, I've realised in the multithreaded environment, there would need to be object locks and synchronisation, which would be unnecessarily complicated. Regarding the two options - I had 30 odd rules in my command line, so the config file is better for me, but I expect that most users will probably just use one or two rules. Your range suggestion has allowed me to reduce the number of rules to about 25. The config file option doesn't override the inline option; if both are provided then both sets of rules are applied - hence I don't think the documentation needs changing. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 29 April 2020 07:28 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, regarding error handling I think we can wait for someone to complain. Each solution has its pros and cons. regarding option handling: - I have no idea what users do. It is possible to create very different maps with a single execution of mkgmap. I can't think of any good reason to do this, but I also see no way to find out if anybody does. I presume that many users don't read this list. - If you see a simple solution to cache the results which works fine with multiple threads using different options go ahead. - When I suggested --nearby-poi-rules-config=filename I thought that is should replace --nearby-poi-rules. Having both options simply complicates everything. If you think that it is unlikely to have more than two rules we should better remove --nearby-poi-rules-config=filename, else it should be documented that --nearby-poi-rules-config=filename overwrites --nearby-poi-rules. Sorry for suggesting it in the first place. - all those trim() statements in combination with substring() look error prone. If I got that right you could use rule.replaceAll("\\s+", "") once to remove all whitespace characters? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 28. April 2020 22:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that allows for # comments either as whole lines or as ends of a line. It also allows whitespace between the components of the rules. At the moment, if an error is found in a rule, this is reported as an error and that rule is ignored. This does result in duplicated error messages, one from each tile. I'm happy to change this to stop processing if you think that is better. I'm not keen on ignoring all rules if an error is found in a rule. If the rules file is not found then this will also just report an error and continue. Perhaps this one at least would be better if it caused termination? I did think about loading the rules at the beginning, prior to processing the tiles, but realised this would break the 'option before tile' convention which allows different options to be passed to each tile (does anyone do this for anything other than the description?). It would be pretty straightforward to cache the options and resulting rules and if the options are the same for the next tile, use the cached rules instead of reprocessing. What do you think? Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 April 2020 09:21 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I did not try it, but it seems the configuration file doesn't allow the typical "#" as comment. This makes it rather useless. We should at least allow comment lines starting with a # to be ignored. I've added code to handle this, also untested. - What should happen when an error was found in the rules? + Ignore only the bad rule(s)? + Ignore all rules? + stop processing? We have this problem with other options like --style-option as well, so it's not directly related to the patch. I think It would be good to check this before any tile is processed, but the current implementation of the option handling makes this really difficult. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. April 2020 16:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that addresses the points below. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Gerd, To answer your points: 1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so. 2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this. 3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler. I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, I agree about the changes to debug level because the remaining log.info() messages are still meaningful. You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing. I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points "). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Mike, the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax: --nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...] This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted. The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs. The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule. The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points. Wildcard rules are only applied if no other rule is applicable. For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted. Regards, Mike _______________________________________________ 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 Mike, hi Gerd, thanks for the nearby option, I like the new way to unclutter the map. To my args-file i´ve added: nearby-poi-rules=*/named:10,*/unnamed:30,0x2f00-0x2f1f:30,0x3200-0x331f:50,0x13700-0x1370d:30 A lot of the pois seem to be reduced (deleted) as expected, but I stumbled on tourism=picnic_site and leisure=picnic_table here: https://www.openstreetmap.org/way/498671746 https://www.openstreetmap.org/way/108892873 These 2 polygon tourism=picnic_site contain picnic pois, tourism in the one and leisure in the other. My rule combines the pois in 0x2f0b: tourism=picnic_site | leisure=picnic_table [0x2f0b resolution 24] As long as tourism and leisure are collected in one poi, both poi will not be reduced. If separated to different pois, tourism is reduced, leisure not. I can´t get the option to work on both. Regards Jan
Am 29.04.2020 um 18:06 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Mike,
OK, did not see this line fileRules.addAll(Arrays.asList(rules));
So, I think I'll commit the patch tomorrow if nobody else suggests changes.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 29. April 2020 17:52 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
I've replaced the trim statements with replaceAll in the attached updated patch. Having thought a bit more about caching the rules, I've realised in the multithreaded environment, there would need to be object locks and synchronisation, which would be unnecessarily complicated.
Regarding the two options - I had 30 odd rules in my command line, so the config file is better for me, but I expect that most users will probably just use one or two rules. Your range suggestion has allowed me to reduce the number of rules to about 25. The config file option doesn't override the inline option; if both are provided then both sets of rules are applied - hence I don't think the documentation needs changing.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 29 April 2020 07:28 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
regarding error handling I think we can wait for someone to complain. Each solution has its pros and cons. regarding option handling: - I have no idea what users do. It is possible to create very different maps with a single execution of mkgmap. I can't think of any good reason to do this, but I also see no way to find out if anybody does. I presume that many users don't read this list. - If you see a simple solution to cache the results which works fine with multiple threads using different options go ahead. - When I suggested --nearby-poi-rules-config=filename I thought that is should replace --nearby-poi-rules. Having both options simply complicates everything. If you think that it is unlikely to have more than two rules we should better remove --nearby-poi-rules-config=filename, else it should be documented that --nearby-poi-rules-config=filename overwrites --nearby-poi-rules. Sorry for suggesting it in the first place. - all those trim() statements in combination with substring() look error prone. If I got that right you could use rule.replaceAll("\\s+", "") once to remove all whitespace characters?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 28. April 2020 22:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that allows for # comments either as whole lines or as ends of a line. It also allows whitespace between the components of the rules.
At the moment, if an error is found in a rule, this is reported as an error and that rule is ignored. This does result in duplicated error messages, one from each tile. I'm happy to change this to stop processing if you think that is better. I'm not keen on ignoring all rules if an error is found in a rule. If the rules file is not found then this will also just report an error and continue. Perhaps this one at least would be better if it caused termination?
I did think about loading the rules at the beginning, prior to processing the tiles, but realised this would break the 'option before tile' convention which allows different options to be passed to each tile (does anyone do this for anything other than the description?). It would be pretty straightforward to cache the options and resulting rules and if the options are the same for the next tile, use the cached rules instead of reprocessing. What do you think?
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 April 2020 09:21 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I did not try it, but it seems the configuration file doesn't allow the typical "#" as comment. This makes it rather useless. We should at least allow comment lines starting with a # to be ignored. I've added code to handle this, also untested.
- What should happen when an error was found in the rules? + Ignore only the bad rule(s)? + Ignore all rules? + stop processing? We have this problem with other options like --style-option as well, so it's not directly related to the patch. I think It would be good to check this before any tile is processed, but the current implementation of the option handling makes this really difficult.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. April 2020 16:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that addresses the points below.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
To answer your points:
1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so.
2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this.
3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler.
I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine.
Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I agree about the changes to debug level because the remaining log.info() messages are still meaningful.
You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing.
I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points ").
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs
HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch.
Cheers, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax:
--nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...]
This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted.
The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs.
The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule.
The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points.
Wildcard rules are only applied if no other rule is applicable.
For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point
This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved
Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted.
Regards, Mike
_______________________________________________ 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 Jan, yes, the data structure used for this new option is too simple when multiple unnamed or equally named POI at very different locations are handled. The first processed POI is stored and for all further POI the position is compared with that first. The algo is not able to handle multiple clouds like in your example. @Mike: My approach would be to collect all POI, even those which appear at the same location, in a list. This list would be reduced with a single method call in StyledConverter.end(). Small disadvantage: You cannot log the node details. I'll work on this idea, if you prefer another just go ahead and we can compare the solutions. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 2. Mai 2020 22:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] nearby POIs Hi Mike, hi Gerd, thanks for the nearby option, I like the new way to unclutter the map. To my args-file i´ve added: nearby-poi-rules=*/named:10,*/unnamed:30,0x2f00-0x2f1f:30,0x3200-0x331f:50,0x13700-0x1370d:30 A lot of the pois seem to be reduced (deleted) as expected, but I stumbled on tourism=picnic_site and leisure=picnic_table here: https://www.openstreetmap.org/way/498671746 https://www.openstreetmap.org/way/108892873 These 2 polygon tourism=picnic_site contain picnic pois, tourism in the one and leisure in the other. My rule combines the pois in 0x2f0b: tourism=picnic_site | leisure=picnic_table [0x2f0b resolution 24] As long as tourism and leisure are collected in one poi, both poi will not be reduced. If separated to different pois, tourism is reduced, leisure not. I can´t get the option to work on both. Regards Jan
Am 29.04.2020 um 18:06 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Mike,
OK, did not see this line fileRules.addAll(Arrays.asList(rules));
So, I think I'll commit the patch tomorrow if nobody else suggests changes.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 29. April 2020 17:52 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
I've replaced the trim statements with replaceAll in the attached updated patch. Having thought a bit more about caching the rules, I've realised in the multithreaded environment, there would need to be object locks and synchronisation, which would be unnecessarily complicated.
Regarding the two options - I had 30 odd rules in my command line, so the config file is better for me, but I expect that most users will probably just use one or two rules. Your range suggestion has allowed me to reduce the number of rules to about 25. The config file option doesn't override the inline option; if both are provided then both sets of rules are applied - hence I don't think the documentation needs changing.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 29 April 2020 07:28 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
regarding error handling I think we can wait for someone to complain. Each solution has its pros and cons. regarding option handling: - I have no idea what users do. It is possible to create very different maps with a single execution of mkgmap. I can't think of any good reason to do this, but I also see no way to find out if anybody does. I presume that many users don't read this list. - If you see a simple solution to cache the results which works fine with multiple threads using different options go ahead. - When I suggested --nearby-poi-rules-config=filename I thought that is should replace --nearby-poi-rules. Having both options simply complicates everything. If you think that it is unlikely to have more than two rules we should better remove --nearby-poi-rules-config=filename, else it should be documented that --nearby-poi-rules-config=filename overwrites --nearby-poi-rules. Sorry for suggesting it in the first place. - all those trim() statements in combination with substring() look error prone. If I got that right you could use rule.replaceAll("\\s+", "") once to remove all whitespace characters?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 28. April 2020 22:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that allows for # comments either as whole lines or as ends of a line. It also allows whitespace between the components of the rules.
At the moment, if an error is found in a rule, this is reported as an error and that rule is ignored. This does result in duplicated error messages, one from each tile. I'm happy to change this to stop processing if you think that is better. I'm not keen on ignoring all rules if an error is found in a rule. If the rules file is not found then this will also just report an error and continue. Perhaps this one at least would be better if it caused termination?
I did think about loading the rules at the beginning, prior to processing the tiles, but realised this would break the 'option before tile' convention which allows different options to be passed to each tile (does anyone do this for anything other than the description?). It would be pretty straightforward to cache the options and resulting rules and if the options are the same for the next tile, use the cached rules instead of reprocessing. What do you think?
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 April 2020 09:21 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I did not try it, but it seems the configuration file doesn't allow the typical "#" as comment. This makes it rather useless. We should at least allow comment lines starting with a # to be ignored. I've added code to handle this, also untested.
- What should happen when an error was found in the rules? + Ignore only the bad rule(s)? + Ignore all rules? + stop processing? We have this problem with other options like --style-option as well, so it's not directly related to the patch. I think It would be good to check this before any tile is processed, but the current implementation of the option handling makes this really difficult.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. April 2020 16:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that addresses the points below.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
To answer your points:
1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so.
2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this.
3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler.
I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine.
Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I agree about the changes to debug level because the remaining log.info() messages are still meaningful.
You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing.
I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points ").
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs
HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch.
Cheers, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax:
--nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...]
This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted.
The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs.
The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule.
The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points.
Wildcard rules are only applied if no other rule is applicable.
For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point
This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved
Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted.
Regards, Mike
_______________________________________________ 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, that sounds good to me. Could you create a class containing the node and the POI and collect these in a list rather than just the POIs or would that be too much overhead just for logging? Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 03 May 2020 07:19 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Jan, yes, the data structure used for this new option is too simple when multiple unnamed or equally named POI at very different locations are handled. The first processed POI is stored and for all further POI the position is compared with that first. The algo is not able to handle multiple clouds like in your example. @Mike: My approach would be to collect all POI, even those which appear at the same location, in a list. This list would be reduced with a single method call in StyledConverter.end(). Small disadvantage: You cannot log the node details. I'll work on this idea, if you prefer another just go ahead and we can compare the solutions. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 2. Mai 2020 22:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] nearby POIs Hi Mike, hi Gerd, thanks for the nearby option, I like the new way to unclutter the map. To my args-file i´ve added: nearby-poi-rules=*/named:10,*/unnamed:30,0x2f00-0x2f1f:30,0x3200-0x331f:50,0 x13700-0x1370d:30 A lot of the pois seem to be reduced (deleted) as expected, but I stumbled on tourism=picnic_site and leisure=picnic_table here: https://www.openstreetmap.org/way/498671746 https://www.openstreetmap.org/way/108892873 These 2 polygon tourism=picnic_site contain picnic pois, tourism in the one and leisure in the other. My rule combines the pois in 0x2f0b: tourism=picnic_site | leisure=picnic_table [0x2f0b resolution 24] As long as tourism and leisure are collected in one poi, both poi will not be reduced. If separated to different pois, tourism is reduced, leisure not. I can´t get the option to work on both. Regards Jan
Am 29.04.2020 um 18:06 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Mike,
OK, did not see this line fileRules.addAll(Arrays.asList(rules));
So, I think I'll commit the patch tomorrow if nobody else suggests changes.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 29. April 2020 17:52 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
I've replaced the trim statements with replaceAll in the attached updated patch. Having thought a bit more about caching the rules, I've realised in the multithreaded environment, there would need to be object locks and synchronisation, which would be unnecessarily complicated.
Regarding the two options - I had 30 odd rules in my command line, so the config file is better for me, but I expect that most users will probably just use one or two rules. Your range suggestion has allowed me to reduce the number of rules to about 25. The config file option doesn't override the inline option; if both are provided then both sets of rules are applied - hence I don't think the documentation needs changing.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 29 April 2020 07:28 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
regarding error handling I think we can wait for someone to complain. Each solution has its pros and cons. regarding option handling: - I have no idea what users do. It is possible to create very different maps with a single execution of mkgmap. I can't think of any good reason to do this, but I also see no way to find out if anybody does. I presume that many users don't read this list. - If you see a simple solution to cache the results which works fine with multiple threads using different options go ahead. - When I suggested --nearby-poi-rules-config=filename I thought that is should replace --nearby-poi-rules. Having both options simply complicates everything. If you think that it is unlikely to have more than two rules we should better remove --nearby-poi-rules-config=filename, else it should be documented that --nearby-poi-rules-config=filename overwrites --nearby-poi-rules. Sorry for suggesting it in the first place. - all those trim() statements in combination with substring() look error prone. If I got that right you could use rule.replaceAll("\\s+", "") once to remove all whitespace characters?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 28. April 2020 22:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that allows for # comments either as whole lines or as ends of a line. It also allows whitespace between the components of the rules.
At the moment, if an error is found in a rule, this is reported as an error and that rule is ignored. This does result in duplicated error messages, one from each tile. I'm happy to change this to stop processing if you think that is better. I'm not keen on ignoring all rules if an error is found in a rule. If the rules file is not found then this will also just report an error and continue. Perhaps this one at least would be better if it caused termination?
I did think about loading the rules at the beginning, prior to processing the tiles, but realised this would break the 'option before tile' convention which allows different options to be passed to each tile (does anyone do this for anything other than the description?). It would be pretty straightforward to cache the options and resulting rules and if the options are the same for the next tile, use the cached rules instead of reprocessing. What do you think?
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 April 2020 09:21 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I did not try it, but it seems the configuration file doesn't allow the typical "#" as comment. This makes it rather useless. We should at least allow comment lines starting with a # to be ignored. I've added code to handle this, also untested.
- What should happen when an error was found in the rules? + Ignore only the bad rule(s)? + Ignore all rules? + stop processing? We have this problem with other options like --style-option as well, so it's not directly related to the patch. I think It would be good to check this before any tile is processed, but the current implementation of the option handling makes this really difficult.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. April 2020 16:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that addresses the points below.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
To answer your points:
1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so.
2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this.
3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler.
I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine.
Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I agree about the changes to debug level because the remaining log.info() messages are still meaningful.
You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing.
I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points ").
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs
HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch.
Cheers, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax:
--nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet
e-name|merge-at-mid-point][,...]
This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted.
The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs.
The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule.
The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points.
Wildcard rules are only applied if no other rule is applicable.
For example: :
--nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1
f:3,0x641d:400:merge-at-mid-point
This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved
Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted.
Regards, Mike
_______________________________________________ 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 Mike, I also thought about this. I think in this phase memory can be a bottleneck. I don't know if POIs are critical, probably not. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 3. Mai 2020 09:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs HI Gerd, that sounds good to me. Could you create a class containing the node and the POI and collect these in a list rather than just the POIs or would that be too much overhead just for logging? Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 03 May 2020 07:19 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs Hi Jan, yes, the data structure used for this new option is too simple when multiple unnamed or equally named POI at very different locations are handled. The first processed POI is stored and for all further POI the position is compared with that first. The algo is not able to handle multiple clouds like in your example. @Mike: My approach would be to collect all POI, even those which appear at the same location, in a list. This list would be reduced with a single method call in StyledConverter.end(). Small disadvantage: You cannot log the node details. I'll work on this idea, if you prefer another just go ahead and we can compare the solutions. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 2. Mai 2020 22:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] nearby POIs Hi Mike, hi Gerd, thanks for the nearby option, I like the new way to unclutter the map. To my args-file i´ve added: nearby-poi-rules=*/named:10,*/unnamed:30,0x2f00-0x2f1f:30,0x3200-0x331f:50,0 x13700-0x1370d:30 A lot of the pois seem to be reduced (deleted) as expected, but I stumbled on tourism=picnic_site and leisure=picnic_table here: https://www.openstreetmap.org/way/498671746 https://www.openstreetmap.org/way/108892873 These 2 polygon tourism=picnic_site contain picnic pois, tourism in the one and leisure in the other. My rule combines the pois in 0x2f0b: tourism=picnic_site | leisure=picnic_table [0x2f0b resolution 24] As long as tourism and leisure are collected in one poi, both poi will not be reduced. If separated to different pois, tourism is reduced, leisure not. I can´t get the option to work on both. Regards Jan
Am 29.04.2020 um 18:06 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Mike,
OK, did not see this line fileRules.addAll(Arrays.asList(rules));
So, I think I'll commit the patch tomorrow if nobody else suggests changes.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 29. April 2020 17:52 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
I've replaced the trim statements with replaceAll in the attached updated patch. Having thought a bit more about caching the rules, I've realised in the multithreaded environment, there would need to be object locks and synchronisation, which would be unnecessarily complicated.
Regarding the two options - I had 30 odd rules in my command line, so the config file is better for me, but I expect that most users will probably just use one or two rules. Your range suggestion has allowed me to reduce the number of rules to about 25. The config file option doesn't override the inline option; if both are provided then both sets of rules are applied - hence I don't think the documentation needs changing.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 29 April 2020 07:28 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
regarding error handling I think we can wait for someone to complain. Each solution has its pros and cons. regarding option handling: - I have no idea what users do. It is possible to create very different maps with a single execution of mkgmap. I can't think of any good reason to do this, but I also see no way to find out if anybody does. I presume that many users don't read this list. - If you see a simple solution to cache the results which works fine with multiple threads using different options go ahead. - When I suggested --nearby-poi-rules-config=filename I thought that is should replace --nearby-poi-rules. Having both options simply complicates everything. If you think that it is unlikely to have more than two rules we should better remove --nearby-poi-rules-config=filename, else it should be documented that --nearby-poi-rules-config=filename overwrites --nearby-poi-rules. Sorry for suggesting it in the first place. - all those trim() statements in combination with substring() look error prone. If I got that right you could use rule.replaceAll("\\s+", "") once to remove all whitespace characters?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 28. April 2020 22:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that allows for # comments either as whole lines or as ends of a line. It also allows whitespace between the components of the rules.
At the moment, if an error is found in a rule, this is reported as an error and that rule is ignored. This does result in duplicated error messages, one from each tile. I'm happy to change this to stop processing if you think that is better. I'm not keen on ignoring all rules if an error is found in a rule. If the rules file is not found then this will also just report an error and continue. Perhaps this one at least would be better if it caused termination?
I did think about loading the rules at the beginning, prior to processing the tiles, but realised this would break the 'option before tile' convention which allows different options to be passed to each tile (does anyone do this for anything other than the description?). It would be pretty straightforward to cache the options and resulting rules and if the options are the same for the next tile, use the cached rules instead of reprocessing. What do you think?
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 April 2020 09:21 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I did not try it, but it seems the configuration file doesn't allow the typical "#" as comment. This makes it rather useless. We should at least allow comment lines starting with a # to be ignored. I've added code to handle this, also untested.
- What should happen when an error was found in the rules? + Ignore only the bad rule(s)? + Ignore all rules? + stop processing? We have this problem with other options like --style-option as well, so it's not directly related to the patch. I think It would be good to check this before any tile is processed, but the current implementation of the option handling makes this really difficult.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. April 2020 16:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that addresses the points below.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
To answer your points:
1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so.
2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this.
3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler.
I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine.
Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I agree about the changes to debug level because the remaining log.info() messages are still meaningful.
You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing.
I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points ").
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs
HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch.
Cheers, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax:
--nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet
e-name|merge-at-mid-point][,...]
This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted.
The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs.
The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule.
The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points.
Wildcard rules are only applied if no other rule is applicable.
For example: :
--nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1
f:3,0x641d:400:merge-at-mid-point
This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved
Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted.
Regards, Mike
_______________________________________________ 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, thanks, I see. The given example can easily be handled with is_in anyway. Jan
Am 03.05.2020 um 08:19 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
yes, the data structure used for this new option is too simple when multiple unnamed or equally named POI at very different locations are handled. The first processed POI is stored and for all further POI the position is compared with that first. The algo is not able to handle multiple clouds like in your example.
@Mike: My approach would be to collect all POI, even those which appear at the same location, in a list. This list would be reduced with a single method call in StyledConverter.end(). Small disadvantage: You cannot log the node details. I'll work on this idea, if you prefer another just go ahead and we can compare the solutions.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 2. Mai 2020 22:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] nearby POIs
Hi Mike, hi Gerd,
thanks for the nearby option, I like the new way to unclutter the map.
To my args-file i´ve added: nearby-poi-rules=*/named:10,*/unnamed:30,0x2f00-0x2f1f:30,0x3200-0x331f:50,0x13700-0x1370d:30
A lot of the pois seem to be reduced (deleted) as expected, but I stumbled on tourism=picnic_site and leisure=picnic_table here: https://www.openstreetmap.org/way/498671746 https://www.openstreetmap.org/way/108892873
These 2 polygon tourism=picnic_site contain picnic pois, tourism in the one and leisure in the other. My rule combines the pois in 0x2f0b: tourism=picnic_site | leisure=picnic_table [0x2f0b resolution 24]
As long as tourism and leisure are collected in one poi, both poi will not be reduced. If separated to different pois, tourism is reduced, leisure not. I can´t get the option to work on both.
Regards Jan
Am 29.04.2020 um 18:06 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Mike,
OK, did not see this line fileRules.addAll(Arrays.asList(rules));
So, I think I'll commit the patch tomorrow if nobody else suggests changes.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 29. April 2020 17:52 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
I've replaced the trim statements with replaceAll in the attached updated patch. Having thought a bit more about caching the rules, I've realised in the multithreaded environment, there would need to be object locks and synchronisation, which would be unnecessarily complicated.
Regarding the two options - I had 30 odd rules in my command line, so the config file is better for me, but I expect that most users will probably just use one or two rules. Your range suggestion has allowed me to reduce the number of rules to about 25. The config file option doesn't override the inline option; if both are provided then both sets of rules are applied - hence I don't think the documentation needs changing.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 29 April 2020 07:28 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
regarding error handling I think we can wait for someone to complain. Each solution has its pros and cons. regarding option handling: - I have no idea what users do. It is possible to create very different maps with a single execution of mkgmap. I can't think of any good reason to do this, but I also see no way to find out if anybody does. I presume that many users don't read this list. - If you see a simple solution to cache the results which works fine with multiple threads using different options go ahead. - When I suggested --nearby-poi-rules-config=filename I thought that is should replace --nearby-poi-rules. Having both options simply complicates everything. If you think that it is unlikely to have more than two rules we should better remove --nearby-poi-rules-config=filename, else it should be documented that --nearby-poi-rules-config=filename overwrites --nearby-poi-rules. Sorry for suggesting it in the first place. - all those trim() statements in combination with substring() look error prone. If I got that right you could use rule.replaceAll("\\s+", "") once to remove all whitespace characters?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 28. April 2020 22:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that allows for # comments either as whole lines or as ends of a line. It also allows whitespace between the components of the rules.
At the moment, if an error is found in a rule, this is reported as an error and that rule is ignored. This does result in duplicated error messages, one from each tile. I'm happy to change this to stop processing if you think that is better. I'm not keen on ignoring all rules if an error is found in a rule. If the rules file is not found then this will also just report an error and continue. Perhaps this one at least would be better if it caused termination?
I did think about loading the rules at the beginning, prior to processing the tiles, but realised this would break the 'option before tile' convention which allows different options to be passed to each tile (does anyone do this for anything other than the description?). It would be pretty straightforward to cache the options and resulting rules and if the options are the same for the next tile, use the cached rules instead of reprocessing. What do you think?
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 April 2020 09:21 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I did not try it, but it seems the configuration file doesn't allow the typical "#" as comment. This makes it rather useless. We should at least allow comment lines starting with a # to be ignored. I've added code to handle this, also untested.
- What should happen when an error was found in the rules? + Ignore only the bad rule(s)? + Ignore all rules? + stop processing? We have this problem with other options like --style-option as well, so it's not directly related to the patch. I think It would be good to check this before any tile is processed, but the current implementation of the option handling makes this really difficult.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. April 2020 16:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that addresses the points below.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
To answer your points:
1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so.
2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this.
3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler.
I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine.
Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I agree about the changes to debug level because the remaining log.info() messages are still meaningful.
You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing.
I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points ").
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs
HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch.
Cheers, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax:
--nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...]
This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted.
The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs.
The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule.
The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points.
Wildcard rules are only applied if no other rule is applicable.
For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point
This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved
Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted.
Regards, Mike
_______________________________________________ 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 Mike, I am making progress, see attached work-in-progress patch. Open problems: 1) The POI de-duplication might remove CoordPOI instances. If yes, it is an old error. Have to check the data flow... 2) With merge-at-midpoint we create a new Coord instance but we don't maintain the flags of the old instance, e.g. onBoundary(). Also your code introduced for dead-end-checks cannot work for these new instances. We need a different place to hande the --dead-ends option or maybe remove the merge-at-midpoint. Have to think about this. 3) I don't fully understand the intended behaviour when a POI type matches multiple rules. My current algo only applies the first rule that matches type and name. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Sonntag, 3. Mai 2020 18:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] nearby POIs Hi Gerd, thanks, I see. The given example can easily be handled with is_in anyway. Jan
Am 03.05.2020 um 08:19 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
yes, the data structure used for this new option is too simple when multiple unnamed or equally named POI at very different locations are handled. The first processed POI is stored and for all further POI the position is compared with that first. The algo is not able to handle multiple clouds like in your example.
@Mike: My approach would be to collect all POI, even those which appear at the same location, in a list. This list would be reduced with a single method call in StyledConverter.end(). Small disadvantage: You cannot log the node details. I'll work on this idea, if you prefer another just go ahead and we can compare the solutions.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 2. Mai 2020 22:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] nearby POIs
Hi Mike, hi Gerd,
thanks for the nearby option, I like the new way to unclutter the map.
To my args-file i´ve added: nearby-poi-rules=*/named:10,*/unnamed:30,0x2f00-0x2f1f:30,0x3200-0x331f:50,0x13700-0x1370d:30
A lot of the pois seem to be reduced (deleted) as expected, but I stumbled on tourism=picnic_site and leisure=picnic_table here: https://www.openstreetmap.org/way/498671746 https://www.openstreetmap.org/way/108892873
These 2 polygon tourism=picnic_site contain picnic pois, tourism in the one and leisure in the other. My rule combines the pois in 0x2f0b: tourism=picnic_site | leisure=picnic_table [0x2f0b resolution 24]
As long as tourism and leisure are collected in one poi, both poi will not be reduced. If separated to different pois, tourism is reduced, leisure not. I can´t get the option to work on both.
Regards Jan
Am 29.04.2020 um 18:06 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Mike,
OK, did not see this line fileRules.addAll(Arrays.asList(rules));
So, I think I'll commit the patch tomorrow if nobody else suggests changes.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 29. April 2020 17:52 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
I've replaced the trim statements with replaceAll in the attached updated patch. Having thought a bit more about caching the rules, I've realised in the multithreaded environment, there would need to be object locks and synchronisation, which would be unnecessarily complicated.
Regarding the two options - I had 30 odd rules in my command line, so the config file is better for me, but I expect that most users will probably just use one or two rules. Your range suggestion has allowed me to reduce the number of rules to about 25. The config file option doesn't override the inline option; if both are provided then both sets of rules are applied - hence I don't think the documentation needs changing.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 29 April 2020 07:28 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
regarding error handling I think we can wait for someone to complain. Each solution has its pros and cons. regarding option handling: - I have no idea what users do. It is possible to create very different maps with a single execution of mkgmap. I can't think of any good reason to do this, but I also see no way to find out if anybody does. I presume that many users don't read this list. - If you see a simple solution to cache the results which works fine with multiple threads using different options go ahead. - When I suggested --nearby-poi-rules-config=filename I thought that is should replace --nearby-poi-rules. Having both options simply complicates everything. If you think that it is unlikely to have more than two rules we should better remove --nearby-poi-rules-config=filename, else it should be documented that --nearby-poi-rules-config=filename overwrites --nearby-poi-rules. Sorry for suggesting it in the first place. - all those trim() statements in combination with substring() look error prone. If I got that right you could use rule.replaceAll("\\s+", "") once to remove all whitespace characters?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 28. April 2020 22:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that allows for # comments either as whole lines or as ends of a line. It also allows whitespace between the components of the rules.
At the moment, if an error is found in a rule, this is reported as an error and that rule is ignored. This does result in duplicated error messages, one from each tile. I'm happy to change this to stop processing if you think that is better. I'm not keen on ignoring all rules if an error is found in a rule. If the rules file is not found then this will also just report an error and continue. Perhaps this one at least would be better if it caused termination?
I did think about loading the rules at the beginning, prior to processing the tiles, but realised this would break the 'option before tile' convention which allows different options to be passed to each tile (does anyone do this for anything other than the description?). It would be pretty straightforward to cache the options and resulting rules and if the options are the same for the next tile, use the cached rules instead of reprocessing. What do you think?
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 April 2020 09:21 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I did not try it, but it seems the configuration file doesn't allow the typical "#" as comment. This makes it rather useless. We should at least allow comment lines starting with a # to be ignored. I've added code to handle this, also untested.
- What should happen when an error was found in the rules? + Ignore only the bad rule(s)? + Ignore all rules? + stop processing? We have this problem with other options like --style-option as well, so it's not directly related to the patch. I think It would be good to check this before any tile is processed, but the current implementation of the option handling makes this really difficult.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. April 2020 16:06 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that addresses the points below.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 April 2020 17:55 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Gerd,
To answer your points:
1) 0x2f1f was just a POI in my style which I have as a bus stop, and as bus stations often have all individual stops mapped it can be useful to remove duplicates (I don't use the default style). Looking at the default style I see that it has both bus stops and taxi as 0x2f17. I'm happy with either the example changing to 0x2f17 or the default style changing to 0x2f1f for bus stops (I have 0x2f17 just for taxi). The sample doesn't have to match the default style, but it would make sense for it to do so.
2) The code sorts the rules into POI type order, but doesn't sort by distance. It would better handle the example you have given if it sorted rules with the same POI type by distance. I'll look into this.
3) Allowing a range of POI types seems like it could be useful. I see that --poi-excl-index uses a hyphen to specify a range and propose we use the same format. I'll look into this as well.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 April 2020 07:07 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
okay, I started to find out if the code works as documented. Here is a first set of questions: 1) I started with the given sample --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f1f:30 and found out the the default style doesn't use type 0x2f1f. Is that intended? 2) Is it allowed to use multiple rules for the same POI type? Two rules like --nearby-poi-rules=0x2f1f:10:merge-at-mid-point,0x2f1f:1 are accepted, but I am not sure what to expect when this is done. The rules are applied in the given order, so the second will never match, right? 3) The option --poi-excl-index allows to specify ranges of POI types. Wouldn't it be good to use the same logic for --nearby-poi-rules?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Mittwoch, 22. April 2020 01:03 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
HI Gerd, the mods look fine to me. I don't think documenting a config file in a sample file is a good idea. I think it is much better if all the documentation is in one place. I also think it make sense to keep the --nearby-poi-rules option as I expect some users would just want something like -- nearby-poi-rules=*:25, and it would be overkill to have to create a config file to do this. I have fixed the formatting issues in the options file in the attached version of the patch.
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 21 April 2020 08:46 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
attached is a modified version of the patch. I've removed some of the changes in StyledConverter and did some cleanup on the NearbyPoiHandler.
I think you got me wrong regarding the config file. With similar to --road-name-config=filename I really meant that the config file should be provided as an example containing the detailed documentation. The option --nearby-poi-rules should be removed, it just adds complexity. This will also fix some formatting problems in file options.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 20. April 2020 16:00 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes were actually part of another patch that is aimed at tidying up logging, which causes me significant problems due to the mixed use of System.err.println and log.xxxx. If you want to remove the System.error.println change from the patch then that is fine.
Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 20 April 2020 07:25 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
I agree about the changes to debug level because the remaining log.info() messages are still meaningful.
You changed some System.err.println(...) to log.info(...). This has two effects: 1) severity is changed from error to info (which is wrong in these cases), the user should always see these messages. 2) the normal logging procedure prints the path to the current tile but the tile is not relevant and thus may be confusing.
I am not 100% sure about the messages log.warn("road has < 2 points",way.getId(),"(discarding)"); You probably only see them when you disable WrongAngleFixer by modfying the code. What was the reason for the change?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 15:24 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, the logging changes seem to me to be correct (though unrelated to the nearby POI change), reducing the severity of some messages to match those elsewhere. I accept that these things are open to interpretation, but would consider messages about entering and leaving functions and similar static code location messages to be debug level messages (e.g. "Maintaining highway counters"), those that give information that the code is doing something that does not need any action to be informational messages (e.g. "Pruning point xxxx"), those that might warrant investigation would be warning (e.g. Oneway road xxx goes nowhere" ) and those that indicate some sort of real problem would be error (e.g. "shape is not closed with identical points ").
Regards, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 19 April 2020 08:41 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
thanks, will look at it during the next days. Some of the changes to the logging in StyledConverter are probably not OK.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 19. April 2020 08:45 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached an updated patch that provides a config file option and puts the nearby POI code into a new class.
Cheers, Mike
-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 08 April 2020 14:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] nearby POIs
HI Gerd, I'll look into having a config file option and separating the code into a new class. Probably will be a couple of days before I get back to you with an updated version of the patch.
Cheers, Mike
-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 07 April 2020 09:07 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] nearby POIs
Hi Mike,
the syntax for the option parameters is extremely complex. I think it would be better to use a config file for that, similar to the option --road-name-config=roadNameConfig.txt we could have a --nearby-poi-rules=nearbyPoiConfig.txt What do you think?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 6. April 2020 20:24 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] nearby POIs
Hi Gerd, please find attached a patch for handling the removal of duplicate POIs that are near to each other but not coincident. The existing code handles the removal of coincident duplicates, but leaves other duplicates in place. It is very common in OSM for buildings to be tagged as amenities with a single node also being tagged as the same amenity. If using --add-pois-to-areas, this can lead to a lot of duplication. The patch provides a new command line option with the following syntax:
--nearby-poi-rules=type[/all|/named|/unnamed]:max-distance[:delete-poi|delet e-name|merge-at-mid-point][,...]
This defines a set of rules to follow when a POI is near to another of the same type. Each rule consists of three parts separated by colons. The first two parts must be provided; the last part can be defaulted.
The first part of the rule is the Garmin POI type code with an optional suffix; it determines when the rule is triggered. The type code may be specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered when processing a POI if the type code of the POI matches the rule type, providing there is also a match in the POI name and the first part suffix. If the suffix is '/all' (the default) then the match is only made on the type. If the suffix is '/named' then the rule is only triggered if the POI has a name. If the suffix is '/unnamed' then the rule is only triggered if the POI has no name. A wildcard of an asterisk character may be used to match any type code. The wildcard may also be combined with a suffix to allow separate processing of named and unnamed POIs.
The second part of the rule is the distance in metres which an already processed POI must be within for it to be considered to be nearby and hence trigger the action part of the rule.
The third part of the rule is the action part and provides three options: ::delete-poi - the POIS are considered to be duplicates and the duplicate is deleted. This is the default. ::delete-name - the POIS are not duplicates, but only a single name needs to be displayed. ::merge-at-mid-point - the POIS are considered to be duplicates but the location of the existing point is moved to a point midway between the two points.
Wildcard rules are only applied if no other rule is applicable.
For example: : --nearby-poi-rules=*/named:50,*/unnamed:25,0x2f1f/named:50:delete-name,0x2f1 f:3,0x641d:400:merge-at-mid-point
This has the following effect: : If no other rule applies, a POI with the same name and type and within 50m of one already processed will be deleted If no other rule applies, a POI having no name and of the same type and within 25m of one already processed will be deleted A POI of type 0x2f1f that is within 50m of another POI with the same name and type will have its name deleted A POI of type 0x2f1f that is within 3m of another POI with the same type will be deleted A POI of type 0x641d that is within 400m of another POI with the same type will be deleted and the existing point moved
Note: a POI that matches another in type, name and exact location is always considered a duplicate and deleted.
Regards, Mike
_______________________________________________ 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
Mike:/ "handling the *removal* of *duplicate *POIs that are *near* to each other but *not coincident*."/ Very useful! In the Netherlands I was involved in a discussion: Set [man_made=windmill] on POI-address-node (is rendered by JOSM and links address to POI) or Set on building (a windmill is not a node, but a building, but building tag is not rendered by JOSM)? Now solution has become "simple": set [man_made=windmill] on both "POI-address-node" and on building. Win-win situation thanks to Mike. But... also... http://gis.19327.n8.nabble.com/One-object-has-more-than-one-POI-tag-Hotel-Ca... One object has (or should have) more than one POI-tags. Examples: - tourism=hotel; amenity=restaurant - historic=building; man_made=windmill - shop=bakery; amenity=café ("konditorei") - amenity=bench; tourism=viewpoint - amenity=bench; tourism= artwork Gerd: /"2) You can create *multiple *POI using the *continue *statement."/ Yes, I can but now different POI's are on same location, which makes both POI's useless (mixed together). Mike:/ "<...> but the location of the *existing* point is *"MOVED"* to a point midway between the two points"./ Question: Is "moving" a "different POI" on the "same object" an *extra option* to resolve "mixed together" POI's? I know: not using "continue" will resolve (Renderer should decide what's more important: hotel *or* restaurant), but also implies a loss of information. -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
Hi Eric I disagree that coincident POI are useless, eg if [tourism=hotel, amenity=restaurant] were to generate: POI 0x2b01 (Lodgings>Hotel/Motel) and POI 0x2a00 (Food&Drink>All) then searching for either gives the correct answer - just what I would want. I implement this in my style. Concerning your other examples; something similar could be done for Cafe/Bakery as this is quite common and useful, but I found there were far to many minor amenity= to bother with, so ignoring all but the major ones, you just get the POI for viewpoint Ticker On Wed, 2020-04-22 at 01:04 -0700, AnkEric wrote:
Mike:/ "handling the *removal* of *duplicate *POIs that are *near* to each other but *not coincident*."/
Very useful! In the Netherlands I was involved in a discussion: Set [man_made=windmill] on POI-address-node (is rendered by JOSM and links address to POI) or Set on building (a windmill is not a node, but a building, but building tag is not rendered by JOSM)?
Now solution has become "simple": set [man_made=windmill] on both "POI-address-node" and on building. Win-win situation thanks to Mike.
But... also...
http://gis.19327.n8.nabble.com/One-object-has-more-than-one-POI-tag-H otel-Cafe-Restaurant-td5960958.html
One object has (or should have) more than one POI-tags. Examples: - tourism=hotel; amenity=restaurant - historic=building; man_made=windmill - shop=bakery; amenity=café ("konditorei") - amenity=bench; tourism=viewpoint - amenity=bench; tourism= artwork
Gerd: /"2) You can create *multiple *POI using the *continue *statement."/
Yes, I can but now different POI's are on same location, which makes both POI's useless (mixed together).
Mike:/ "<...> but the location of the *existing* point is *"MOVED"* to a point midway between the two points"./
Question: Is "moving" a "different POI" on the "same object" an *extra option* to resolve "mixed together" POI's?
I know: not using "continue" will resolve (Renderer should decide what's more important: hotel *or* restaurant), but also implies a loss of information.
-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
My issue: It's very useful to Render BOTH coincident POI's. But that's my question, issue! How? If [tourism=hotel, amenity=restaurant] is set on the SAME NODE than both tags are "mixed together" when rendered on the Map. So you see a POI 0x2b01x0x2a00 which is a "RestaHotelurant" ON the map. Searching for both is okay. Unless (see my cynical mode in my first post) a Mapper decides to remove tourism=hotel because it's now rendered (by some Renderers) as hotel and he/she doesn't use it a hotel but only as restaurant. Mapping for the Renderer: delete [tourism=hotel]. This issue would be resolved if both POI nodes would be rendered BESIDES or AMONG each other and not ON TOP of each other. Therefore my question to Mike: can you MOVE one of them. And NOT DELETE. -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
POI search is much more important for me. The rendering is of less importance. I need glasses to be able to recognize the icons and I don't wear them while cycling ;) Unfortunately I can barely read the result lists nowadays without stopping and using my optical glasses. I wonder why the rendering problem isn't solved in the rendering software (Garmins firmware or Basecamp). I see no way to solve that problem in mkgmap because it doesn't know how the Garmin software renders the POI, right? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von AnkEric <ankeric.osm@gmail.com> Gesendet: Mittwoch, 22. April 2020 10:58 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] nearby POIs My issue: It's very useful to Render BOTH coincident POI's. But that's my question, issue! How? If [tourism=hotel, amenity=restaurant] is set on the SAME NODE than both tags are "mixed together" when rendered on the Map. So you see a POI 0x2b01x0x2a00 which is a "RestaHotelurant" ON the map. Searching for both is okay. Unless (see my cynical mode in my first post) a Mapper decides to remove tourism=hotel because it's now rendered (by some Renderers) as hotel and he/she doesn't use it a hotel but only as restaurant. Mapping for the Renderer: delete [tourism=hotel]. This issue would be resolved if both POI nodes would be rendered BESIDES or AMONG each other and not ON TOP of each other. Therefore my question to Mike: can you MOVE one of them. And NOT DELETE. -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Concerning your other examples; something similar could be done for Cafe/Bakery as this is quite common and useful, but I found there were far to many minor amenity= to bother with, so ignoring all but the major ones, you just get the POI for viewpoint
I make my own Map because and only because my priorities are completely different to the priorities set by other Renderers: "ignoring all but the major ones, you just get the POI for viewpoint". During a bicycle tour we sometimes need a pause. When the grass is wet (Anke) we will look for a bench (coffee) or picnic_table (lunch). I will always search for a bench or picnic_table even by good weather. So even we have different priorities. Therefore these POI's are Rendered (my own Map) in the most visible way. If there's also a viewpoint, that's nice, but not first "priority", therefore not major (IMO). "Not many"? Last tour in East Germany we had to find out to search for viewpoint to find a bench. Okay, one mapper only, but complete area was viewpoint + bench. Which is okay, but not Rendered okay. Augh... I had forgotten this is still not okay in my style! Amenity should have priority (in MY Map). Or Mike might resolve by rendering both. But for a "simple node" this is a challenge. In a building two POI's are "ok", two poi's on a node are "messy". You're priorities (in your style) are quite different from mine. Which does not imply your priorities are not okay, but they are not mine. I'm using MKGMAP meet my own priorities by my own map. And Ger: I search for a POI if I (or more specific Anke as navigator on tandem bicycle) can't see it on the map. But first we will look on the Map. I will look at OsmAnd (and keep focussed on the road), Anke will look on Garmin. And again: my priorities or preferences are not yours. MKGMAP to resolve (my assumption) and make both of us happy. I should have a Rendering example in BaseCamp. Somewhere... tourism=hotel {set amenity=restaurant). And I should also send this Map to GPS? Or is BaseCamp "restahoteluant" enough proof of concept? -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
STYLE: MKGMAP, default, mapnik.txt tourism=hotel {set amenity=restaurant} BaseCamp: <http://gis.19327.n8.nabble.com/file/t344065/Hotel_Restaurant_BaseCamp.png> GPSMAP 64st: <http://gis.19327.n8.nabble.com/file/t344065/Hotel_Restaurant_GPSMAP_64st.png> On my own Map I won't Render the name. I will show POI only, select and click (or hover over) to find details. Ohhh, lol, I very rarely use GPSMAP (not allowed). Only sometimes during hiking trip, until Anke gets annoyed by my lack of experience. But Search for a POI, not Navigate to ("GO"), just show it on the Map, is to difficult for me; -)) Ohhh, lol, according to Garmin (inside my home office) I'm 5790 km away from this hotel/restaurant. Than it's excellent I did find it; -)) -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
Hi Eric, I am not sure what icons your pictures show. I assume it is 0x2f12 (internet or telefon) and lodging. I never tried it before but on my Oregon 600 only one icon is shown when I create two POI for the restaurant and for the hotel. It requires more changes in the default style than I thought. Anyhow: When I search for a restaurant the restaurant icon is displayed, when I search for lodging the "bed" icon is displayed While panning only the restaurant icon is displayed, but I can touch the icon and get a list of the objects at this place when touching the "menu" icon. Basecamp and Mapsource overlay multiple icons as in your picture but when hovering over the icon the list of objects is shown as well. If I got you right you want that mkgmap detects that two or more POI have the same location (remember the low Garmin resolution) and move them somewhere else (where? until all POI have their unique place on the map? Did you try how that looks at different zoom levels? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von AnkEric <ankeric.osm@gmail.com> Gesendet: Mittwoch, 22. April 2020 12:48 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] nearby POIs STYLE: MKGMAP, default, mapnik.txt tourism=hotel {set amenity=restaurant} BaseCamp: <http://gis.19327.n8.nabble.com/file/t344065/Hotel_Restaurant_BaseCamp.png> GPSMAP 64st: <http://gis.19327.n8.nabble.com/file/t344065/Hotel_Restaurant_GPSMAP_64st.png> On my own Map I won't Render the name. I will show POI only, select and click (or hover over) to find details. Ohhh, lol, I very rarely use GPSMAP (not allowed). Only sometimes during hiking trip, until Anke gets annoyed by my lack of experience. But Search for a POI, not Navigate to ("GO"), just show it on the Map, is to difficult for me; -)) Ohhh, lol, according to Garmin (inside my home office) I'm 5790 km away from this hotel/restaurant. Than it's excellent I did find it; -)) -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I forgot "continue" so there is NO restaurant rendered in my test. My test has failed. But I didn't know. What is rendered: - internet_access=wlan - tourism=hotel - name=Gr8 & La Place Bodegraven So there are already TWO (2) duplicate POI’s on top of each other. internet_access=yes {name 'Internet ${name}' | 'Internet'} [0x2f12 resolution 24 continue] If I add: - tourism=hotel {set amenity=restaurant} AND: - tourism=hotel | tourism=motel [0x2b01 resolution 24 continue] THEN: - I have THREE (3) duplicated POI’s: hotel + wifi + restaurant (I do believe I do see a plate, spoon, knife and fork). <http://gis.19327.n8.nabble.com/file/t344065/Hotel_Wifi_Restaurant_BaseCamp.png> Best option: Ignore my request. I have advised myself (and others): never use Garmin for Search. In OsmAnd I can select which category of POI is to be rendered. So only hotel, or only restaurant, or both, or none. Garmin (gpsmap) will only find 50 poi's. OsmAnd will ask each time if I want to extend search area to find more and more and more... I could even find your favorite restaurant from where I am. No address in OSM? Okay, wait a second, OsmAnd will calculate nearest address. But also: I was triggered this morning by Mike using the word "MOVE". And also: Is rendering two or three POI on top of each other considered to be okay for mkgmap, default style? Or should "we" prioritize? Set Level for POI ????? Or should I switch to Oregon 600? Just trying to make a joke... My conclusion for now: ignore my suggestion, but lets wait for Mike to explain "move"... Also if "we" should move Duplicated POI’s this should only be an option, only. I can use this option because I don’t render names (except for important names like rivers and city names, I like to know). But rendering names and moving POI’s? I expect it to be messy or very messy. Garmin used to have an option "declutter". But not anymore, I believe. Not gpsmap 64st. -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
Hi Eric,the picture still doesn't show the restaurant icon. I've attached my modified points file to really get three POI for a node like https://www.openstreetmap.org/node/129857992 Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von AnkEric <ankeric.osm@gmail.com> Gesendet: Mittwoch, 22. April 2020 16:26 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] nearby POIs I forgot "continue" so there is NO restaurant rendered in my test. My test has failed. But I didn't know. What is rendered: - internet_access=wlan - tourism=hotel - name=Gr8 & La Place Bodegraven So there are already TWO (2) duplicate POI’s on top of each other. internet_access=yes {name 'Internet ${name}' | 'Internet'} [0x2f12 resolution 24 continue] If I add: - tourism=hotel {set amenity=restaurant} AND: - tourism=hotel | tourism=motel [0x2b01 resolution 24 continue] THEN: - I have THREE (3) duplicated POI’s: hotel + wifi + restaurant (I do believe I do see a plate, spoon, knife and fork). <http://gis.19327.n8.nabble.com/file/t344065/Hotel_Wifi_Restaurant_BaseCamp.png> Best option: Ignore my request. I have advised myself (and others): never use Garmin for Search. In OsmAnd I can select which category of POI is to be rendered. So only hotel, or only restaurant, or both, or none. Garmin (gpsmap) will only find 50 poi's. OsmAnd will ask each time if I want to extend search area to find more and more and more... I could even find your favorite restaurant from where I am. No address in OSM? Okay, wait a second, OsmAnd will calculate nearest address. But also: I was triggered this morning by Mike using the word "MOVE". And also: Is rendering two or three POI on top of each other considered to be okay for mkgmap, default style? Or should "we" prioritize? Set Level for POI ????? Or should I switch to Oregon 600? Just trying to make a joke... My conclusion for now: ignore my suggestion, but lets wait for Mike to explain "move"... Also if "we" should move Duplicated POI’s this should only be an option, only. I can use this option because I don’t render names (except for important names like rivers and city names, I like to know). But rendering names and moving POI’s? I expect it to be messy or very messy. Garmin used to have an option "declutter". But not anymore, I believe. Not gpsmap 64st. -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I do see a red (or brown) dot in the middle that was not there before. After I added restaurant and "continue" to hotel. I was assuming this is a "plate". No spoon, knife, fork though. That's the "radiation" of wifi. But I can't see clearly because of the cluttering; -) Anyway, it's seems possible to render two (or more?) POI's on top of each other. I don't like that, but I can prevent it by NOT "continue". [internet_access] should not continue or being set after hotel? Like openfietsmap once resolved the historical windmill to be rendered as a windmill. But your example is better and different. Why? Do I wanna know? -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
participants (5)
-
AnkEric -
Gerd Petermann -
jan meisters -
Mike Baggaley -
Ticker Berkin