Hi,
I'm trying to pull some data out of a netcdf and convert it to a geotiff. The
data are the snowdepths from this paper
https://www.nature.com/articles/s41467-019-12566-y
with one of the data files here for testing:
https://drive.google.com/open?id=1qZBYJ4UEbYYHXpSV4gyFBkZYdYKtZGTR
The data
Hi Even,
On Fri, Jan 31, 2020 at 7:53 AM Even Rouault
wrote:
> On vendredi 31 janvier 2020 15:14:39 CET Mateusz Loskot wrote:
> > On Fri, 31 Jan 2020 at 10:58, Christoph Paulik
> wrote:
> > > My initial motivation was that I would like `pip install gdal` to just
> > > work.
> > I do share your
On 1/30/2020 6:33 AM, Robert Coup wrote:
Hi Christoph,
For what it's worth, I'm doing some very minimal GDAL builds at the
moment with Python bindings. The problem you'll very quickly run into is
that GDAL has an enormous set of dependencies. This is what the default
Homebrew gdal package d
> How important is this error? Thank you.
Probably not that much. It is due to failure when trying to reproject pixels
not corresponding to a location on Earth.
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-de
Dears,
I finally got a working `gdalwarp` one-lines for MSG/SEVIRI products.
For example,
```
gdalwarp \
-ot Float32 \
-s_srs "+proj=geos +h=35785831 +a=6378169 +b=6356583.8 +no_defs" \
-t_srs EPSG:4326 \
-r near \
-of GTiff \
HDF5_LSASAF_MSG_LST_MSG-Disk_201906302300.tif \
HDF5_LSASAF_MS
Jason,
From your description you may be interested to try the GDAL that is shipped
with the GMT installer. I haven't touched on the symbol names ofc but either
the GDAL dll and all of its dependencies have different names (suffixed with a
"_w64"), which avoids the name clashing that you refer t
As a 15-year user of GDAL's Python bindings and a long time lurker on this
list, I just wanted to thank all of you who are contemplating the Python
packaging problem (and thank you for GDAL in general). I maintain a small
package of Python-based utilities used by marine ecologists, mainly in an
On vendredi 31 janvier 2020 15:14:39 CET Mateusz Loskot wrote:
> On Fri, 31 Jan 2020 at 10:58, Christoph Paulik
wrote:
> > My initial motivation was that I would like `pip install gdal` to just
> > work.
> I do share your view.
> The pip install is always the canonical Pythonic way for me and
> I
On vendredi 31 janvier 2020 14:30:31 CET Joaquim Manuel Freire Luís wrote:
> I found this
>
> https://gdal.org/drivers/vector/memory.html
>
> but it refers to CreateDataSource() to the job and I can't find anything
> about this function that is not python related (old code?).
CreateDataSource()
I found this
https://gdal.org/drivers/vector/memory.html
but it refers to CreateDataSource() to the job and I can't find anything about
this function that is not python related (old code?).
Is there an example somewhere of creating a Memory (not MEM?) vector dataset
that I could use to learn
On Fri, 31 Jan 2020 at 10:58, Christoph Paulik wrote:
>
> My initial motivation was that I would like `pip install gdal` to just work.
I do share your view.
The pip install is always the canonical Pythonic way for me and
I'd be very happy myself to be able to install GDAL that way.
> I guess tha
Here is how I build them for Linux, taken from Sean's work on rasterio.
https://github.com/youngpm/gdalmanylinux
On Fri, Jan 31, 2020, 2:58 AM Christoph Paulik
wrote:
> Thank you all for the input.
>
> My initial motivation was that I would like `pip install gdal` to just
> work.
>
> I like
Thank you all for the input.
My initial motivation was that I would like `pip install gdal` to just
work.
I like and use conda-forge daily but in my opinion the whole Python
packaging system is broken.
There are packages you can install with conda but not with pip and the
other way around.
So yo
13 matches
Mail list logo