Re: [mkgmap-dev] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI
Hi Gerd, There is something weird happening with this version r3573, maybe a bug or maybe a fault in my styles? The name of London disappears and becomes England, http://www.openstreetmap.org/relation/58447 I see the same for Edinburgh which becomes Scotland. Any idea what went wrong here? How can I get the name of England not at the node of London (=admin_centre) but in the middle of the country / relation? With mkgmap-r3487 it was still ok. See http://mijndev.openstreetmap.nl/~ligfietser/test/ for my styles and the tiles around London. Version mkgmap-r3573 was committed by gerd on Sun, 10 May 2015 admin_centre-v1.patch: avoid to create duplicate POI 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. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] housenumber2 branch r3589
Hi all,
I think I've now found a solution for most of the known problems
reg. address search, for details see svn log:
http://www.mkgmap.org.uk/websvn/log.php?repname=mkgmapisdir=1;
The remaining work to do is cleanup and maybe performance
improvements, I don't plan any more significant
changes in the algorithms as long as nobody complains.
If you want to try the branch with your style, please make sure
to understand the new special tags mkgmap:numbers=false
and mkgmap:execute_finalize_rules=true in combination with inc/address.
Attached is the diff between the default style in the branch and that in trunk.
Note that mkgmap uses by default all OSM elements with a tag addr:housenumber
or mkgmap:housenumber. Even if the style doesn't create any map object for the
element, the numbers are used, so the new tags are used to
make sure that the rules in inc/address are used for all of them and
to allow the exclusion.
A few hints:
The img files produced with the branch are typically larger, esp. in areas
where the trunk version did not work well (e.g. heavy usage of addr:place)
The throughput is a few percent slower. Main reason is the complex
search for nearest roads. Maybe I can find a better algorithm for this in
the future.
It would be great to get some feedback, esp. when you think that
rather good / clear OSM data is not interpreted correctly,
but also when you think the branch works fine ;-)
Gerd
diff -r ./inc/water_lines \mkgmap-tr\resources\styles\default/inc/water_lines
3d2
route=ferry {set mkgmap:numbers = false }
diff -r ./lines \mkgmap-tr\resources\styles\default/lines
11d10
addr:housenumber=* {set mkgmap:execute_finalize_rules=true}
31c30
highway=motorway|highway=motorway_link { add oneway=yes; add
mkgmap:numbers=false }
---
highway=motorway|highway=motorway_link { add oneway=yes }
200,202d198
# don't add house numbers to unnamed or artifical bicycle ways
mkgmap:bicycle=yes (mkgmap:foot=no mkgmap:car=no mkgmap:street!=* |
mkgmap:synthesised=yes) {set mkgmap:numbers=false}
diff -r ./points \mkgmap-tr\resources\styles\default/points
11d10
addr:housenumber=* {set mkgmap:execute_finalize_rules=true}
diff -r ./polygons \mkgmap-tr\resources\styles\default/polygons
11,12d10
addr:housenumber=* {set mkgmap:execute_finalize_rules=true}
84,86d81
# we need addrees info from buildings for the address search
include 'inc/address';
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3590: ignore position of role=admin_centre node when name of
Version mkgmap-r3590 was committed by gerd on Wed, 13 May 2015 ignore position of role=admin_centre node when name of boundary and name of node are not equal ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI
Hi Minko, ahh, yes, I assume that you still get two different POI, one for London, one for England, but they are at the same place. This is probably not what we want? I'll have a look at your data later if that explanation doesn't work out. Gerd Date: Wed, 13 May 2015 11:35:36 +0200 From: ligfiet...@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI Hi Gerd, There is something weird happening with this version r3573, maybe a bug or maybe a fault in my styles? The name of London disappears and becomes England, http://www.openstreetmap.org/relation/58447 I see the same for Edinburgh which becomes Scotland. Any idea what went wrong here? How can I get the name of England not at the node of London (=admin_centre) but in the middle of the country / relation? With mkgmap-r3487 it was still ok. See http://mijndev.openstreetmap.nl/~ligfietser/test/ for my styles and the tiles around London. Version mkgmap-r3573 was committed by gerd on Sun, 10 May 2015 admin_centre-v1.patch: avoid to create duplicate POI 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. ___ 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
Re: [mkgmap-dev] housenumber2 branch r3589
Hi Gerd thank you for the good work i'll test the new version against my styles, after reading the doc ;-) , and give a feedback if there are problems. Bernd Am Mittwoch, 13. Mai 2015, 10:58:18 schrieb Gerd Petermann: Hi all, I think I've now found a solution for most of the known problems reg. address search, for details see svn log: http://www.mkgmap.org.uk/websvn/log.php?repname=mkgmapisdir=1; ... Gerd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI
Yep, I see with GPSMapedit those two points at the same place. In Mapsource it seems random at which zoomlevel which placename is shown, either London (which I prefer) or England. I notice the same for Scotland but I guess in many other countries or regions this will be an issue too. Thanks for looking at it. - Oorspronkelijk bericht - ahh, yes, I assume that you still get two different POI, one for London, one for England, but they are at the same place. This is probably not what we want? I'll have a look at your data later if that explanation doesn't work out. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI
Hi Minko, I think this is an error caused by the patch. I thought that it is a good idea to place the generated POI at the same place as the admin_centre node, but now I think this is only usefull when the names are equal. If not, we should probable use the center of the polygon again. I have to check if the admin_level is also important. Gerd ligfietser wrote Yep, I see with GPSMapedit those two points at the same place. In Mapsource it seems random at which zoomlevel which placename is shown, either London (which I prefer) or England. I notice the same for Scotland but I guess in many other countries or regions this will be an issue too. Thanks for looking at it. - Oorspronkelijk bericht - ahh, yes, I assume that you still get two different POI, one for London, one for England, but they are at the same place. This is probably not what we want? I'll have a look at your data later if that explanation doesn't work out. Gerd ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3573-admin-centre-v1-patch-avoid-to-create-duplicate-POI-tp5843949p5844461.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] repeated code for option name-tag-list
Hi programmers, we have LocatorUtil which evaluates the option and diverse routines like StyledConverter, LinkDestinationHook, RelationStyleHook and now also POIGeneratorHook which seem to do the same to evaluate the name of an OSM element. I wonder why we don't evaluate the name once in ElementSaver? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/repeated-code-for-option-name-tag-list-tp5844472.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3590: ignore position of role=admin_centre node when name of
Working as expected, thanks for the quick fix Gerd! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] EU map too big?
Hi, On Wed, May 13, Minko wrote: I fear that the Europe map became too big for mkgmap to put it into one mapset. I have now 2293 img tiles that I wanted to combine with mkgmap-r3590 The java memory is set to -Xmx8000m, the error message is as follows: Maybe you should write more in detail what exaclty you try to do? For one gmapsupp, whole europe is of course far too big. And with 2293 img tiles you have too much, too. The number of img tiles is limited to 2000 for older devices. Don't know where the limit is for newer devices, I think 5000 tiles. I have no problems creating the data for whole europe with about 1300 img tiles. But I use --tdbfile and not --gmapsupp. Afterwards I can select the img tiles I need and write them with MapSource to a GPS device. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, 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
Re: [mkgmap-dev] EU map too big?
Hi Gerd, There was no problem when I skipped about 200 tiles (~1,5 Gb), the index was created. So the limit seems to be around 2000 tiles / 10 Gb of data. I will try to skip split-name-index, lets see if that will work... ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] EU map too big?
Hi Minko, ah, ok, so you don't have the problem with the index files contained in the 5 parts. I think you should wait for a comment from Steve regarding the limit, a comment i svn says that there is no known limit, so maybe the hard coded value 0xff is not needed. Gerd ligfietser wrote Hi Gerd, No, I can't create a gmapsupp because the whole Europe map is 11 Gb and the maximum size is 4Gb for one gmapsupp. So I need to split my Europe map in several gmapsupp's but that's not a problem. Last year I could manage this with 3, but now I need at least 5. However, I've also seen Mkgmap producing gmapsupp files 5 Gb which doesnt make any sense, because Garmin dont support this. Problem is not the gmapsupp set, but the mapset for the pc / Basecamp. I have set x-split-name-index and also added housenumbers from the French address database. I guess it would help to throw them out. Last option is no big Europe map anymore or on without a search index... :-/ - Oorspronkelijk bericht - Van: Gerd Petermann lt; gpetermann_muenchen@ gt; Aan: mkgmap-dev@.org Verzonden: Woensdag 13 mei 2015 22:18:33 Onderwerp: Re: [mkgmap-dev] EU map too big? Hi Minko, yes, the message is probably produced while writing the index file. Presuming that this limit really exists there is probably no program that works. You may try if Basecamp is able to produce a gmapsupp for all tiles. If that doesn't work I assume that you have to reduce the number of items that are indexed, e.g. POI. Or maybe we can add code so that some POI are created but not indexed. If I got that right some devices would still show them. Gerd ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/EU-map-too-big-tp5844506p5844513.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3591: enable merge lines when creating the overview map.
Version mkgmap-r3591 was committed by gerd on Thu, 14 May 2015 enable merge lines when creating the overview map. MapBuilder.config() is not called in this case. TODO: mergeShapes does not yet work with overview maps, probably because the reader doesn't produce identical Coord instances for points with equal coordinates. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] EU map too big?
Hi Minko, I've just noticed that the merge-lines option was ignored and disabled by default when the overview map was created. I've changed that with r3591. The effect is great, the overview map size is reduced by 30% . I have to look into the shape merging process, it does not yet work with the overview map. Gerd Date: Wed, 13 May 2015 21:37:06 +0200 From: ligfiet...@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] EU map too big? I fear that the Europe map became too big for mkgmap to put it into one mapset. I have now 2293 img tiles that I wanted to combine with mkgmap-r3590 The java memory is set to -Xmx8000m, the error message is as follows: SEVERE (MapFailedException): (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. What does this mean? Is my index file too big? Is there another way to combine the img tiles to make a single mapset? ___ 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
Re: [mkgmap-dev] Commit: r3590: ignore position of role=admin_centre node when name of
Hi Minko, thanks for the quick feedback. I am not sure if the additional check for the name is all we need, but it should fix most cases. Gerd Date: Wed, 13 May 2015 15:51:06 +0200 From: ligfiet...@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Commit: r3590: ignore position of role=admin_centre node when name of Working as expected, thanks for the quick fix 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
