- mkgmap-dev - The mkgmap lists

Commit: r3081: merge from the high-prec-coord branch.
by svn commit 06 Mar '14

06 Mar '14

Version mkgmap-r3081 was committed by gerd on Thu, 06 Mar 2014 merge from the high-prec-coord branch. The expected effects are: - improved routing - less distorted lines caused by rounding to map units - smaller map size (~ 10%) because of various optimizations - larger "precompiled" sea and bounds data (~30%) - increased mkgmap run time (~ 10%)

6 10

Splitter and multiple input-files
by Henning Scholland 06 Mar '14

06 Mar '14

Hi Gerd, I discovered a (small) problem with using two inputfiles with splitter. One input-file is planet.osm, the other one is a srtm-files covering only a few areas. If I split an area, which is not covered by the bbox of my srtm-file, splitter wont write any areas.list and so on. Would it be possible to merge the bboxes of the input-files or check, that the required area is coverd at least by one input and not necessarily by all? Henning

3 8

Commit: r3076: Merge from the sort branch.
by svn commit 05 Mar '14

05 Mar '14

Version mkgmap-r3076 was committed by steve on Tue, 04 Mar 2014 Merge from the sort branch. This solves multiple problems searching for addresses when the default ascii character set is used, or when many characters cannot be represented in the target character set and have to be transliterated. Complete sort tables for code-pages: 1250, 1251, 1252, 1253, 1254, 1255, 1256, 1257 and 1258. A few corrections to the sorting algorithm so that sorting by sort-keys always gives the same result as sorting using the Collator. If anyone uses there own sort descriptions, then there is one change: everything is in terms of unicode. The file itself should be in utf-8 as before, but all characters with numeric references should be in unicode, rather than the target character set. There are numerous internal changes that are the beginnings of unicode support, but these changes are not visible, so unicode maps will still not be searchable.

4 6

Commit: r3080: Merge assertion fix from sort branch.
by svn commit 05 Mar '14

05 Mar '14

Version mkgmap-r3080 was committed by steve on Wed, 05 Mar 2014 Merge assertion fix from sort branch.

1 0

error in mkgmap reg. toll roads
by Gerd Petermann 05 Mar '14

05 Mar '14

Hi all, Steve just found out that we have a bug in the NOD header which is related to the drive-on-left option: Only if this option is enabled we set one bit in the header which has a big influence on the routing: You have to switch on "avoid toll roads" in MapSource and Basecamp to be able to route on major roads Instead this bit should always be set, no matter what drive-on-xxx option is used. This bug is very old and I noticed that some people use toll roads in their style. So I wonder if anybody relies on the wrong behaviour or why nobody complained until now? Gerd

1 0

Distorted lines
by Andrzej Popowski 05 Mar '14

05 Mar '14

Hi, I observe badly looking lines. I have attached some pictures and xml objects that doesn't look good on Garmin map. My guess is that there is no proper simplifications for resolution 24bit. Points too dense are removed in a non optimal way which can lead to jagged curves. This could be the reason for bad looking tram railways (file tram1.osm in test.zip). Other reason could be removing of short lines. I think in this case some nodes are moved. It looks like instead of creating a new node in a middle of removed line, first point is used. This can lead to bigger distortion. This is probably the case of road example (file road1.osm). -- Best regards, Andrzej

10 40

removed remove-short-arcs option in r3077
by Gerd Petermann 05 Mar '14

05 Mar '14

Hi all, with r3077 I've removed the remove-short-arcs option in the high-prec-coord branch. Gerd

2 2

high-prec-branch ready for trunk?
by Gerd Petermann 04 Mar '14

04 Mar '14

Hi all, I think the branch is ready as it is. Steve and I are still working on a new algo to calculate the NOD data (routing information), but this doesn't depend on high precision and should be done in a different branch. In short, the branch produces smaller img files with nicer looking lines and shapes and slightly improved routing and requires around 10% more cpu time. If I hear no complains I'll merge on March 6. Gerd P.S. The more detailed changes in the branch compared to trunk r3072 are: 1) the program keeps the higher precision of OSM data ( precision ~ 5 cm, presuming that OSM data is precise) and tries to detect situations where the rounding to Garmin map units (precision ~ 2.4 m) causes distorted lines. The effects are "rounder" roundabouts and "straigter" straight roads. A nice side effect is that the algo drops a lot of points which makes img size smaller. 2) polygons with equal attributes are merged and the remaining points are filtered to also remove distortions. The positive effects are - smaller img size - nicer looking buildings, see previous post http://gis.19327.n5.nabble.com/shape-merger-in-high-prec-coord-branch-tp579… A negative effect of the current implementation is that two different algos are used for lines and shapes, e.g. coastlines may differ from the sea shapes. It is planned to correct that in the near future . 3) Restriction relations are no longer written in a format that prohibits pedestrians and emergency (unless the style requests that) 4) the code for the option --link-pois-to-ways was rewritten, see http://gis.19327.n5.nabble.com/Patch-v2-link-pois-to-ways-and-restrictions-… 5) a few optimizations and corrections in the NOD data reduce the size of the NOD file and seem to correct some routing problems. This is not related to high-precision. 6) Precompiled boundary and sea data is ~30% larger as it contains more points, and also calculaion time for them increased (this is related to higher precision). It is probably possible to change that also, for now that means larger downloads.

6 6

Limit in MapSplitter
by Gerd Petermann 04 Mar '14

04 Mar '14

Hi all, we have a limit in mkgmap that doesn't allow to have more than 255 POI in an area of 10x10 map units. If this limit is reached, you see the "Area too small to split at ...(reduce the density of points, length of lines, etc.)" message Technically it is no problem to solve this, e.g. we can create overlapping areas and distribute the points, but I wonder if that would be of any use? Gerd

1 0

[Patch v1] ignore duplicate POI
by Gerd Petermann 04 Mar '14

04 Mar '14

Hi all, attached patch ignores repeated POI, typically generated by the --add-poi-to-line feature in combination with a style that doesn't check the mkgmap:line2poitype=inner tag. If two or more POI with equal tags appear in sequence. This might help to avoind the problem reported by Stephen. @Stephen: I think you should also check your style. Did you change it as requested here ? http://www.mkgmap.org.uk/news/2013/12/22/more-flexibility-in-style-files-st… Gerd

1 0