Hi GDAL team,
I've implemented several improvements to the NetCDF driver and I would like to
provide them to the community.
Main goal of the changes is to add full support of NetCDF-4 including groups.
NetCDF-4 is the future format of ESA Sentinel-3 products (no groups) and NASA
Ocean Color
Even Rouault even.rouault at spatialys.com writes:
Mani,
you could use a VRT union layer to merge all layers into a single one.
This is
documented at http://gdal.org/drv_vrt.html
In your case this would be creating a .vrt file like :
OGRVRTDataSource
OGRVRTUnionLayer
Le jeudi 05 février 2015 20:15:47, Jukka Rahkonen a écrit :
Jorge Arévalo jorge at cartodb.com writes:
- Generate JPEG tiles instead of PNG. Tried just replacing the driver's
name (PNG) with JPEG. Didn't work. Base tiles are generated, but
overview tiles are not. Getting this error instead:
Jorge Arévalo jorge at cartodb.com writes:
- Generate JPEG tiles instead of PNG. Tried just replacing the driver's
name (PNG) with JPEG. Didn't work. Base tiles are generated, but
overview tiles are not. Getting this error instead: ERROR 1: Buffer too
small
There is a patch included
Le jeudi 05 février 2015 23:18:30, Leif Gruenwoldt a écrit :
I happened to be playing around with this more today and I'm fairly certain
this isn't just a GitHub UI thing. I'm betting it's svn migration related.
After cloning a copy of the git repo I noticed the tags don't appear as
normal
Hi, I am trying to follow the tutorials posted in
http://www.gdal.org/ogr_apitut.html , but it's made for GDAL 2.0 and I have
the latest stable release GDAL 1.11.1.
I can rewrite the code to GDAL 1.11.1 but the API for this version shows
some functions like deprecated.
So... Where can I get GDAL
Carlos,
Hi, I am trying to follow the tutorials posted in
http://www.gdal.org/ogr_apitut.html , but it's made for GDAL 2.0 and I have
the latest stable release GDAL 1.11.1.
A snapshot of GDAL 1.11.1 doc is available at http://gdal.org/1.11
I can rewrite the code to GDAL 1.11.1 but the API
Hello Klokan,
Thanks for the info. Yes, we have a maptiler license. It's a great tool
:-).
Best regards
Jorge
Klokan Petr Pridal mailto:klo...@klokan.cz
February 3, 2015 at 2:20 AM
Hi there,
maptiler generates xyz by default, and back-compatible tms with -tms
on the command line or in
Just thinking, but wouldn't it be nice to have ogrbuildvrt tool that would
take list of OGR supported layers and outputs a simple vrt with one union
layer like the one in your example?
There is this script,
https://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/ogr2vrt.py,
with details
Le jeudi 05 février 2015 17:24:24, Eli Adam a écrit :
Just thinking, but wouldn't it be nice to have ogrbuildvrt tool that
would take list of OGR supported layers and outputs a simple vrt with
one union layer like the one in your example?
There is this script,
Le jeudi 05 février 2015 17:23:06, Jesse McGraw a écrit :
I'm not sure whether this is a real issue or not but I thought I'd bring it
up, at the very least I'll learn something
When using gdalwarp -cutline shapefile -crop_to_cutline on an input
raster that is in EPSG:3857 with square-pixels
Thanks Even.
I did try re-warping the cropped output to 3857 again and it does produce
square pixels but at the expense of an additional warping operation
I'm just curious why the warping that is part of the -crop_to_cutline
process is changing the pixel ratio while a regular, non-cropping
I'm not sure whether this is a real issue or not but I thought I'd bring it
up, at the very least I'll learn something
When using gdalwarp -cutline shapefile -crop_to_cutline on an input
raster that is in EPSG:3857 with square-pixels the output raster, while
still EPSG:3857, now has non-square
Le jeudi 05 février 2015 17:41:22, Jesse McGraw a écrit :
Thanks Even.
I did try re-warping the cropped output to 3857 again and it does produce
square pixels but at the expense of an additional warping operation
I'm just curious why the warping that is part of the -crop_to_cutline
Thank you, Even. For now I'll proceed with the additional warping.
Just for my education: are square pixels a requirement for EPSG:3857?
On Thu, Feb 5, 2015 at 11:50 AM, Even Rouault even.roua...@spatialys.com
wrote:
Le jeudi 05 février 2015 17:41:22, Jesse McGraw a écrit :
Thanks Even.
Le jeudi 05 février 2015 17:57:02, Jesse McGraw a écrit :
Thank you, Even. For now I'll proceed with the additional warping.
Just for my education: are square pixels a requirement for EPSG:3857?
In the general case, no. But it might be a requirement (or an optimization)
depending on what
Hi everybody,
If you want to use the latest stable GDAL, for example on a newly installed
Linux machine to do some fast raster data processing with the command-line
utilities, and you need drivers like MrSID, ECW or Kakadu JPEG2000, you may
very probably end up compiling everything yourself. It
Even,
thanks for the tip. The binaries are build against the stable debian. We
will adjust the Dockerfile and republish the binaries soon.
Regards,
Petr
On Thu, Feb 5, 2015 at 11:21 AM, Even Rouault even.roua...@spatialys.com
wrote:
Petr,
I can see that the libgdal in the Docker image is
Yeah that ll be pretty awesome :D
On Thu, Feb 5, 2015 at 4:49 PM, Jukka Rahkonen
jukka.rahko...@maanmittauslaitos.fi wrote:
Even Rouault even.rouault at spatialys.com writes:
Mani,
you could use a VRT union layer to merge all layers into a single one.
This is
documented at
Hi,
This is a call for discussion on RFC 53: OGR not-null constraints and default
values.
http://trac.osgeo.org/gdal/wiki/rfc53_ogr_notnull_default
Summary :
This RFC addresses handling of NOT NULL constraints and DEFAULT values for OGR
fields. NOT NULL constraints are useful to maintain
Hi,
Thanks for the tips, Klokan. Really useful. We already have a maptiler
license, and we use it, but we can't use that tool this time.
Best regards,
Jorge
Klokan Petr Pridal mailto:klo...@klokan.cz
February 3, 2015 at 2:18 AM
Hi Jorge,
rendering of your sample file down to zoomlevel 19
Kurt,
Forwarding this publicly as this is of general interest.
I've created http://trac.osgeo.org/gdal/ticket/5830 and commited :
branches/1.11 r28417 Internal libtiff: partial upgrade to 4.0.4beta
(everything, except changes in tif_jpeg.c that are not security related and
cause differences in
Jorge Arévalo mailto:jo...@cartodb.com
February 5, 2015 at 7:15 PM
- Generate JPEG tiles instead of PNG. Tried just replacing the
driver's name (PNG) with JPEG. Didn't work. Base tiles are generated,
but overview tiles are not. Getting this error instead: ERROR 1:
Buffer too small
- Apply a
Jorge,
- Generate JPEG tiles instead of PNG. Tried just replacing the driver's
name (PNG) with JPEG. Didn't work. Base tiles are generated, but
overview tiles are not. Getting this error instead: ERROR 1: Buffer too
small
This messages comes from the WriteRaster() Python bindings, when it is
Petr,
I can see that the libgdal in the Docker image is linked against
/usr/lib/x86_64-linux-gnu/libtiff.so.4
which happens to be 3.9.6-11. GDAL itself contains a copy of libtiff 4.0.X that
will get used,
so you can potentially have a mix of libtiff symbols of different ABI that
could lead to
- Generate JPEG tiles instead of PNG. Tried just replacing the driver's
name (PNG) with JPEG. Didn't work. Base tiles are generated, but
overview tiles are not. Getting this error instead: ERROR 1: Buffer too
small
- Apply a color to nodata value of generated tiles. Tried passing -a
200,0,0 to
Excellent! Thanks!
-kurt
On Thu, Feb 5, 2015 at 10:21 AM, Even Rouault even.roua...@spatialys.com
wrote:
Kurt,
Forwarding this publicly as this is of general interest.
I've created http://trac.osgeo.org/gdal/ticket/5830 and commited :
branches/1.11 r28417 Internal libtiff: partial
Wow, we answered at same time. So, I'll include my findings here
Even Rouault mailto:even.roua...@spatialys.com
February 5, 2015 at 7:30 PM
Jorge,
- Generate JPEG tiles instead of PNG. Tried just replacing the driver's
name (PNG) with JPEG. Didn't work. Base tiles are generated, but
overview
28 matches
Mail list logo
