- mkgmap-dev - The mkgmap lists

Commit: r1178: Confidently increase the values of MAX_RGN_SIZE and MAX_NUM_LINES.
by svn commit 07 Sep '09

07 Sep '09

Version 1178 was commited by markb on 2009-09-07 11:51:05 +0100 (Mon, 07 Sep 2009) Confidently increase the values of MAX_RGN_SIZE and MAX_NUM_LINES.

1 0

Commit: r1177: Take into account the fact that lines can be split when counting them.
by svn commit 07 Sep '09

07 Sep '09

Version 1177 was commited by markb on 2009-09-07 11:51:02 +0100 (Mon, 07 Sep 2009) Take into account the fact that lines can be split when counting them.

1 0

Commit: r1176: Don't add subsequent identical points.
by svn commit 07 Sep '09

07 Sep '09

Version 1176 was commited by markb on 2009-09-07 11:50:59 +0100 (Mon, 07 Sep 2009) Don't add subsequent identical points.

1 0

Commit: r1175: Don't add 0.5 to boundary point coordinates when clipping.
by svn commit 07 Sep '09

07 Sep '09

Version 1175 was commited by markb on 2009-09-07 11:50:56 +0100 (Mon, 07 Sep 2009) Don't add 0.5 to boundary point coordinates when clipping. Doing that caused some points to not actually be on the boundary. Now asserts that the clipped lines really do end on the boundary.

1 0

Commit: r1174: "Soft clip" ways before doing short arc removal.
by svn commit 07 Sep '09

07 Sep '09

Version 1174 was commited by markb on 2009-09-07 11:50:52 +0100 (Mon, 07 Sep 2009) "Soft clip" ways before doing short arc removal. To avoid the problem of short arcs being generated when ways are clipped after the short arc removal has been done, we now "soft clip" the ways before short arc removal by adding nodes where the ways meet the boundary. These boundary nodes are "set in concrete" and cannot be merged into other nodes so their coordinates will not change.

1 0

problem routing across tiles again
by maning sambale 07 Sep '09

07 Sep '09

Hi, I encountered routing across tiles again. Using mkgmap ver 1163 and splitter r83. This photo shows routing detours to the cemetery when I used a split file: http://farm3.static.flickr.com/2593/3892530364_d80a7546b4_o.png But no problems when no split file was used: http://farm3.static.flickr.com/2499/3891743809_21048450de_o.png -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

2 10

POI's don't show in the 3d or routing mode
by maning sambale 07 Sep '09

07 Sep '09

hi, Anyone encountered this issue? Using custom typ file for POIs and roads, POI's don't show in the 3d display or routing mode on nuvi200. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

1 1

New splitter version, big memory savings
by Chris Miller 06 Sep '09

06 Sep '09

I've just checked in a new version of the splitter (r84) that requires far less memory and also performs slightly better during the first stage of the split. As an example, it used to take about a 5GB heap to generate areas.list for the whole planet, but now only takes around 300MB(!). An additional advantage is that as the planet grows in size and complexity going forwards, the memory required during the first stage will not increase. This change should finally mean that anyone is able to split the planet even on a relatively low end machine (though be prepared for a long wait!). If you try but run out of memory during the second stage of the split (ie after areas.list has been generated), reduce the value of --max-areas. This will reduce the memory required during that second stage, at the cost of additional passes over the data (if you do require multiple passes then I highly recommend you also use the --cache option, it can make a huge difference to performance). One possible downside to this new version is the algorithm that decides how to split up the map has been changed somewhat. This results in slightly different tile layouts compared to the old algorithm. This shouldn't be too noticable unless perhaps it puts a tile boundary right through somewhere you care about when the old algorithm didn't. Of course, it may also work in your favour for the same reason! My experiments have shown the number of tiles generated increases by about 2% with the new approach which I think is a small price to pay for the huge memory saving. I've put some example kml files online here that show the before and after effects of the change: UK --max-nodes=1600000 old splitter: http://maps.google.co.uk/maps?q=http:%2F%2Fredyeti.net%2Fosm%2Fuk-original.… new splitter: http://maps.google.co.uk/maps?q=http:%2F%2Fredyeti.net%2Fosm%2Fuk-density.k… Europe --max-nodes=1600000 old: http://maps.google.co.uk/maps?q=http:%2F%2Fredyeti.net%2Fosm%2Feurope-origi… new: http://maps.google.co.uk/maps?q=http:%2F%2Fredyeti.net%2Fosm%2Feurope-densi… Europe --max-nodes=300000 old: http://maps.google.co.uk/maps?q=http:%2F%2Fredyeti.net%2Fosm%2Feurope-300k-… new: http://maps.google.co.uk/maps?q=http:%2F%2Fredyeti.net%2Fosm%2Feurope-300k-… Planet --max-nodes=1600000 old: http://maps.google.co.uk/maps?q=http:%2F%2Fredyeti.net%2Fosm%2Fplanet-origi… new: http://maps.google.co.uk/maps?q=http:%2F%2Fredyeti.net%2Fosm%2Fplanet-densi… If you aren't happy with the new tiles, or simply want to compare the new with the old, there's a parameter --legacy-mode=true that will generate areas.list using the old approach. Assuming there aren't any serious problems that come to light I'll be removing that parameter in a future build. Where to from here? As some of you may have guessed, this new splitter is based on a 'density map' as discussed in earlier mails. Currently it maps the density of nodes only, and the generated map is only held in memory long enough to calculate the tile boundaries. I indend to write this map out to disk so it can be used by external tools, or reused on successive runs of the splitter to allow extremely quick generation of areas.list with different --max-nodes settings. After that I hope to tackle the quite difficult problem (in terms of performance and memory overhead) of generating density maps for ways and relations too. Once we have density maps for all three element types it will hopefully be possible to generate tiles that are as big as possible but still avoid giving 'Map to big' messages. Another related area I'm starting to look at is new/improved algorithms for arranging the tiles so they eg avoid putting boundaries through the middle of cities, or reduce the overall number of tiles. Any ideas here would be appreciated. Enjoy! Chris

7 15

Re: [mkgmap-dev] mkgmap creates polygons that break Mapsource panning and also routing in some zoomlevels as well as crashing the GPS
by Mark Burton 06 Sep '09

06 Sep '09

Felix, > Okay, here are the output files. Once including the problematic > landuse=* line, once without. Thanks. Unfortunately, they have too much other crap in them and not enough of what I want to see. Did you use the logging.properties file I sent to you? Mark

2 12

Commit: r1173: Avoid generating degenerate lines/areas with too few points.
by svn commit 06 Sep '09

06 Sep '09

Version 1173 was commited by markb on 2009-09-06 14:10:28 +0100 (Sun, 06 Sep 2009) Avoid generating degenerate lines/areas with too few points.

1 0