[mkgmap-dev] Fw: Help

Mon May 4 07:46:15 BST 2015

On Mon, May 04, Gerd Petermann wrote:

> Hi Thorsten,
> 
> thanks for the feedback. What do you think about my proposed
> solution? 

I like the idea. But I'm currently still thinking, if this really
works.
For something like "place=city", the place tag and the name are the
most important thing mostly used. But what about population? What
to do if only one of the "two" POI has full informations?

Even more complicated would be something like amenity=restaurant, if
somebody adds a POI and adds all tags to the building, too (I think
this is bad tagging and the POI should be removed from the OSM data,
but that's another problem.
When are this two POIs really the same? And what if the tags sligthly
differ?

  Thorsten 

> 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
>  		 	   		  

> _______________________________________________
> 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)