[mkgmap-dev] Fw: Help

Wed May 6 10:23:07 BST 2015

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 at gpsinfo.com.br
To: mkgmap-dev at 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 at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150506/04ce7c56/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: admin_centre-v1.patch
Type: application/octet-stream
Size: 4308 bytes
Desc: not available
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150506/04ce7c56/attachment-0001.obj>