Hi all,
I've now looked at the code in POIGeneratorHook.
Attached is a first attempt to solve the problem, the compiled binary
based on trunk version r3564 is here:
http://files.mkgmap.org.uk/download/264/mkgmap.jar
It implements the following:
When POIGeneratorHook creates a POI for a type=boundary relation
with boundary=administrative it searches for a role=admin_centre member
in that relation.
If one is found, the generated POI will use the coordinates of this member.
I see no easy way to compare the tags of the existing
node with those of the generated POI, so
as a second step, StyledConverter detects when a POI
with the same type and name (or empty name) is created at the
same Garmin coordinates (after style processing)
If that is true, the latter one is ignored and an info message is logged.
Maybe for certain types this should be changed to check for a radius
rather than equality, but that would require complex configuration.
I think this solves the problem reported by A.Carlos, maybe it also
helps Stephen Sgalowski.
Please let me know if there are other member roles like admin_centre
which could be treated alike, or if this patch causes problem.
If I hear no complains I will commit it on sunday.
Gerd
From: thundercel@gpsinfo.com.br
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Mon, 4 May 2015 10:13:55 -0300
Subject: Re: [mkgmap-dev] Fw: Help
Hi,
On Mon, May 04, Gerd Petermann wrote:
>
I got some screenshots from Anor.Carlos that show this relation:
>
http://www.openstreetmap.org/relation/333659> which has
name=Barra do Garças and place=town.
> If I got that right, the
--add-pois-to-area option creates a node with the tag place=town for it,
although the relation also has a member
>
http://www.openstreetmap.org/node/415522222> with
place=town and name=Barra do Garças
> As a result, the map contains
two POI with very different locations, one has the additional tag
mkgmap:area2poi=true, but that doesn't help in the style rules to filter
duplicate entry because one doesn't know about the node 415522222.
Yes, in relation the --add-poi-to-area creates
a node with the tag place = town,
but in this
relation there is 415522222 member node that is
the place=town positioned in
its true location.
The knot created
by the --add-to-it-area option in this case duplicates
an existing node place=town, but in another
position.
This
node member (415522222) was included in the relationship as
admin_centre.
>
My 1st approach would be this:
> After style processing, keep a map that
relates the Garmin POI with the original node, one map for each type. If two or
more POI have the same type and label(s), remove those where the OSM element has
the mkgmap:area2poi=true tag (maybe also the ones with
mkgmap:line2poi=true.
> Gerd
For
our tests in Brazil only identified this occurrence of POI duplication in boundary relations and when there is the relation=boundary
the admin_center included.
Marcio
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev