[mkgmap-dev] [PATCH V4] boundary preparer with quadtree

Sun Feb 19 12:20:03 GMT 2012

Hi Gerd,

merging of africa, australia-oceania did work (but I think they have no 
bnd file in common). Merging of asia to them failed at the first file.

WanMil

> Hi WanMil,
>
> thanks. Reg. the error: I have to add some tests to make sure that the
> BoundaryQuadTree object was created.
> Did the program already process some bnd files or did that happen right
> after the program start?
>
> Gerd
>
>
>
> WanMil wrote
>>
>> Hi Gerd,
>>
>> thanks for that patch. It's a big step forward :-)
>> I've comitted it and also merged all changes from the trunk so that the
>> branch does not diverge too much.
>>
>> I tried to compile boundaries for an old planet file but got an
>> exception in the BoundaryMerger:
>> Exception in thread "main" java.lang.NullPointerException
>>           at
>> uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryMerger.merge(BoundaryMerger.java:93)
>>           at
>> uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryMerger.main(BoundaryMerger.java:144)
>>
>> Can you have a look on it?
>> Thanks!
>>
>> WanMil
>>
>>> 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-tp5495676p5495676.html
>>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at .org
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at .org
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>
> --
> View this message in context: http://gis.19327.n5.nabble.com/PATCH-V4-boundary-preparer-with-quadtree-tp5495676p5496815.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev