logo separator

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

From GerdP gpetermann_muenchen at hotmail.com on Fri Mar 2 16:18:45 GMT 2012

Hi WanMil,

yes, your solution is better. I wanted to do it in the same way, but failed
to find the 
correct tile sizes for areas that cover e.g. 7 split rectangles (the middle
is not on the grid)

two small points:
1) the variable names midLon and midLat are a bit missleading, since you
don't split in the middle, but near the middle (which perfectly solves my
problem described above)

2) You removed my added try/catch from BoundaryPreparer.run()
I hope you found a better solution? I needed it there to make assert work in
e.g. splitArea()

Gerd


WanMil wrote
> 
> Hi Gerd,
> 
> that's great!
> 
>> 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
> 
> wow, that's more improvement than I expected.
> 
>>
>> - use simple quadtree in BoundarySaver.splitArea()
> 
> You are a quadtree guy.
> In this case I thinks it's more irritating and complex to split the area 
> into four subareas. I've changed that to split into two subareas and the 
> code is now much easier to read (I think so..?!?) and performs in 
> similar speed.
> 
> WanMil
> 
>> - 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
>> message.
>>
>> Please double check this, I am still not so experienced
>> with try+catch and wrong placed
>>
>> Ciao,
>> Gerd
>>
>> http://gis.19327.n5.nabble.com/file/n5512906/splitArea_v1.patch
>> splitArea_v1.patch
>>
>>
>> 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.
>> _______________________________________________
>> 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-V1-Idea-for-minor-speed-improvement-for-boundary-preprocessing-tp5512906p5531433.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.



More information about the mkgmap-dev mailing list