Hi Gerd, Trying to help the Anor.Carlos, is there any command to be entered by the user in rendering to be removed key: place inserted boundary: relation? Unfortunately in Brazil some editors inserted a KEY place in boundary-administrative relationship there so duplicity in indexing as the key:place exists in admin_centre inserted in the relationship. []s Marcio
Date: Sun, 3 May 2015 07:56:00 -0700 From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Help
Hi A.Carlos,
I am sorry, I don't yet understand your problem. Maybe you can post some screenshots to describe what you want and what you get?
You can use http://files.mkgmap.org.uk/ for that.
Gerd
A. Carlos wrote
help
Hello, the question may seem amateurish, but I'm having problems compiling my maps. Seeing the OSM, the region that use in many places are using the place at the midpoint of the Administrative Liminte and also in relation to limit the administrative, in the case here level 8.
However, when compiling the map with the styles that have both the GPS when the Mapsouce when looking for these cities are showing up two times in the list.
I ask: Do you have any command, tip to delete one of these tags, both at the center (point) and in relation Administrative Limit to not duplicate research? grateful Anor C. A. de Souza
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 thundercel wrote
Hi Gerd, Trying to help the Anor.Carlos, is there any command to be entered by the user in rendering to be removed key: place inserted boundary: relation?
Unfortunately in Brazil some editors inserted a KEY place in boundary-administrative relationship there so duplicity in indexing as the key:place exists in admin_centre inserted in the relationship. []s Marcio
Date: Sun, 3 May 2015 07:56:00 -0700 From:
gpetermann_muenchen@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Help
Hi A.Carlos,
I am sorry, I don't yet understand your problem. Maybe you can post some screenshots to describe what you want and what you get?
You can use http://files.mkgmap.org.uk/ for that.
Gerd
A. Carlos wrote
help
Hello, the question may seem amateurish, but I'm having problems compiling my maps. Seeing the OSM, the region that use in many places are using the place at the midpoint of the Administrative Liminte and also in relation to limit the administrative, in the case here level 8.
However, when compiling the map with the styles that have both the GPS when the Mapsouce when looking for these cities are showing up two times in the list.
I ask: Do you have any command, tip to delete one of these tags, both at the center (point) and in relation Administrative Limit to not duplicate research? grateful Anor C. A. de Souza
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Fw-Help-tp5843021p5843024.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
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
Hi all, 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. 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? 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
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)
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@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
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)
Hi Thorsten, good points. When the tags like population are different the style may produce different POI (different type, same label), so my solution would not help in all cases. I also see the problem that we can have duplicates which are really different, e.g. two small hamlets with the same name (like Holzhausen which appears often in Germany). So, maybe a less general approach: Treat type=boundary relations special and detect the case that a node member with role=admin_centre is present. If that is the case, don't generate a POI. I fear that will also cause trouble in some cases, e.g. when the node with role=admin_centre doesn't have the wanted tags :-( Gerd
Date: Mon, 4 May 2015 08:46:15 +0200 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Fw: Help
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
On Mon, May 04, 2015 at 08:46:15AM +0200, Thorsten Kukuk wrote:
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.
Would it be possible for mkgmap --areas-to-pois to copy the tags to one (or all) of the entrance POIs, instead of generating a new POI? Let us consider a building that is dedicated to a single restaurant, and has multiple entrances. Or a school building that has a complex shape and lots of doors on each side, but only one main entrance that is useable by visitors. I think that it would be best to have a POI generated for the main entrance, or maybe for all entrances. Someone could "tag for a renderer" and duplicating the tags (amenity, name, opening_hours, etc.) on each entrance. Then we would get a duplicate POI for the area if --areas-to-pois is used. This redundant tagging would AFAIU be the only way to get POIs on the entrances with the current mkgmap. For those who prefer a car analogy: parking=multi_storey or parking=underground lot that has an entrance. OK, for cars, the entrance and exit driveways are usually explicitly mapped, with appropriate access tags. For pedestrian routing, some fences or locked gates might be missing or ignored by the routing, and therefore you really could benefit from knowing which entrance to use, instead of being told where the center of the building or area is. Marko
Hi Marko, we have the option --pois-to-areas-placement with the defaults 'entrance=main;entrance=yes;building=entrance', but I think you want to avoid the situation that we have two POI in the map? I don't like the idea to compare and weight tags in mkgmap, I'd prefer to do that in a kind of style file, but that also sounds like a lot of coding. So, please check if the patch admin_centre-v1.patch helps for this as well: http://gis.19327.n5.nabble.com/Fw-Help-tp5843021p5843485.html Gerd
Date: Mon, 4 May 2015 16:26:46 +0300 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Copying area tags to pre-existing POIs
On Mon, May 04, 2015 at 08:46:15AM +0200, Thorsten Kukuk wrote:
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.
Would it be possible for mkgmap --areas-to-pois to copy the tags to one (or all) of the entrance POIs, instead of generating a new POI?
Let us consider a building that is dedicated to a single restaurant, and has multiple entrances. Or a school building that has a complex shape and lots of doors on each side, but only one main entrance that is useable by visitors.
I think that it would be best to have a POI generated for the main entrance, or maybe for all entrances.
Someone could "tag for a renderer" and duplicating the tags (amenity, name, opening_hours, etc.) on each entrance. Then we would get a duplicate POI for the area if --areas-to-pois is used. This redundant tagging would AFAIU be the only way to get POIs on the entrances with the current mkgmap.
For those who prefer a car analogy: parking=multi_storey or parking=underground lot that has an entrance. OK, for cars, the entrance and exit driveways are usually explicitly mapped, with appropriate access tags. For pedestrian routing, some fences or locked gates might be missing or ignored by the routing, and therefore you really could benefit from knowing which entrance to use, instead of being told where the center of the building or area is.
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
Hi all, I've now looked at the code in POIGeneratorHook. Attached is a first attempt to solve the problem, the compiled binary based on trunk version r3564 is here: http://files.mkgmap.org.uk/download/264/mkgmap.jar It implements the following: When POIGeneratorHook creates a POI for a type=boundary relation with boundary=administrative it searches for a role=admin_centre member in that relation. If one is found, the generated POI will use the coordinates of this member. I see no easy way to compare the tags of the existing node with those of the generated POI, so as a second step, StyledConverter detects when a POI with the same type and name (or empty name) is created at the same Garmin coordinates (after style processing) If that is true, the latter one is ignored and an info message is logged. Maybe for certain types this should be changed to check for a radius rather than equality, but that would require complex configuration. I think this solves the problem reported by A.Carlos, maybe it also helps Stephen Sgalowski. Please let me know if there are other member roles like admin_centre which could be treated alike, or if this patch causes problem. If I hear no complains I will commit it on sunday. Gerd From: thundercel@gpsinfo.com.br To: mkgmap-dev@lists.mkgmap.org.uk Date: Mon, 4 May 2015 10:13:55 -0300 Subject: Re: [mkgmap-dev] Fw: Help 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
Gerd Petermann -
GerdP
-
Marko Mäkelä -
Thorsten Kukuk -
thundercel＠gpsinfo.com.br