On lundi 30 septembre 2019 22:39:13 CEST Mateusz Loskot wrote:
> On Mon, 30 Sep 2019 at 14:34, Even Rouault
wrote:
> > I'd say that we should at the very minimum recover the information that
> > used to be in the "Compiled by default" column of
> > https://github.com/OSGeo/gdal/blob/release/3.0/g
On Mon, 30 Sep 2019 at 14:34, Even Rouault wrote:
>
> I'd say that we should at the very minimum recover the information that used
> to be in the "Compiled by default" column of
> https://github.com/OSGeo/gdal/blob/release/3.0/gdal/frmts/formats_list.html
>
> That would address the comments in
> h
As far as I see, the size of the output raster is equal to the input size
with the gdaldem utility set.
With the viewshed approach, the size of the output raster is calculated
according to the provided parameters (ie. the observer location and
maxdistance), however it is a good idea to allow the us
On Mon, Sep 30, 2019 at 11:54 AM Even Rouault
wrote:
>
> On lundi 30 septembre 2019 20:10:38 CEST Tamas Szekeres wrote:
> > Hi,
> >
> > I've implemented a viewshed algorithm a while ago, by utilizing a modified
> > version of the algorithm published at
> > https://www.asprs.org/wp-content/uploads/
On lundi 30 septembre 2019 20:10:38 CEST Tamas Szekeres wrote:
> Hi,
>
> I've implemented a viewshed algorithm a while ago, by utilizing a modified
> version of the algorithm published at
> https://www.asprs.org/wp-content/uploads/pers/2000journal/january/2000_jan_8
> 7-90.pdf
>
> With this appro
Hi,
I've implemented a viewshed algorithm a while ago, by utilizing a modified
version of the algorithm published at
https://www.asprs.org/wp-content/uploads/pers/2000journal/january/2000_jan_87-90.pdf
With this approach, it was crucial to provide a fast real-time option for
the viewshed calculat
On lundi 30 septembre 2019 08:58:18 CEST Fernando Aristizabal - NOAA Affiliate
wrote:
> FEMA generated Lidar datasets
I've just committed
https://github.com/OSGeo/gdal/commit/e6196ddef3ef73652eedef2c2daf73c087ebf4f2
which should fix reading those datasets
Even
--
Spatialys - Geospatial profess
Hi Stefan,
On Mon, Sep 30, 2019 at 6:03 AM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:
> Hi Even,
>
> And thanks for your swift reply.
>
> If I install Python bindings like:
> pip3 install gdal==2.4.2
> installation works fine.
>
> However, if I then install nansat:
> pip3 install nan
GDAL does not seem to recognize some FEMA generated Lidar datasets that are
presented in USGS DEM (.dem) file formats. The files open fine in ArcGIS.
Running:
$ gdalinfo fema06-140cm_2995441b.dem
ERROR 1: Does not appear to be a USGS DEM file
gdalinfo failed - unable to open 'fema06-140cm_2995441b
On lundi 30 septembre 2019 12:02:55 CEST Stefan Blumentrath wrote:
> Hi Even,
>
> And thanks for your swift reply.
>
> If I install Python bindings like:
> pip3 install gdal==2.4.2
> installation works fine.
>
> However, if I then install nansat:
> pip3 install nansat
> then pip3 tries to re-ins
On lundi 30 septembre 2019 14:07:44 CEST Mateusz Loskot wrote:
> On Mon, 30 Sep 2019 at 12:33, Even Rouault
wrote:
> > On lundi 30 septembre 2019 11:21:16 CEST Mateusz Loskot wrote:
> > > I'm a bit lost where build requirements are supposed
> > > to be documented now. They used to be described
>
On Mon, 30 Sep 2019 at 12:33, Even Rouault wrote:
> On lundi 30 septembre 2019 11:21:16 CEST Mateusz Loskot wrote:
> >
> > I'm a bit lost where build requirements are supposed
> > to be documented now. They used to be described
> > on the Wiki, e.g. https://trac.osgeo.org/gdal/wiki/BuildingOnUnix
Hi Even,
And thanks for your swift reply.
If I install Python bindings like:
pip3 install gdal==2.4.2
installation works fine.
However, if I then install nansat:
pip3 install nansat
then pip3 tries to re-install GDALs python bindings for GDAL version 3 (which
fails).
So, users are caught up in
On lundi 30 septembre 2019 03:42:32 CEST CDelancy wrote:
> Hello. I am using GDAL 3 in a c++ project. I have found that GDAL does not
> seem to properly read values from raster datasets that it has created. For
> example, if I create a new raster dataset with one band and read the min and
> max val
Hello. I am using GDAL 3 in a c++ project. I have found that GDAL does not
seem to properly read values from raster datasets that it has created. For
example, if I create a new raster dataset with one band and read the min and
max values from that band, it always returns -4294967295.0 and 429496729
On lundi 30 septembre 2019 08:19:41 CEST Stefan Blumentrath wrote:
> Hi gdal-devs,
>
> GDAL on PyPi is already at version 3, while e.g. Ubuntu and Fedora still
> ship GDAL 2. Thus, downstream Python packages that do not particularly
> specify to depend on GDAL <3 fail to build via pip3, cause pip3
On lundi 30 septembre 2019 11:21:16 CEST Mateusz Loskot wrote:
> Hi,
>
> I'm a bit lost where build requirements are supposed
> to be documented now. They used to be described
> on the Wiki, e.g. https://trac.osgeo.org/gdal/wiki/BuildingOnUnix
> or driver-specific ones https://trac.osgeo.org/gdal/
Hi,
I'm a bit lost where build requirements are supposed
to be documented now. They used to be described
on the Wiki, e.g. https://trac.osgeo.org/gdal/wiki/BuildingOnUnix
or driver-specific ones https://trac.osgeo.org/gdal/wiki/ECW
For example, where unixODBC requirements should be advertised,
to
Hi gdal-devs,
GDAL on PyPi is already at version 3, while e.g. Ubuntu and Fedora still ship
GDAL 2.
Thus, downstream Python packages that do not particularly specify to depend on
GDAL <3 fail to build via pip3, cause pip3 tires to install Python bindings for
GDAL 3, which is missing on the syst
19 matches
Mail list logo
