February 2010 - mkgmap-dev - The mkgmap lists

Commit: r1566: Drop all tags from the osm file that are not used
by svn commit 12 Feb '10

12 Feb '10

Version 1566 was commited by steve on 2010-02-08 12:33:09 +0000 (Mon, 08 Feb 2010) BRANCH: style-speed Drop all tags from the osm file that are not used in the applied style. Whether this makes a big difference or not depends on the country. In the UK which is mostly manually taged it doesn't make a great deal of difference. There are only an average of 2 tags per way and about zero per node. In countries with data imports, there are typically many tags per way (and even nodes) that refer back to the original data. Having tags on nodes is particularly bad for memory consumption since there are more nodes than ways and most are not POIs. We are forced to allocate a Tags object even though there is likely to be nothing to do as none of the tags are used. Denmark is the worst in this respect and so will show the best improvement with this patch. See also: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/003597.html For this to be successful you need an acurate list of all the tags that could be used. Tags are examined not just in the style itself, but there are hardwired tag lookups in the style system itself and there are non-style related usages as well. For the moment all the built in usages of tags are held in the builtin-tag-list file. I think I have got them all for normal use, but there may be options that require ones I've missed.

8 11

Gmapibuilder: Searching for new site to host source code
by Clinton Gladstone 12 Feb '10

12 Feb '10

Hi All, I, and others, have noticed that the original hosting server for Gmapibuilder appears to be no longer available. Attempts to contact the original author have also failed. Fortunately the source is BSD licensed. I still have the source (which I patched to convert .mdr and .mdx files as well), and would like to find a new permanent host for it. Are there any disadvantages to using Google Source, or is there a better place to host the code? (For those of you who do not know/remember Gmapibuilder converts maps created by mkgmap to the Gmapi format used on Mac OS X.) Any advice is appreciated. Cheers.

5 10

Re: [mkgmap-dev] Wrong multipolygon warnings
by David 12 Feb '10

12 Feb '10

Hello Carlos, Hi Wanmil, Mapsource capture is as if Mapsource level of details is set to lowest details. If you choose higher or highest LOD, the map should be good. David Le 12/02/2010 19:23, mkgmap-dev-request(a)lists.mkgmap.org.uk a écrit : >> Compiling Spain I get several warnings similar to the one below, that >> point to data that are correct (or it seems to me). >> >> |2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): >> 63240004.osm.gz: Multipolygon >> http://www.openstreetmap.org/browse/relation/319017 contains errors. >> 2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): 63240004.osm.gz: >> Polygon 4611686018427391078[5P : (44132028[5P]) carries role inner but >> is not inside any outer polygon. Potentially it does not belong to this >> multipolygon. >> >> |Reported way (hole in the building) lacks in the resulting map. >> Is it a know bug? >> Another question, why are polygons so deformed in MapSource compared to >> Mapnik? >> > Carlos, > > the way http://www.openstreetmap.org/browse/way/44132028 overlaps the > outer way of multipolygon > http://www.openstreetmap.org/browse/relation/319017. If we look keenly > on the definition of the multipolygon relation > (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) this is not > allowed. The current implementation of mkgmap does not support this. > > But it is widely used. There is a patch > (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007086.html) > which is not yet committed and which fixes the problem. I think it > will be committed within the next days. > > The deformations do not look good. I think the problem is that mkgmap > rounds the exact OSM coordinates to lower resolution garmin coordinates. > > WanMil

2 1

Re: [mkgmap-dev] multipolygon with outer polygon within inner polygons
by Minko 12 Feb '10

12 Feb '10

Thanks Steve, So, as I understand it, I need to change the default relation style file in order to convert those multipolygons into lines? When I look at other osm maps from the same area (openmtbmap, radfahrers map, computerteddy) I dont see those connecting lines between the borderlines. Looking at their style files I don't see a difference in how they handle the borders compared to the default style. So... how do they do this, if they use exactly the same osm data? If anybody who want to test it out, I put the osm data here: http://moh.freehostia.com/osm/nassau.osm (200kb, I only downloaded the border polygons of the municipality of Baarle-Nassau). Or an even more simple example can be found at http://moh.freehostia.com/osm/simple.osm (3kb) The last one is not real osm data, but a simplification of the situation. Steve Ratcliffe wrote: Thanks for that image as it shows the problem clearly. If the boundaries were being drawn as areas, then the lines would not be seen (or not much anyway) since they would be zero width. However since the borders are drawn as lines you clearly see the connecting lines. I think that the best way to solve this is for mkgmap to convert to multipolygon into separate lines in the case of boundaries. ..Steve

2 1

Maps crashing Mapsource in big cities
by Felix Hartmann 12 Feb '10

12 Feb '10

