You did not count the band size when allocating memory for the buffer.
That should be:
byte[] readRaster = new byte[tileSize * tileSize * 4];
Or alternatively use Band.ReadRaster to read just a specific band.
Best regards,
Tamas
Gigas002 ezt írta (időpont: 2018. nov. 12., H, 17:34):
> Hi
Hi all.
I've rewritten some python code from gdal2tiles.py on c#, using GDAL.NET
nuget package (ver. 2.3.1). Here you can see the working python code:
def create_overview_tiles(input_file, output_file):
tile_driver = 'PNG'
tile_size = 256
tilebands = 4
resampling =
Even,
I think your 'toy' is a real gem which deserves to live (if only as
something flagged 'experimental').
AFAIK this would be the only option for GDAL users to extend GDAL on run
time.
Confining this technique to run time only extensions IMHO addresses the main
concerns in the discussion.
Ma
On lundi 12 novembre 2018 08:48:59 CET Robert Coup wrote:
> Hi Even,
>
> On Mon, 12 Nov 2018 at 07:57, Even Rouault
>
> wrote:
> > Not completely sure what to do with GDAL 2.3 branch, as it already had
> > ZStd
> > (if using its internal libtiff copy). I feel it is probably wise to also
> > upda
On lundi 12 novembre 2018 01:48:03 CET deduikertjes wrote:
> I'd love to have the possibility to add drivers to GDAl using Python.
>
> Use case for me is all those services/ datasets containing useful geo
> data but adhere to no standard. Being able to create a driver quickly to get
> it in QGIS o
Hi Even,
On Mon, 12 Nov 2018 at 07:57, Even Rouault
wrote:
>
> Not completely sure what to do with GDAL 2.3 branch, as it already had
> ZStd
> (if using its internal libtiff copy). I feel it is probably wise to also
> update the modified value of COMPRESSION_ZSTD there to avoid the risk of
> peo
I'd love to have the possibility to add drivers to GDAl using Python.
Use case for me is all those services/ datasets containing useful geo
data but adhere to no standard. Being able to create a driver quickly to get
it in QGIS or an ETL proces is
really useful.
Did this proposal ever make it to
