logo separator

[mkgmap-dev] [PATCH V1] Idea for minor speed improvement for boundary preprocessing

From GerdP gpetermann_muenchen at hotmail.com on Fri Feb 24 14:12:24 GMT 2012

Hi WanMil,

this was a very good hint :-)

Time for african boundaries was 250 secs with /branch/performance/r2225, 267
secs with trunk, 
and with this patch it is now 152 secs 

- use simple quadtree in BoundarySaver.splitArea()
- add try/catch in BoundaryPreparer.run() to allow e.g. usage of assert.
Without that,
an assertion was handled by the threading routines and caused program stop
without any 

Please double check this, I am still not so experienced 
with try+catch and wrong placed



WanMil wrote
> 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
> _______________________________________________
> 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-V1-Idea-for-minor-speed-improvement-for-boundary-preprocessing-tp5512906p5512906.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.

More information about the mkgmap-dev mailing list