Re: [gdal-dev] gdal_viewshed

Hi Eli, Oh yes, I used the same parameters in all three. The only difference is in atmospheric refraction and curvature effect, but even playing a bit with that parameter, the overall effect is minimum compared with the huge difference I see between gdal_viewshed and the others. I'm putting

Re: [gdal-dev] gdal_viewshed

Hi Eli, Does -tz 10.0 in effect raise your DEM target elevation by 10 units? > > Was the observer height of -oz 21.6 the same for all three as well? > I'm using -oz 21.6 to put my observer at 21.6 meters above the DEM (it is a watch-tower); -tz10.0 to put the target at 10 meters above the DEM

Re: [gdal-dev] New to Gdal and NITF

I'd suggest with the documentation. https://trac.osgeo.org/gdal/wiki/GdalOgrInCsharp An example is shown at https://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALRead.cs for reading and at https://trac.osgeo.org/gdal/browser/trunk/gdal/swig/csharp/apps/GDALWrite.cs for writing

Re: [gdal-dev] gdal_viewshed

Hi Pedro, On Thu, May 7, 2020 at 4:03 PM Pedro Venâncio wrote: > > Hi, > > I'm trying the new gdal_viewshed and it is in fact really quick! But the > result is completely different than other viewshed analysis algorithms: > >

Re: [gdal-dev] gdal_viewshed

Hi, I'm trying the new gdal_viewshed and it is in fact really quick! But the result is completely different than other viewshed analysis algorithms: https://cld.pt/dl/download/e80216bb-d7eb-40b0-b6da-8e45572e9eb3/viewshed.jpg

Re: [gdal-dev] Wrong GDAL VersionInfo

> Do you think I should open a ticket in QGIS or OSGeo4W tracker? I'd say OSGeo4W -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org

Re: [gdal-dev] Wrong GDAL VersionInfo

Hi Even, You're right, I hadn't python3-gdal-dev package installed. After install it and run gdal-dev-py3-env, version become correct in OSGeo4W Shell gdal.VersionInfo() '302' Should not python3-gdal-dev package be installed by default with gdal-dev? However, I was trying it inside QGIS,

Re: [gdal-dev] Removal of API_PROXY mechanism: objections?

+1 for removing On Thu, May 7, 2020 at 11:53 AM Even Rouault wrote: > Hi, > > > > https://github.com/OSGeo/gdal/pull/2489 kills the API_PROXY mechanism, > which removes 7820 lines of code. Anyone objects ? > > > > Note: if you have no idea what this is about, then it means you never used > that

[gdal-dev] Removal of API_PROXY mechanism: objections?

Hi, https://github.com/OSGeo/gdal/pull/2489 kills the API_PROXY mechanism, which removes 7820 lines of code. Anyone objects ? Note: if you have no idea what this is about, then it means you never used that stuff since it couldn't be used just accidentally like other functionalities. I'm not

Re: [gdal-dev] Wrong GDAL VersionInfo

On jeudi 7 mai 2020 18:29:02 CEST Pedro Venâncio wrote: > Hi all, > > I'm seeing that gdal 3.2.0dev is giving a wrong gdal.VersionInfo() output: > '3000400'. > Anyone confirm? You're probably not using the Python module corresponding to master. Have you intalled the python3-gdal-dev package

[gdal-dev] Wrong GDAL VersionInfo

Hi all, I'm seeing that gdal 3.2.0dev is giving a wrong gdal.VersionInfo() output: '3000400'. Testing several GDAL versions: 3.2.0dev import gdal gdal.VersionInfo() '3000400' 3.0.2 import gdal gdal.VersionInfo() '3000200' 2.4.3 import gdal gdal.VersionInfo() '2040300' This is happening with

Re: [gdal-dev] OGR GeoJSON transormation woes

Ah, I did not make myself clear enough. My intention surely wasn't to change any existing standards/formats, I believe especially the GeoJSON coordinate thing has been already sufficiently discussed. I was referring to the GeoJSON data I receive in my plugin or any future project. I was

Re: [gdal-dev] gdal_viewshed

> On May 7, 2020, at 11:05 AM, Eli Adam wrote: > > The image with two dots makes me think that there can be multiple > observer inputs. Is that the case? Is the syntax for that just to > keep adding more -ox, -oy, (and oz)? For instance, gdal_viewshed -md > 500 -ox -10147017 -oy 5108065 -ox

[gdal-dev] HDF5-R (Re: Intro)

Peter, Thanks for reaching out. > On many of the projects we support, there has been a need to create a gdal > driver / format to natively ingest a specification of the hdf5 format. > Since this data type is used by mainy vendors HDF5 in general, or this particular formulation ? > , we thought

