[mkgmap-dev] nearby POIs

Wed Apr 8 14:02:23 BST 2020

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 at hotmail.com] 
Sent: 07 April 2020 09:07
To: Development list for mkgmap <mkgmap-dev at 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 at lists.mkgmap.org.uk> im Auftrag von Mike
Baggaley <mike at 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