[mkgmap-dev] Fw: Help

Mon May 4 07:35:16 BST 2015

Hi Thorsten,

thanks for the feedback. What do you think about my proposed
solution? 

Gerd

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