high-prec-branch ready for trunk?

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-tp5793... 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-t... 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.

On Tue, Mar 04, Gerd Petermann wrote:
If I hear no complains I'll merge on March 6.
Fine with me, I'm using that branch already for my maps and haven't heard anything negative back yet. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

Hi Thorsten, thats good to now, thanks! Gerd
Date: Tue, 4 Mar 2014 09:07:48 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] high-prec-branch ready for trunk?
On Tue, Mar 04, Gerd Petermann wrote:
If I hear no complains I'll merge on March 6.
Fine with me, I'm using that branch already for my maps and haven't heard anything negative back yet.
Thorsten
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (6)
-
Andrzej Popowski
-
Gerd Petermann
-
Henning Scholland
-
Minko
-
Steve Ratcliffe
-
Thorsten Kukuk