[mkgmap-dev] high-prec-branch ready for trunk?
From Gerd Petermann gpetermann_muenchen at hotmail.com on Tue Mar 4 07:54:31 GMT 2014
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-tp5793093.html 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-tp5791299.html 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140304/7012f2af/attachment.html>
- Previous message: [mkgmap-dev] Splitter and multiple input-files
- Next message: [mkgmap-dev] high-prec-branch ready for trunk?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list