February 2012 - mkgmap-dev - The mkgmap lists

Downloading pbf files
by Roger Calvert 23 Feb '12

23 Feb '12

I have found in the last couple of days that Firefox (which updated itself recently) tries to open pbf files from the geofabrik depository rather than downloading them. Has anyone else noticed this? If so, have you found a solution? (A work round is to use Save As, but this should not be, and never used to be, necessary.) Thanks, Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------

8 10

Idea for minor speed improvement for boundary preprocessing
by WanMil 23 Feb '12

23 Feb '12

Hi Gerd, boundary preprocessing takes quite a lot of time. That's not a big problem because it's performed only by some people who publish their results. But I think some speed improvements would not be bad anyhow?! While preprocessing asia and america I go an idea. The area of a boundary is splitted into the raster. But each time the complete area is intersected to the raster. In case an area is big and/or complex (boundary of russia, USA, canada etc.) this takes a long time. It would be possible first to cut the area into smaller pieces (columns or rows of the raster) and then do the final cut to the raster. Maybe this saves time because the column or row areas should be less complex. What do you think? WanMil

2 1

Precompiled coastlines
by GerdP 23 Feb '12

23 Feb '12

Hi, some weeks ago WanMil wrote > ... > All in all: Please keep the format of the bnd files as simple as > possible and think about using it for other purposes. e.g. the current > format could easily be used for coastline processing - one can > precompile the coastlines and mgkmap could load the sea areas from the > precompiled sea file. This would be great to have (a big!! performance > and quality improvement). But someone needs to implement that. > I looked at the sources now and see two ways how to do that: 1) We can write the result of SeaGenerator.joinWays() or 2) We can write the result of SeaGenerator.end() pro 1): this will produce files that are usable for all, no matter what optionsthe user wants to use in generate-sea parm, so it can be downloaded like the precompiled boundaries. pro 2): this should reduce the CPU time even more, but every user has to create his own file(s) Any ideas what will be better? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Precompiled-coastlines-tp5507867p5507867.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 2

feature-request - variable copyright information
by aighes 23 Feb '12

23 Feb '12

Hi, MapSource shows as copyright information the following lines: /Map created with mkgmap-r2220 Map data licenced under Creative Commons Attribution ShareAlike 2.0 OpenStreetMap and contributors Program released under the GPL http://creativecommons.org/licenses/by-sa/2.0/ www.openstreetmap.org/ In near future OSM will change the licence, so I think Garmin-maps could also released with other licences than cc-by-sa. So it would be great to chage these lines to a fix part /Map created with mkgmap-r2220 / /Program released under the GPL / and a variable part for the licence of the map and licence information of the input. this could be done in a txt-file. If there is no txt-file, there should be a default. Henning

4 14

[Patch v6] LocationHook with new Quadtree
by GerdP 21 Feb '12

21 Feb '12

Hi WanMil, attached patch corrects the known problems, it removes some debug or dead code and starts to complete javadoc. http://gis.19327.n5.nabble.com/file/n5499705/boundary_prep_quadtree_v6.patch boundary_prep_quadtree_v6.patch I did not yet fully understand the concept of the FutureTask, so I didn't dare to change BoundaryPreparer. I got the impression that this will require a lot more code in main, because we have to finish all preparer threads first. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v6-LocationHook-with-new-Quadtree-tp54… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 2

[PATCH V4] boundary preparer with quadtree
by GerdP 20 Feb '12

20 Feb '12

Hi WanMil, attached is the new patch for the performance branch. Its quite big because I've rewritten many methods to work with the quadtree instead of List<boundary> Major changes: - new file format for *.bnd files. It stores first the boundary tags, then the areas with float precision. The file size is not much different from the old format, but when zipped it is much smaller. The time to load the file into the quadtree is shorter than the time to load the old format. The old format is still supported, but requires much more time in the LocationHook (probably it is still faster than trunk, but not much) - the bounds parameter allows now to specify a zip file with the *.bnd files. The zip file can have a directory structure, but should not contain duplicate *.bnd files. - BoundaryPreparer uses multiple processors for the workoutBoundaryRelations() part when --max-jobs parameter allows it. When called as stand-alone program, it starts one thread for each processor. - the utilities BoundaryDiff, BoundaryMerger, BoundaryFile2Gpx, BoundaryLister were rewritten to use the quadtree, most of them also allow *.zip as input. BoundaryLister lists only the OSM tags, not the information created for the quadtree. Can be changed if needed. Open problem: The BoundaryMerger creates a result that contains a few more small holes than the trunk version. I'm going to analyse that during the next days. Todo: Javadoc Ciao, Gerd http://gis.19327.n5.nabble.com/file/n5495676/boundary_prep_quadtree_v4.patch boundary_prep_quadtree_v4.patch -- View this message in context: http://gis.19327.n5.nabble.com/PATCH-V4-boundary-preparer-with-quadtree-tp5… Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 12

creating precompiled boundaries with Derby DB?
by GerdP 20 Feb '12

20 Feb '12

Hi, would it be okay to change the BoundaryPreparer so that it (optionally) stores data in a Derby DB instead of keeping everything on the heap? http:////http://www.oracle.com/technetwork/java/javadb/overview/index.html Java DB Due to the growth of the OSM data I can no longer create europe *.bnd files with -Xmx2800m (which seems to be the max. value on my machine) I think the current process of extracting boundary data with osmconvert and osmfilter is already quite complex, and maybe a simple DB will help. The idea: The BoundaryElementSaver could store the data in a DB(maybe only the coord data). This would allow to create the *.bnd files with less than 1GB of memory. Any objections against this? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/creating-precompiled-boundaries-with-Derby-D… Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 4

Commit: r2220: After sorting the zip codes, must set the index in the sorted array
by svn commit 20 Feb '12

20 Feb '12

Version 2220 was commited by steve on 2012-02-20 19:24:01 +0000 (Mon, 20 Feb 2012) After sorting the zip codes, must set the index in the sorted array and use that. This means that the full zip record must be passed the POIrecord so that the index can be extracted after it set after sorting.

1 0

Commit: r2215: Sort the zip codes.
by svn commit 20 Feb '12

20 Feb '12

Version 2215 was commited by steve on 2012-02-20 13:35:46 +0000 (Mon, 20 Feb 2012) Sort the zip codes.

1 0

compiling typ txt file error
by Minko 20 Feb '12

20 Feb '12

The latest typ viewer editor (3.5.20) from https://sites.google.com/site/sherco40/home generates a comments section in the txt file where mkgmap's compiler gets stuck: ;=========== COMMENTAIRES ====== [_comments] [End] Is it possible to ignore thse unknown sections?

2 1