Even,
Appreciate the response.
Your example is interesting but there are a couple of issues. Importing a
random .000 file using ogr2ogr yields 6 tables in the database. Which tables
are created depend on the data and are unknown to me prior to import, so it is
difficult to generate the SQL in
Hi Evan,
I probably wasn't clear in my response to you. I did try optimizing IDW using
max points and various radii. The results were mixed, but overall by using
radius and max points, the process is slowed considerably. If it is helpful, I
can give you some time differences when I get back
Cheer Joakim! That I am not familiar with and will have a look
From: Joaquim Manuel Freire Luís [jl...@ualg.pt]
Sent: Tuesday, 26 June 2018 10:58 a.m.
To: Ian Reese; Even Rouault; gdal-dev@lists.osgeo.org
Cc: Jeremy Palmer
Subject: RE: [gdal-dev] Kriging In
I have plenty of methods for working around speed issues and have
|>worked with any number of interpolations methods in GRASS, SAGA and
|>Python.
You have also the minimum curvature in GMT. Not lightning fast but quicker than
krigging and normally better looking, specially on the extrapolation
Hi All,
Thank you so much everyone for your replies. I should be clear, speed is
important to our processes, but most important in my work is the visual
outcome. Kriging by far produces the best results for this. No amount of
tweaking IDW or any other method in GDAL produces the same results.
> This would still be an issue with paging. Most of the actual datasets
> of interest (to me) involve multiple HTTP requests to fetch many pages
> of JSON data (usually 1000 - 1 features at a time depending on
> server setup). The curves may easily not be on the first page and
> re-running th
On 06/22/2018 02:51 PM, Even Rouault wrote:
> On vendredi 22 juin 2018 14:38:15 CEST James Klassen wrote:
>> I finally got around to doing a rough implementation of parsing ESRIJSON
>> with curved geometries. The code is very rough yet, but works enough to
>> import a polygon layer from an ESRI
+1
Tamas
2018-06-25 15:18 GMT+02:00 Even Rouault :
> Hi,
>
> Motion: GDAL/OGR 2.3.1 rc2 is promoted to be the official 2.3.1 final
> release.
>
> ---
>
> My vote: +1
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _
On lundi 25 juin 2018 13:10:16 CEST Kalev Julge wrote:
> Hi Doug,
>
> Thanks for the info. I know that JPEG is lossy but our datasets are very
> large. That’s why we use JPEG, which is good enough for our needs and the
> file sizes are smaller.
After your gdalwarp to VRT, do:
gdal_translate new.v
Hi,
Motion: GDAL/OGR 2.3.1 rc2 is promoted to be the official 2.3.1 final release.
---
My vote: +1
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osg
Hi Doug,
Thanks for the info. I know that JPEG is lossy but our datasets are very large.
That’s why we use JPEG, which is good enough for our needs and the file sizes
are smaller.
It seems that GDAL doesn’t create new JPEG files without having pre-existing
JPEG-s to modify. If I try to modify
Ian,
Looking at your script, for the IDW, I see you don't use the max_points, nor
the radius1 and radius2 to limit the neighbourhoud into which the points are
searched.
For the linear search, I've profiled the run and found that an enormous amout
of time was spent processing the points outside
Hi Even,
Thanks a lot. This is great news! I will start investigating the fix for
Out-DB rasters. I will keep you posted. Great work!
On Mon, Jun 25, 2018 at 10:26 AM, Even Rouault
wrote:
> On lundi 25 juin 2018 10:18:22 CEST Osahon Oduware wrote:
> > Hi Even,
> >
> > I want to find out if this
On lundi 25 juin 2018 10:18:22 CEST Osahon Oduware wrote:
> Hi Even,
>
> I want to find out if this GDAL fix will be release by the end of June. I
> use PostGIS version 2.3.2 at present and I will be building from source.
Yes, this is in the release notes of the release candidate of GDAL 2.3.1 th
Hi Even,
I want to find out if this GDAL fix will be release by the end of June. I
use PostGIS version 2.3.2 at present and I will be building from source.
On Thu, May 31, 2018 at 9:39 PM, Even Rouault
wrote:
> On jeudi 31 mai 2018 21:35:30 CEST Osahon Oduware wrote:
> > Hi Even,
> >
> > Thanks
Hi Ian,
If you find IDW on N points slow, you will find Kriging on the same number
of points unbearably slow, since for Kriging you will have to solve a
system of N linear equations (essentially inverting an NxN matrix) to
compute the Kriging weights. To set up the matrix you will even need to
com
16 matches
Mail list logo
