I just tried the same using in DB storage. I found that the more or less
monotonic linear relationship with tile size (as was shown on my original
weblog post)   apparently still holds for in db rasters (which I used in
the original post). The overlay also remains much slower than R. (see the
figure in the recompiled doc in which I just removed the -R flag )

https://dl.dropboxusercontent.com/u/2703650/Courses/geostats/SpeedTestPointOverlay2.html

If these findings are generally robust I suppose that I should try to find
some time to compile them properly in order to add a comment and some
figures to the weblog.

Duncan


On Fri, Sep 20, 2013 at 12:16 AM, Duncan Golicher <[email protected]>wrote:

> Hi Bborie,
>
> OK, I might well have been thinking on old lines. So I tested again
> against the R extract function with the same data (this time on my slow
> laptop)
>
> https://dl.dropboxusercontent.com/u/2703650/SpeedTestPointOverlay.html
>
> You are quite right! With a tile size of 200 to 300 or so PostGIS now does
> beat the extract function in the raster package (although still slower with
> suboptimal tile sizes). This was certainly not the case when I tested a
> year ago (when all runs were several orders of magnitude slower unless tile
> size was  very small, in which case load time was prohibitive). ST_VALUE is
> now performing very differently (postgis2.2dev  compiled from source). More
> good news!
>
> Duncan
>
>
> On Thu, Sep 19, 2013 at 9:18 PM, Bborie Park <[email protected]> wrote:
>
>>
>> Note that the point on raster overlay can be beaten easily for speed by
>>> the extract function in the R raster package. However the polygon overlays
>>> are now very fast and compare well with any alternative way of getting the
>>> result. Using PLR to run  R functions within PostGIS is great if you want
>>> medians, quartiles etc or any other derived property.
>>>
>>>
>> I wonder what is going on to make the point on raster overlay in PostGIS
>> slower than in R. I'd have expected the numbers to be about the same as
>> that operation is conceptually very simple.
>>
>> -bborie
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> [email protected]
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>
>
>
>
> --
> Dr Duncan Golicher
> Investigador Titular,
> El Colegio de la Frontera Sur, Chiapas,Mexico
> Mexico tel +52 1 967 137 94 20
> Skype name duncangolicher
>
> Publications: http://www.mendeley.com/profiles/duncan-golicher
>
> Senior lecturer, Bournemouth University, UK
> Centre for Conservation Ecology & Environmental Change
> School of Applied Sciences
> Christchurch House rm C218a
> Bournemouth University
> Fern Barrow
> Poole (Dorset) BH12 5BB UK
> Tel. +44 (0)1202 961682
>
> For list of publications see Researcher ID:
> http://www.researcherid.com/rid/B-4240-2009
>
> [email protected]
> [email protected]
>
> Researcher ID:
> http://www.researcherid.com/rid/B-4240-2009
>



-- 
Dr Duncan Golicher
Investigador Titular,
El Colegio de la Frontera Sur, Chiapas,Mexico
Mexico tel +52 1 967 137 94 20
Skype name duncangolicher

Publications: http://www.mendeley.com/profiles/duncan-golicher

Senior lecturer, Bournemouth University, UK
Centre for Conservation Ecology & Environmental Change
School of Applied Sciences
Christchurch House rm C218a
Bournemouth University
Fern Barrow
Poole (Dorset) BH12 5BB UK
Tel. +44 (0)1202 961682

For list of publications see Researcher ID:
http://www.researcherid.com/rid/B-4240-2009

[email protected]
[email protected]

Researcher ID:
http://www.researcherid.com/rid/B-4240-2009
_______________________________________________
postgis-users mailing list
[email protected]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

Reply via email to