Commit: r1893: Add option to control the smallest polygon that is displayed
Version 1893 was commited by steve on 2011-03-09 22:18:10 +0000 (Wed, 09 Mar 2011) Add option to control the smallest polygon that is displayed at lower resolutions. - Johann Gail The default remains at 8, but it can now be adjusted. ..Steve
Thanks, Steve. Could you also commit Nakors latest patch regarding the installer which includes the typ file into the windows register? I think it's quit urgent when you use a typ file (he forgot that in the patch that was commited) Cheers, Minko ----- Oorspronkelijk bericht ----- Van: svn commit <svn@mkgmap.org.uk> Aan: mkgmap-svn@lists.mkgmap.org.uk Verzonden: Wed, 09 Mar 2011 23:18:11 +0100 (CET) Onderwerp: [mkgmap-dev] Commit: r1893: Add option to control the smallest polygon that is displayed Version 1893 was commited by steve on 2011-03-09 22:18:10 +0000 (Wed, 09 Mar 2011) Add option to control the smallest polygon that is displayed at lower resolutions. - Johann Gail The default remains at 8, but it can now be adjusted. ..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Why did you change the merge-lines text at the same time? --merge-lines Try to merge lines. This helps the simplify filter to straighten out longer chunks at lower zoom levels. Decreases file size more. Increases paint speed at low zoom levels. *At the moment this option causes routing errors. Use only if routing is not needed in your map.* Where is any reference to this causing routing errors. Routing is only on res=24, though merge-lines now by default starts at res=22 (and even before ran after routing - which causes display panning problems and maybe label problems, but no changes on routing as such. Also the max error is now much smaller (1/4) compared with the old behaviour). On 09.03.2011 23:18, svn commit wrote:
Version 1893 was commited by steve on 2011-03-09 22:18:10 +0000 (Wed, 09 Mar 2011)
Add option to control the smallest polygon that is displayed at lower resolutions.
- Johann Gail
The default remains at 8, but it can now be adjusted.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Why did you change the merge-lines text at the same time?
--merge-lines Try to merge lines. This helps the simplify filter to straighten out longer chunks at lower zoom levels. Decreases file size more. Increases paint speed at low zoom levels. *At the moment this option causes routing errors. Use only if routing is not needed in your map.*
Where is any reference to this causing routing errors. Routing is only on res=24, though merge-lines now by default starts at res=22 (and even before ran after routing - which causes display panning problems and maybe label problems, but no changes on routing as such. Also the max error is now much smaller (1/4) compared with the old behaviour).
This text was added in my patch as a side note while editing the help file. I have never watched routing errors for myself, but the internal data structures gets corrupted. AFAIR there was a problem with the drawing of the pink line. The routing layer should be intact, but some internal references at the lower resolutions are wrong. If the maps work for you even with routing, then well, its okay, use it and enjoy. But I expect strongly some side effects, so I added this warning. It is simply a warning, not more and not less. Regards, Johann
On 10.03.2011 18:09, Johann Gail wrote:
Why did you change the merge-lines text at the same time?
--merge-lines Try to merge lines. This helps the simplify filter to straighten out longer chunks at lower zoom levels. Decreases file size more. Increases paint speed at low zoom levels. *At the moment this option causes routing errors. Use only if routing is not needed in your map.*
Where is any reference to this causing routing errors. Routing is only on res=24, though merge-lines now by default starts at res=22 (and even before ran after routing - which causes display panning problems and maybe label problems, but no changes on routing as such. Also the max error is now much smaller (1/4) compared with the old behaviour).
This text was added in my patch as a side note while editing the help file. I have never watched routing errors for myself, but the internal data structures gets corrupted. AFAIR there was a problem with the drawing of the pink line. The routing layer should be intact, but some internal references at the lower resolutions are wrong. If the maps work for you even with routing, then well, its okay, use it and enjoy. But I expect strongly some side effects, so I added this warning. It is simply a warning, not more and not less.
Well on my tries routing stayed 1:1. Only the tooltip is showing up at wrong places on the map - and once you drag/pan the map, the engine thinks you panned it from the wrongly showing place, leading to a big jump. This error gets smaller by 50% on each resolution down. Therefore it only really matters for resolution 23 and 24, and the reason for the change a few revisions back, was to get the worst noticeable problems away. There are options that cause far more problems like --ignore-osm-bounds or not using remove-short-arcs (this should be default when --route is given because if not used routing really gets broken for any highway that has segments shorter than 2.8m),or --link-pois-to-ways which makes gps crash on search and one map using it destroys search for all other maps on many GPS units. Also lower-case which is known to cause loads of errors (without any indication of it working). While transparent and show-profiles may be problematic if you don't understand exactly what they do. Close-gaps and floodblocker should be default if sea is generated (would save lots of people complaining about sea overflowing while the problem is in OSM data).
Regards, Johann
participants (4)
-
Felix Hartmann -
Johann Gail -
Minko -
svn commit