logo separator

[mkgmap-dev] Fw: Help

From thundercel at gpsinfo.com.br thundercel at gpsinfo.com.br on Mon May 4 14:13:55 BST 2015

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150504/3afff5d1/attachment.html>


More information about the mkgmap-dev mailing list