[gdal-dev] gdal_viewshed

Congrats on another great release! On Thu, May 7, 2020 at 7:20 AM Even Rouault wrote: > > > The 3.1.0 release is a new feature release with the following highlights: > > - [gdal_viewshed](https://gdal.org/programs/gdal_viewshed.html): > > new utility for viewshed algorithm > On the

Re: [gdal-dev] GDAL versions Vs PROJ versions

On jeudi 7 mai 2020 11:12:30 CEST Vincent Sarago wrote: > > Help to improve them is always welcome (hint hint!) > : > :-) I’ll see what I can do. I know that if we start adding PROJ version docs > :people may also ask for GEOS and more other libs.: > > I'd strongly advise using either 6.3.2 or

Re: [gdal-dev] GDAL versions Vs PROJ versions

> Help to improve them is always welcome (hint hint!) :-) I’ll see what I can do. I know that if we start adding PROJ version docs people may also ask for GEOS and more other libs. > I'd strongly advise using either 6.3.2 or 7.0.1 for best experience Thanks Even this is really helpful, I was

Re: [gdal-dev] GDAL versions Vs PROJ versions

Vincent, > My second question is then should we make the docs a bit more clear ? Help to improve them is always welcome (hint hint!) but listing all min/max versions of dependencies of GDAL could be close to a full time job since you'd have to actually test building and at runtime...

Re: [gdal-dev] GDAL versions Vs PROJ versions

Thanks for your response Greg, I can’t see anything on https://github.com/OSGeo/gdal/blob/master/README.md about PROJ versions. In the NEWS there are some info yes: - https://github.com/OSGeo/gdal/blob/master/gdal/NEWS#L755

[gdal-dev] GDAL versions Vs PROJ versions

Dear GDAL devs, Maybe this is a totally dumb question and there might be already a doc somewhere (which I couldn’t find), but what are the min (and or max?) PROJ version for let say gdal2.4 / gdal3.0 / gdal3.1 ? Regards, Vincent ___ gdal-dev

[gdal-dev] GDAL 3.1.0 is released

Hi, On behalf of the GDAL/OGR development team and community, I am pleased to announce the release of GDAL/OGR 3.1.0. GDAL/OGR is a C++ geospatial data access library for raster and vector file formats, databases and web services. It includes bindings for several languages, and a variety

Re: [gdal-dev] New to Gdal and NITF

NITF is a format designed to wrap various metadata sets into a package with some number of raster layers. It isn't necessarily straightforward to build. I suggest you have a look at the specifications: https://gwg.nga.mil/ntb/baseline/documents.html There's also a Wikipedia article that provides

Re: [gdal-dev] New to Gdal and NITF

It's hard to say what ive tried as I don't even know where to start really. I was expecting something like "new Nitf()" or "Nitf.Create()" style api and I'm not seeing those. I'm guessing I'm supposed to do something with the Gdal.Open() method but I dont know what I'd actually pass in there.

Re: [gdal-dev] Motion: promote GDAL 3.1.0 RC3

On mardi 5 mai 2020 11:39:35 CEST Even Rouault wrote: > Hi, > > Motion: promote GDAL 3.1.0 RC3 to final 3.1.0 > I declare this motion passed with +1 from PSC members HowardB, MateuszL, JukkaR, DanielM and myself Even -- Spatialys - Geospatial professional services http://www.spatialys.com

Re: [gdal-dev] OGR GeoJSON transormation woes

> PS > is the API documentation for Python up to date? The SpatialReference > docs [3] are missing the SetAxisMappingStrategy method Thanks for pointing that. There was indeed an issue with the refresh of the Python API. This is now mentionned -- Spatialys - Geospatial professional services

Re: [gdal-dev] OGR GeoJSON transormation woes

On jeudi 7 mai 2020 03:28:15 CEST jratike80 wrote: > Hi, > > I fear that such a change in GeoJSON would not really correct anything but > rather move the confusion into another place. Yeah, especially since GeoJSON rather claims using OGC:1.3:CRS84 which is long, lat. But for interoperability

Re: [gdal-dev] OGR GeoJSON transormation woes

Hi, I fear that such a change in GeoJSON would not really correct anything but rather move the confusion into another place. -Jukka Rahkonen- Frank Broniewski-6 wrote > But after reading all this stuff, I wonder if it would not have been > better/more right to "correct" the GeoJSON

Re: [gdal-dev] OGR GeoJSON transormation woes

Hi Even, thank you very much for the hint. Although after researching on it I fell into a rabbit hole and just barely got out, but with a decent headache ;-) Why do these coordinate systems and their axes have to be so complicated, they make my head hurt ... :-) For future readers on the