To me it seems that either we do something wrong, or Mapsource cannot handle very detailed places. Try compiling Australia from Geofabrik (I used maxnodes=1300000 - so smaller than default 16...) with the following commandline: start /low /b /wait java -enableassertions -jar -Xmx4200M mkgmap.jar --max-jobs=2 --reduce-point-density=5.4 --reduce-point-density-polygon=4 --suppress-dead-end-nodes --index --delete-tags-file=deletetags --blacklist-tags-file=deletetags --adjust-turn-headings --ignore-maxspeeds --ignore-turn-restrictions --remove-short-arcs=4 --location-autofill=1 --description=openmtbmap_%abr%_%date% --route --country-abbr=%abr% --country-name=%country% --mapname=%mapid%0000 --family-id=%mapid% --product-id=1 --series-name=openmtbmap_%abr%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapset --area-name=%country% d:\garmin\mkgmap_680\maps\%mapid%00%tile%.osm.gz At the latest on resolution=24 it crashes. If I use --generate-sea=no-mp;extend.... then it already crashes on resolution 22 (zoomlevel 700m). Simply center onto the city POI of Melbourne and zoom in. Same problem exists for Greece and Athens. (it's not related to the TYPfile - Mapsource also crashes without registered typfile). Reports I got indicate that the maps not only crash Mapsource but also BSOD Garmin GPS (though no damage done, except restart needed).

7 16

Re: [mkgmap-dev] multipolygon with outer polygon within inner polygons
by Minko 12 Feb '10

12 Feb '10

Those borderlines form part of different type of administration regions, (countries, provinces, municipalities etc). My question is not to understand why they are tagged like that, but how to make them render them well into mapsource. Is there some kind of patch I can try out, and where/how can I apply it? Im new regarding patching mkgmap, just using the latest release. Chris wrote: Hi, what I don't understand: Why is the complex MP processing for borders necessary while we are (mostly) only interested in the border _lines_ ? Chris

2 1

[PATCH v2] - fix Table C size bug + allow Table B to contain up to 255 entries
by Mark Burton 12 Feb '10

12 Feb '10

v2 - oops, the fix was flawed - try this one, sorry -------- Hopefully, this patch will fix Marco's routing problem in Rome. The bug is ancient (almost as old as Rome) but it hasn't shown itself much before now because it only causes a problem when one of the routing tables gets to a certain size which only occurs when there are quite a few turn restrictions within a small area. The patch also contains a mod to allow another of the routing tables to grow larger than it does now. Please could as many people as possible test this patch to check that routing doesn't bomb when using mapsource or a Nuvi in city areas with lots of roads and turn restrictions. Mark

3 5

Commit: r1569: Fix null pointer exception and corrected the
by svn commit 11 Feb '10

11 Feb '10

Version 1569 was commited by steve on 2010-02-11 20:05:44 +0000 (Thu, 11 Feb 2010) BRANCH: style-speed Fix null pointer exception and corrected the logic of creating nodes.

1 0

Problem with --adjust-turn-headings
by Steve Hosgood 11 Feb '10

11 Feb '10

Please look at http://www.openstreetmap.org/?mlat=51.44827&mlon=-3.49581&zoom=16&layers=B0… If you approach the marked junction on the B4270 from the south, intending to continue northwards on the B4268 then you get told "turn left" as you approach the junction with 300m or so to go. Trouble is, there is a minor road junctioning with the B4270 at about the same point on the road, and the geometry of the combined junction most certainly does not agree with a "turn left" for the B4268! The portion of the B4270 that continues to the north-east makes a junction with the B4268/B4270 as a "give way" on the road. The transition from the B4270 to the B4268 is seamless on the road. The minor road going west does of course join the B4270 as a "give way" on the road. You can see the physical details on Google Earth if you need more detail. But to hear "turn left in 300m" is most certainly a surprise! I'd expect no verbal instruction in this case. Steve

5 20

Continue behaviour changed?
by Mark Burton 11 Feb '10

11 Feb '10

I just noticed that the recent changes to the style engine have broken my map. I think it's possibly down to me using 'continue' in these rules (that appear before the rules that generate the roads): highway=* & bridge=yes { delete 'ref'; delete 'int_ref'; delete 'name'; } [0x010107 continue resolution 24] railway=* & bridge=yes { delete 'ref'; delete 'int_ref'; delete 'name'; } [0x010107 continue resolution 24] highway=* & tunnel=yes { delete 'ref'; delete 'int_ref'; delete 'name'; } [0x010e00 continue resolution 24] In the latest mkgmap, will these work as before? i.e. the bridge/tunnel lines will be generated without names and refs and the style engine will continue on to lower down my lines file where it will match rules for generating the routable roads (and the names/refs will be still around). Do I need any other keywords to make this work as before? Thanks, Mark

2 2