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@suse.de To: mkgmap-dev@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@gpsinfo.com.br To: mkgmap-dev@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@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)