logo separator

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

From WanMil wmgcnfg at web.de on Mon Feb 20 20:43:17 GMT 2012

Hi Gerd,

using the serialization means that you will always have to use the 
Path2D class to read it. You cannot use another lib with better 
functionality without changing the format. Also other programming 
languages do not have a real chance to read the files.
So unless there is a big advantage regarding size or speed I would not 
use the Java serialization.

WanMil

> Hi WanMil,
>
> fine. Yes, it makes no sense, but I see no reason why it should not produce
> a result that is more or less identical to the input. By the way, today I
> learned that Path2D is serializable, do you thing we should prefer the
> writeObject() method to store the shape info?
>
> Gerd
>
>
> WanMil wrote
>>
>> Hi Gerd,
>>
>> thanks. It's working now.
>>
>> I think it does not make any sense to start the BoundaryMerger with
>> identical dir1 and dir2. There would be nothing to merge. So this can be
>> checked and either an error message is issued and the program exits or
>> dir1 is just copied to the merge directory.
>>
>> WanMil
>>
>>> Hi WanMil,
>>>
>>> I think the problem was caused by mixed usage of dir1.getName() and
>>> dir1.getAbsolutePath().
>>>
>>> Please try the attached patch.
>>>
>>> I think the BoundaryMerger doesn't work yet, when you specify the same
>>> directory for dir1 and dir2, it sometimes creates files that are much
>>> larger
>>> than the input. I'm going to look at this tomorrow.
>>>
>>> Gerd
>>>
>>> http://gis.19327.n5.nabble.com/file/n5496926/boundary_prep_quadtree_v5.patch
>>> boundary_prep_quadtree_v5.patch
>>>
>>>
>>> WanMil wrote
>>>>
>>>> Hi Gerd,
>>>>
>>>> the only message I have in the log file is:
>>>> 2012/02/19 14:08:34 Schwerwiegend (BoundaryUtil): Cannot read asia
>>>> 2012/02/19 14:08:35 Schwerwiegend (BoundaryUtil): Cannot read tomerge
>>>>
>>>> WanMil
>>>>
>>>>
>>>>> Hi WanMil,
>>>>>
>>>>> do you see messages in the log, e.g. "Cannot load boundary file" ?
>>>>> If yes, please provide the content of the two *.bnd files.
>>>>> I think in such a case the merger should stop with some speaking error
>>>>> message.
>>>>> Do you agree?
>>>>>
>>>>> Gerd
>>>>>
>>>>>    >   Date: Sun, 19 Feb 2012 13:20:03 +0100
>>>>>    >   From: wmgcnfg@
>>>>>    >   To: mkgmap-dev at .org
>>>>>    >   Subject: Re: [mkgmap-dev] [PATCH V4] boundary preparer with
>>>>> quadtree
>>>>>    >
>>>>>    >   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 .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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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-tp5495676p5496926.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-tp5495676p5497615.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




More information about the mkgmap-dev mailing list