[gdal-dev] The slowness of gdal_grid

Tamas Szekeres szekerest at gmail.com
Fri Oct 31 17:32:59 EDT 2008


Even,

Does this approach provide a significant performance increment
comparing to the search ellipse option in the inverse distance
algorithm?

When I've been recently playing with gdal_grid I could gain further
increment by reducing the number of the floating point operations in
the inner loop of the algorithm (see
GDALGridInverseDistanceToAPowerNoSearch for example), like:

1. Getting out the dfSmoothing * dfSmoothing multiplication from the loop
2. In case when dfPower = 2 we could save using of sqrt and pow at all.
3. Replace CPLIsEqual with a faster approach

It must be noted that I had no chance to rely on the assumption that
the distant points doesn't affect the value of the result, especially
when the points are based on non-geograpic related quantities.

Best regards,

Tamas



2008/10/31 Even Rouault <even.rouault at mines-paris.org>:
> Ari,
>
> the slowness of gdal_grid when fed with a big number of point features is a
> known issue. See ticket #2411. I had attached a patch to speed up the
> process. You could give it a try.
>
> Le Friday 31 October 2008 08:09:11 Ari Jolma, vous avez écrit :
>> I'm doing some laser scanning data -> geotiff interpolations and I'm
>> finding that they take some time - the current run has been going on for
>> ~20 hours now.
>>
>> The current run is for a 3 by 2 kilometer area, which I'm interpolating
>> into a raster with 1 m x 1 m cells. The data is in PostGIS but it
>> shouldn't matter:
>>
>> gdal_grid -a invdist:radius1=10:radius2=10 -txe 3350505 3353786 -tye
>> 6692068 6694105 -outsize 3281 2037 -of GTiff -ot Float32 -l nummela
>> PG:dbname=nummela nummela.tiff
>> Grid data type is "Float32"
>> Grid size = (3281 2037).
>> Corner coordinates = (3350504.500000 6694105.500000)-(3353786.500000
>> 6692067.500000).
>> Grid cell size = (1.000000 1.000000).
>> Source point count = 2588809.
>> Algorithm name: "invdist".
>> Options are
>> "power=2.000000:smoothing=0.000000:radius1=10.000000:radius2=10.000000:angl
>>e=0.000000:max_points=0:min_points=0:nodata=0.000000"
>>
>> Any ideas how to make things faster? I did a interpolation to 2 m x 2 m
>> raster earlier, which was faster but not very fast either.
>>
>> Best regards,
>>
>> Ari
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>


More information about the gdal-dev mailing list