Hi Adam,
https://github.com/codice/imaging-nitf/pull/196 is the work I did for my
java implementation.
The spec definition I came up should be directly applicable.
However for it to work in GDAL, we need at least:
* Support for parsing / using the IEEE 754 encoding (which I calle
Hi
On 11/5/19 9:54 PM, Even Rouault wrote:
On mardi 5 novembre 2019 14:48:19 CET Norman Barker wrote:
Hi,
I was looking at the recent 3.0.2 release and it was missing a few of my
commits for the TileDB driver dating back to June. How do I get these added
to the 3.0.x series, I understood the b
On Tue, 5 Nov 2019 at 12:06, Even Rouault wrote:
>
> This is a topic we already discussed a couple years ago. Please find a RFC
> about it in:
>
> https://github.com/OSGeo/gdal/pull/1984/files
I dropped some comments there, not a review though.
Best regards,
--
Mateusz Loskot, http://mateusz.lo
Thanks Even!
De : Even Rouault [even.roua...@spatialys.com]
Envoyé : mardi 5 novembre 2019 18:07
À : Julien Demaria
Cc : gdal-dev@lists.osgeo.org
Objet : Re: [gdal-dev] Removing default nodata value from netCDF driver ?
On mardi 5 novembre 2019 15:41:47 CE
On mardi 5 novembre 2019 14:48:19 CET Norman Barker wrote:
> Hi,
>
> I was looking at the recent 3.0.2 release and it was missing a few of my
> commits for the TileDB driver dating back to June. How do I get these added
> to the 3.0.x series, I understood the backport function to be for bug fixes?
Hi,
I was looking at the recent 3.0.2 release and it was missing a few of my
commits for the TileDB driver dating back to June. How do I get these added
to the 3.0.x series, I understood the backport function to be for bug fixes?
Norman
___
gdal-dev mai
Improvements have hit master. I suspect there are some remaining
bottlenecks though, but I currently lack the tests/means to investigate
further in short term and will appreciate feedback.
Den tors 31 okt. 2019 02:17Björn Harrtell skrev:
> Thanks for trying out accessing FlatGeobuf via http.
>
>
On mardi 5 novembre 2019 13:16:36 CET Mike wrote:
> I did end up just defining the layers and just adding all the data to it.
>
> However this does occur with ogr2ogr, and it says to use skip failures.
> When I use that, I get one less feature (fails on the first I assume).
You get that message b
I did end up just defining the layers and just adding all the data to it.
However this does occur with ogr2ogr, and it says to use skip failures.
When I use that, I get one less feature (fails on the first I assume).
Is there a way to ignore FID with fgdb output & ogr2ogr?
Same for the CopyLayer
I'm trying to create some features in a File GDB, and have that driver
loaded.
I've been doing something along the lines just fine to gpkg, but I hit a
FileGDB issue and wondering how to get around it.
This line in python
lyr = fgdbds.CopyLayer(inmemorylayer,somename,['OVERWRITE=YES'])
I get the
On mardi 5 novembre 2019 15:41:47 CET Julien Demaria wrote:
> Ok let's keep this for another PR.
>
> no_fill is not only a write side optimization because nc_inq_var_fill() can
> be called when reading a file (the no_fill value is stored in the hidden
> NetCDF attribute _NoFill, you can print it w
Ok let's keep this for another PR.
no_fill is not only a write side optimization because nc_inq_var_fill() can be
called when reading a file (the no_fill value is stored in the hidden NetCDF
attribute _NoFill, you can print it with ncdump -s but it is only set when
nofill=true).
My understandin
On mardi 5 novembre 2019 14:08:33 CET Julien Demaria wrote:
> Hi Even,
>
> Thanks for all the work.
> I looked at the new pull request, it seems good but what do you think about
> adding support for case where nc_inq_var_fill() returns no_fill=1? In this
> case the current code uses fillvalue=zero
Dear Even, Ivan,
Point taken on the self-consistency of the products.
GeoTransform indeed appears incorrect, at least for NDVI.
We'll cross-check for other products and either correct or remove GeoTransform.
I noted in earlier reply that it doesn't impact GDAL's netCDF driver, as it
looks at lon
Brad,
Sorry it took so long to get back to you.
I am interested in collaborating on this with you.
Any help would be appreciated!
Thanks!
Adam
From: Brad Hards
Sent: Monday, October 14, 2019 6:16 PM
To: Edson, Adam Robert ; gdal-dev@lists.osgeo.org
Subject:
Even,
That confirms my suspicious. The NetCDF driver is fine and there is nothing to
be added or changed.
> The products are not self consistent if you consider the crs:GeoTransform
> property,
> the documentation of the product and the actual values of the lon, lat arrays
> ...
> I think clari
Hi Even,
Thanks for all the work.
I looked at the new pull request, it seems good but what do you think about
adding support for case where nc_inq_var_fill() returns no_fill=1? In this case
the current code uses fillvalue=zero by default (if I'm not wrong) which is not
ideal, I think it is bett
On mardi 5 novembre 2019 08:25:53 CET Travis Kirstine wrote:
> Does the MVT driver support updates and the creation of multiple layers
> using the -append -update methods
No, it is one time creation only. To achieve what you want to do, you can
typically create a input VRT file that has multiple
Does the MVT driver support updates and the creation of multiple layers
using the -append -update methods
Something like:
ogr2ogr -f MVT -dsco NAME=MyTiles -dsco DESCRIPTION="My Tileset Description
" -dsco FORMAT=MBTILES -lco NAME=Layer1 -lco DESCRIPTION="My Layer
Description" results.mbtiles lay
Hi,
This is a topic we already discussed a couple years ago. Please find a RFC
about it in:
https://github.com/OSGeo/gdal/pull/1984/files
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-de
On mardi 5 novembre 2019 01:18:35 CET Julien Demaria wrote:
> Hi Even,
>
> Are you sure that the driver uses a default fill value if the attribute is
> not present?
Yes, the raster band constructor systematically called SetNoDataValue() even
if the bGotNoData flag was not set before.
Thanks a l
21 matches
Mail list logo
