How about:
gdalbuildvrt -addalpha -hidenodata -srcnodata "0"
On Wed, Sep 23, 2015 at 1:50 PM, Jonathan Greenberg
wrote:
> Folks:
>
> I've got a weird one -- I'm trying to perform a mosaic of GeoTIFF tiles
> that are somewhat overlapping. Here's the odd issue -- I need the mosaic
> to basical
Folks:
I've got a weird one -- I'm trying to perform a mosaic of GeoTIFF tiles
that are somewhat overlapping. Here's the odd issue -- I need the mosaic
to basically set all values of 0 AND "NODATA" to be the srcnodata. How do
I do this? Will gdalbuildvrt automatically use "true" NODATA values t
I downloaded gdal-2.0.1.tar.gz, reconfigured, recompiled, reinstalled, and
suddenly it's working. So maybe there was a problem with 2.0.0? Or maybe,
as Even said (as I was typing this message), the problem was needing to
"make clean" (I wiped the directory after downloading the new version).
Also,
Le mercredi 23 septembre 2015 17:29:42, Nicholas Williams a écrit :
> I'm having trouble getting ogr2ogr working with MySQL on Ubuntu 12.04, but
> I can't figure out why. Configure says MySQL is enabled, but execution says
> it's not.
>
> In addition to other dependencies, I installed the MySQL cl
Realized I left out which version I was on. I compiled and installed
from gdal-2.0.0.tar.gz. I'm about to try gdal-2.0.1.tar.gz.
Thanks,
Nick
On Wed, Sep 23, 2015 at 10:29 AM, Nicholas Williams <
nicholas+os...@nicholaswilliams.net> wrote:
> I'm having trouble getting ogr2ogr working with MySQL
Hi,
This is a call for discussion on "RFC 60: Improved round-tripping in OGR".
https://trac.osgeo.org/gdal/wiki/rfc60_improved_roundtripping_in_ogr
This RFC defines how to improve better round-tripping in conversion of vector
formats, in particular for GeoJSON extensions.
Best regards,
Even
I'm having trouble getting ogr2ogr working with MySQL on Ubuntu 12.04, but
I can't figure out why. Configure says MySQL is enabled, but execution says
it's not.
In addition to other dependencies, I installed the MySQL client dev:
sudo apt-get install -y libmysqlclient-dev=5.5.28-rel29.1-334.preci
Le mercredi 23 septembre 2015 14:54:58, Maxime Demers a écrit :
> Thank you for your answer.
>
> That works correctly with the correct layer name. However, I wonder where
> in the geojson that layer name is stored? It's not written in the file
> itself and I can't find it in the metadata of the fi
Thank you for your answer.
That works correctly with the correct layer name. However, I wonder where
in the geojson that layer name is stored? It's not written in the file
itself and I can't find it in the metadata of the file neither. The layer
name I found is OGRGeoJSON. Is this a default layer
Le mercredi 23 septembre 2015 14:41:53, Maxime Demers a écrit :
> Hi Even,
>
> Thank you for the suggestion. However, it seems I cannot use such a -sql
> statement on a geojson file. I got the following error with the command
> below:
>
> ogr2ogr -f "MapInfo File" test.tab points.geojson -sql "se
Hi Even,
Thank you for the suggestion. However, it seems I cannot use such a -sql
statement on a geojson file. I got the following error with the command
below:
ogr2ogr -f "MapInfo File" test.tab points.geojson -sql "select cast(id as
integer(10)), cast(codecs as character(3)), cast(codeSecteur a
post mailing list___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi,
On behalf of the GDAL/OGR development team, I am pleased to
announce the release of the GDAL/OGR 1.11.3 and 2.0.1 bug fix versions. Each
one contains more than 40 bug fixes since 1.11.2 / 2.0.0.
The sources for 1.11.3 are available at:
http://download.osgeo.org/gdal/1.11.3/gdal-1.11.3.ta
Le lundi 21 septembre 2015 12:27:35, Even Rouault a écrit :
> Hi,
>
> Saving a few bits, 2 motions in one email:
>
> Motion 1: GDAL/OGR 1.11.3 RC2 is promoted to be the official 1.11.3 final
> release.
>
> Motion 2: GDAL/OGR 2.0.1 RC1 is promoted to be the official 2.0.1 final
> release.
>
> --
Le mercredi 23 septembre 2015 12:54:21, Gane R a écrit :
> When I convert the above mentioned PDF to a GeoTIFF in EPSG:3857 I get the
> raster bounds shifted down from the actual raster location, where as when I
> convert the PDF to GeoTIFF in EPSG:4326 then to EPSG:3857 using gdalwarp
> and I get
Gane,
I don't really understand what you mean. Is there an error in the PDF
georeferencing (I thought we had addressed that a few months ago), or are you
surprised that gdalwarp transforms the image to be north-up ? If it is the
later, then it is an intended behaviour of gdalwarp.
Best regards
There are cases for handling 90 -90 rotation in pdfdataset.cpp
I am using poppler with pdfdataset.cpp as in Revision: 28978 of trunk
PDF gets skewed and shifts in geo location raster GeoTIFF, Is there any
issue in computing the geotransform ?
GeoTransform values are for an pdf at EPSG:4326
10776
17 matches
Mail list logo
