[mkgmap-dev] increase precision of node coordinates?
Hi! How to increase precision of node coordinates? mkgmap rounded the point coordinates in IMG format and map object have big distortion on large zoom. mapnik image: http://velo100mapper.googlecode.com/svn/trunk/test/img/map-precition- mapnik.png garmin img file (mkgmap output): http://velo100mapper.googlecode.com/svn/trunk/test/img/map-precition- garmin.png my commandline: http://code.google.com/p/velo100mapper/source/browse/trunk/makemap my mkgmap style: http://code.google.com/p/velo100mapper/source/browse/trunk/stranger/ my TYP: http://velo100mapper.googlecode.com/svn/trunk/stranger.typ --- wbr Maks ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] increase precision of node coordinates?
Hi Maks, I think it's a Garmin problem, the resolution of the Garmin's are not as fine as on Mapnik. See also this subject which is quite related to your question: http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07459.html ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error splitting binary files
Thanks, I'm following the discussion on talk-de. I just splitted netherlands.osm.pbf (08-Dec-2010 02:40) and it seems all the relations are gone. Lines and polygons are ok. I also mailed Frederik about this. The splitted europe.osm.pbf (benelux area) from today showed only some pois. BTW im using windows. aighes wrote: It seems to be an error in extract-file. Osmosis has also problems Frederik is informed about it (talk-de) and will take a closer look to it. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] increase precision of node coordinates?
Maks Vasilev schrieb am 08.12.2010 14:25: How to increase precision of node coordinates? In general there is no way to increase the precision of node coordinates. The only cause for problems is sometimes the remove-short-arcs option. I donÄt know whether there is a default value, so you could try setting it explicitly to zero and check, whether this will improve the map optics. But be aware: Setting this option to zero will break the routing. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Configurable flood blocker
On 05.12.2010 15:48, WanMil wrote: I committed r1746 to the coast branch. The floodblocker rules which OSM elements are used to detect land and as sea areas can now be configured in the special style resources/styles/floodblocker. If this style marks a ways as garmin type 0x01 the way is on land whereas 0x02 is used for sea. Now you can configure your own rules which tag combinations should be used for the flood blocking algorithm. Have fun! WanMil I have used it without problems, however currently all geofabrik extracts I had used (even Australia/Oceania or Lower Saxony) worked on the old version without problems too, while often these extracts caused severe flooding (haven't got any broken extracts saved however)... Also not really sure if my command line makes sense: /generate-sea=--generate-sea=extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=50,fbthres=500,fbratio=5/ (until now I have been using: /generate-sea=--generate-sea=polygons,extend-sea-sectors,close-gaps=6000/ ) I think it is safe to commit the coast branch to trunk (and maybe include some defaults in the help file, especially I have no clue about a sensible fbration value), I could not note any problems. Felix, thanks for testing! Yesterday I have committed that the multipolygon sea generation also creates land polygons. This should fix a shortcoming which prevented some users from using the mulitpolygon sea generation. What I am interested in at the moment: Does the external coastline file loading fit your needs? I am a bit concerned about memory requirements and would like to decrease its memory footprint. The following things should be done before merging back the branch to trunk: * Improve multipolygon processing performance for sea polygons. The mp algorithm can count on the outer and inner tags so the matrix which polygon is contained by which polygon should be less complex to create * @Steve: Can you check if my changes to the ElementSaver class and my coastfile loading mechanism feels good for you? Maybe you want to simplify some things? * Decrease memory footprint of the coastline file loading. (Maybe this could also be done after merging back). Have fun! WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Configurable flood blocker
On 08.12.2010 20:50, WanMil wrote: On 05.12.2010 15:48, WanMil wrote: I committed r1746 to the coast branch. The floodblocker rules which OSM elements are used to detect land and as sea areas can now be configured in the special style resources/styles/floodblocker. If this style marks a ways as garmin type 0x01 the way is on land whereas 0x02 is used for sea. Now you can configure your own rules which tag combinations should be used for the flood blocking algorithm. Have fun! WanMil I have used it without problems, however currently all geofabrik extracts I had used (even Australia/Oceania or Lower Saxony) worked on the old version without problems too, while often these extracts caused severe flooding (haven't got any broken extracts saved however)... Also not really sure if my command line makes sense: /generate-sea=--generate-sea=extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=50,fbthres=500,fbratio=5/ (until now I have been using: /generate-sea=--generate-sea=polygons,extend-sea-sectors,close-gaps=6000/ ) I think it is safe to commit the coast branch to trunk (and maybe include some defaults in the help file, especially I have no clue about a sensible fbration value), I could not note any problems. Felix, thanks for testing! Yesterday I have committed that the multipolygon sea generation also creates land polygons. This should fix a shortcoming which prevented some users from using the mulitpolygon sea generation. okay great, I prefer multipolygon mode (makes maps without land/sea overlap if --transparent is used). What I am interested in at the moment: Does the external coastline file loading fit your needs? I am a bit concerned about memory requirements and would like to decrease its memory footprint. I have not tried that out yet - I usually only compile single geofabrik country extracts (and Africa, South-America and Australia-Oceania Extracts). For external coastlines to be useful, I'ld need them handy to mix with the geofabrik extracts... Suppose if coastlines for the extracts were available, that would be the best thing... -- Where can one get coastline extracts - anyone providing them? The following things should be done before merging back the branch to trunk: * Improve multipolygon processing performance for sea polygons. The mp algorithm can count on the outer and inner tags so the matrix which polygon is contained by which polygon should be less complex to create * @Steve: Can you check if my changes to the ElementSaver class and my coastfile loading mechanism feels good for you? Maybe you want to simplify some things? * Decrease memory footprint of the coastline file loading. (Maybe this could also be done after merging back). Have fun! WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
