[postgis-users] tile size

[Duncan Golicher]

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 <dgolicher at gmail.com>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 <dustymugs at gmail.com> 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
>> postgis-users at lists.osgeo.org
>> 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
>
> dgolicher at bournemouth.ac.uk
> dgoliche at ecosur.mx
>
> 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

dgolicher at bournemouth.ac.uk
dgoliche at ecosur.mx

Researcher ID:
http://www.researcherid.com/rid/B-4240-2009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20130920/dc32b64b/attachment.html>