Selon Roger Bivand roger.biv...@nhh.no:
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
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
On Fri, 12 Jun 2015, Even Rouault wrote:
Selon Roger Bivand roger.biv...@nhh.no:
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
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 -
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
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
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,
Selon Thomas Sevaldrud tho...@silentwings.no:
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
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
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
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 is
On Fri, Jun 12, 2015 at 11:25 AM, Ari Simmons ari.ucb.f...@gmail.com 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
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 the
On 12 June 2015 at 16:11, Andrew C Aitchison and...@aitchison.me.uk 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
Jay,
On Fri, Jun 12, 2015 at 10:59 AM, Jay L. jla...@asu.edu wrote:
Using GDAL 1.11.2 (Anaconda Python osgeo binstar install).
I have a WKT projection:
Using GDAL 1.11.2 (Anaconda Python osgeo binstar install).
I have a WKT projection:
Jay,
On Fri, Jun 12, 2015 at 11:21 AM, Kyle Shannon k...@pobox.com wrote:
Jay,
On Fri, Jun 12, 2015 at 10:59 AM, Jay L. jla...@asu.edu wrote:
Using GDAL 1.11.2 (Anaconda Python osgeo binstar install).
I have a WKT projection:
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
David
On Fri, Jun 12, 2015 at 11:33 AM, David Adler
dad...@adtechgeospatial.com 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?
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 ea...@co.lincoln.or.us wrote:
On Thu, Jun 11, 2015 at 2:38 PM, Ari Simmons ari.ucb.f...@gmail.com
wrote:
One
Super cool. Thanks!
On Fri, Jun 12, 2015 at 10:29 AM, Kyle Shannon k...@pobox.com wrote:
Jay,
On Fri, Jun 12, 2015 at 11:21 AM, Kyle Shannon k...@pobox.com wrote:
Jay,
On Fri, Jun 12, 2015 at 10:59 AM, Jay L. jla...@asu.edu wrote:
Using GDAL 1.11.2 (Anaconda Python osgeo binstar
22 matches
Mail list logo
