[mkgmap-dev] [PATCH V4] boundary preparer with quadtree
From GerdP gpetermann_muenchen at hotmail.com on Sun Feb 19 21:55:24 GMT 2012
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.
- Previous message: [mkgmap-dev] [PATCH V4] boundary preparer with quadtree
- Next message: [mkgmap-dev] [PATCH V4] boundary preparer with quadtree
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list