On Fri, Jun 12, 2015 at 11:25 AM, Ari Simmons wrote:
> Do you mean
>
> gdal_translate -te -13813007 5569641 -13809113 5572598
> srtm_merged_3857.vrt my_subwindow.tif --config GDAL_CACHEMAX 800
>
> ?
Oops, I made a bad typo by omitting -projwin:
gdal_translate -projwin -13813007 5569641 -1380911
> > 3. What is the plan for the transition to GDAL 2.0? My driver was
> > developed against GDAL 1.11.2 and parallels similar drivers for MSSQL,
> > PostGIS, Oracle, etc.
>
> Current trunk is 2.0,
2.1dev actually ;-)
> with a release candidate out. You may have to
> do a little work to update
Le vendredi 12 juin 2015 23:18:26, Nicolas Cadieux a écrit :
> Hi Even,
> Thank you very much. I increased the buffer to 1.5 GB
> (512+512+514)*1024*1024 and I can now work much much faster with
> gdal_grid.
>
> Does gdal_fillnodata have the same type of variable that could speed things
> up? It
Hi Even,
Thank you very much. I increased the buffer to 1.5 GB (512+512+514)*1024*1024
and I can now work much much faster with gdal_grid.
Does gdal_fillnodata have the same type of variable that could speed things up?
It is also slow and does not seem speeded up by the "All_CPUS".
I will use
Patch is a diff of the source tree:
https://en.wikipedia.org/wiki/Patch_%28Unix%29
Yours will mostly be new files, but a few will change.
Easiest way to to do that is with svn checkout the trunk, make your
changes, svn add them, then do svn diff > db2.patch. That makes it
easier for the gdal de
Motion: GDAL/OGR 2.0.0RC1 is promoted to be the official 2.0.0 final release.
---
No critical issue has been specifically reported on RC1 so far, so I invite PSC
members to vote on this motion after doing your own testing and validation.
Input from everyone else who can test it is also very wel
Super cool. Thanks!
On Fri, Jun 12, 2015 at 10:29 AM, Kyle Shannon wrote:
> Jay,
>
>
> On Fri, Jun 12, 2015 at 11:21 AM, Kyle Shannon wrote:
> > Jay,
> >
> >
> > On Fri, Jun 12, 2015 at 10:59 AM, Jay L. wrote:
> >> Using GDAL 1.11.2 (Anaconda Python osgeo binstar install).
> >>
> >> I have a
Do you mean
gdal_translate -te -13813007 5569641 -13809113 5572598
srtm_merged_3857.vrt my_subwindow.tif --config GDAL_CACHEMAX 800
?
On Thu, Jun 11, 2015 at 3:08 PM, Eli Adam wrote:
> On Thu, Jun 11, 2015 at 2:38 PM, Ari Simmons
> wrote:
> > One notably huge difference is that there is a hu
David
On Fri, Jun 12, 2015 at 11:33 AM, David Adler
wrote:
> I have mostly completed the driver for DB2 Spatial using the ODBC support
> and would appreciate pointers into the GDAL information for the following:
>
> 1. Is there a test suite / framework for OGR drivers?
Yes, you can download the
I have mostly completed the driver for DB2 Spatial using the ODBC
support and would appreciate pointers into the GDAL information for the
following:
1. Is there a test suite / framework for OGR drivers?
2. What is the mechanism for submitting a new driver?
3. What is the plan for the transition
Jay,
On Fri, Jun 12, 2015 at 11:21 AM, Kyle Shannon wrote:
> Jay,
>
>
> On Fri, Jun 12, 2015 at 10:59 AM, Jay L. wrote:
>> Using GDAL 1.11.2 (Anaconda Python osgeo binstar install).
>>
>> I have a WKT projection:
>> 'PROJCS["Mercator",GEOGCS["GCS_Moon_2000",DATUM["D_Moon_2000",SPHEROID["Moon_20
Jay,
On Fri, Jun 12, 2015 at 10:59 AM, Jay L. wrote:
> Using GDAL 1.11.2 (Anaconda Python osgeo binstar install).
>
> I have a WKT projection:
> 'PROJCS["Mercator",GEOGCS["GCS_Moon_2000",DATUM["D_Moon_2000",SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degre
Using GDAL 1.11.2 (Anaconda Python osgeo binstar install).
I have a WKT projection:
'PROJCS["Mercator",GEOGCS["GCS_Moon_2000",DATUM["D_Moon_2000",SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Mercator"],PARAMETER["False
On 12 June 2015 at 16:11, Andrew C Aitchison wrote:
>
> I wasn't previously aware of the pgdg94 repository
> (I use ELGIS http://elgis.argeo.org/repos/6/elgis).
Ah! OK...
Silly question, but how/why are you doing that?
I followed a "natural" sequence of links on the postgresql.org which
led me
I have those nodata-values there since the same code path is used for
elevation data and such, but it had no effect to remove it.
I have narrowed it down to the case where I use an overview as input. I
have some very large images with overviews, so I find the overview closest
matching to the outpu
I fear my original subject line did not make the problem clear.
It looks like there is a problem with the 32-bit gdal RPM on the
pgdg94.repository (i.e. gdal-1.9.2-6.rhel6.i686).
Specifically, ogr2ogr cannot connect to a running postgres server, and
does not list PostgreSQL as one of the formats
Selon Thomas Sevaldrud :
> Thanks again! The problem was in the warper setup, it used only the first
> band of the image. This also revealed a bug in another part of my code
> related to VRT's and Warp, since I had added double sets of bands there as
> well. However, when fixing this, some old cod
Thanks again! The problem was in the warper setup, it used only the first
band of the image. This also revealed a bug in another part of my code
related to VRT's and Warp, since I had added double sets of bands there as
well. However, when fixing this, some old code stopped working :-)
Basically,
On Fri, 12 Jun 2015, Even Rouault wrote:
Selon Roger Bivand :
Hi,
In adapting rgdal for GDAL 2.0.0, it would be useful to know that
clamping, etc, and workarounds for integers in Integer64 fields that
exceed INT_MAX or INT_MIN actually work. Which of the autotest vector
files include Integer6
Il 12/06/2015 10:02, Even Rouault ha scritto:
> Yes, the driver could possibily be improved to also look at the first lines
> and
> guess if they look like valid DXF. Although it must be extremely uncommon to
> have dxf files without .dxf extension.
thanks, done.
--
Paolo Cavallini - www.fauna
Selon Roger Bivand :
> Hi,
>
> In adapting rgdal for GDAL 2.0.0, it would be useful to know that
> clamping, etc, and workarounds for integers in Integer64 fields that
> exceed INT_MAX or INT_MIN actually work. Which of the autotest vector
> files include Integer64 fields that test reading with In
Hi Paolo,
> See details at: http://hub.qgis.org/issues/9547
> with sample data.
Yes, the DXF driver currently uses the .dxf extension as the only criterion to
determine if a file is DXF or not.
> Should I open a ticket?
Yes, the driver could possibily be improved to also look at the first lines
See details at: http://hub.qgis.org/issues/9547
with sample data.
Should I open a ticket?
Thanks.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://
23 matches
Mail list logo
