<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi Thorsten,<br><br>thanks for the feedback. What do you think about my proposed<br>solution? <br><br>Gerd<br><br><div>> Date: Mon, 4 May 2015 07:48:21 +0200<br>> From: kukuk@suse.de<br>> To: mkgmap-dev@lists.mkgmap.org.uk<br>> Subject: Re: [mkgmap-dev] Fw: Help<br>> <br>> <br>> Hi,<br>> <br>> On Mon, May 04, Gerd Petermann wrote:<br>> <br>> > I am not sure if the OSM data is okay, but I think we probably have <br>> > more sure cases. Did anybody try to solve that already?<br>> > Do you see a general rule which might be implemented <br>> > as filter before or after style processing?<br>> <br>> The OSM data is okay, it is defined this way in the wiki. I have no<br>> solution for the city part, but I use for example:<br>> <br>> place=country & mkgmap:area2poi!=true [0x1500 level 5-7]<br>> <br>> But I only do that for POIs, where I know that you will have duplicates<br>> or where I don't care if one is missing.<br>> But for cities, this is not the case, since some have only a place key,<br>> otheres none (only boundary), and others both. But I don't want missing<br>> cities in the index, so I accept sometimes two.<br>> <br>> Thorsten<br>> <br>> > My 1st approach would be this:<br>> > After style processing, keep a map that relates the Garmin POI with <br>> > the original node, one map for each type. If two or more POI have the same <br>> > type and label(s), remove those where the OSM element has the <br>> > mkgmap:area2poi=true tag (maybe also the ones with <br>> > mkgmap:line2poi=true.<br>> > <br>> > Gerd<br>> > <br>> > > From: thundercel@gpsinfo.com.br<br>> > > To: mkgmap-dev@lists.mkgmap.org.uk<br>> > > Date: Sun, 3 May 2015 17:10:57 -0300<br>> > > Subject: Re: [mkgmap-dev] Fw: Help<br>> > > <br>> > > Hi Gerd.<br>> > > <br>> > > thanks for your quick response and congratulations to the whole team for the <br>> > > excellent work developed.<br>> > > Yes, it's POI generated by the add-as-to-area option and only when the <br>> > > boundary relationship. For the other areas we are not having problem.<br>> > > It is a filter we need and we do not know how to do and where to apply.<br>> > > A filter that only remove the label place when inserted into the boundary <br>> > > relationship. The filter would not need to collect all the POI. Would <br>> > > collect only those generated by the boundary area due to add-to-area option.<br>> > > We have a rule for admin_centre and these were included in the relationship, <br>> > > but unfortunately many admin_centre were excluded relationships.<br>> > > Could you help us?<br>> > > [] s<br>> > > Marcio<br>> > > <br>> > > -----Mensagem Original----- <br>> > > From: GerdP<br>> > > <br>> > > Hi Marcio,<br>> > > <br>> > > okay, so this is about the POI generated by the add-pois-to-area option<br>> > > and other OSM nodes with similar tags and the problem is that you<br>> > > cannot know if both exist or only one?<br>> > > Well, I think there is no trick to solve that problem,<br>> > > but it should be easy to implement a filter.<br>> > > Something like this:<br>> > > Collect all POI with the same type, and when two have the same<br>> > > label(s), select the one that has a special tag, or just use the first.<br>> > > I assume we have to limit this filter to special POI types.<br>> > > Does that sound like a solution?<br>> > > <br>> > > Gerd<br>> > > <br>> > > <br>> > > <br>> > > _______________________________________________<br>> > > mkgmap-dev mailing list<br>> > > mkgmap-dev@lists.mkgmap.org.uk<br>> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> > <br>> <br>> > _______________________________________________<br>> > mkgmap-dev mailing list<br>> > mkgmap-dev@lists.mkgmap.org.uk<br>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br>> <br>> <br>> -- <br>> Thorsten Kukuk, Senior Architect SLES & Common Code Base<br>> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany<br>> GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)<br>> _______________________________________________<br>> mkgmap-dev mailing list<br>> mkgmap-dev@lists.mkgmap.org.uk<br>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev<br></div> </div></body>
</html>