Re: [gdal-dev] OGR C API PostGIS geometry with wrong field entries

I am no Postgre expert but we have experienced similar cases when running complex transactions with large geometries, i.e. faulty results. When splitting the transaction into several pieces, i.e. enforcing COMMITs (Postgre doesn't support COMMIT inside functions), the correct results are given.

Re: [gdal-dev] OGR C API PostGIS geometry with wrong field entries

Even, On Mon, Dec 2, 2019 at 7:46 PM Even Rouault wrote: > > Markus, > [...] > > Are you sure there's no latent memory corruption in v.in.ogr ? Did you check > with Valgrind ? Yes, I checked with valgrind, no memory corruption. I tried v.in.ogr with other OGR formats, no problem. I am out of ide

[gdal-dev] gdal_translate geotiff to netcdf: values

HelloI have a geotiff file of sea ice concentration.When I use gdal_info it gives a series of values like:   Metadata:     COLORINTERP=Palette   Color Table (RGB with 65536 entries)     0: 9,60,112,255     1: 9,60,112,255     2: 9,60,112,255     3: 9,60,112,255     4: 9,60,112,255     5:

Re: [gdal-dev] OGR C API PostGIS geometry with wrong field entries

Markus, > In the GRASS module v.in.ogr we follow pretty much the vector API tutorial. > The only difference is that we first fetch the geometry of a feature, then > the fields. When input is a PG database, sometimes the wrong field entries > are associated with the geometries, as if geometries and

[gdal-dev] OGR C API PostGIS geometry with wrong field entries

In the GRASS module v.in.ogr we follow pretty much the vector API tutorial. The only difference is that we first fetch the geometry of a feature, then the fields. When input is a PG database, sometimes the wrong field entries are associated with the geometries, as if geometries and field entries we

Re: [gdal-dev] ogr2ogr (I)LIKE not caseINsensitive

> 2) more work. for WFS, have LIKE and ILIKE having two different > translations. But if we do so, as we would need to add a new SWQ_ILIKE > operator, and we should also probably make LIKE and ILIKE be distinct > operations on a pure OGR SQL evaluation (client side). Which has some > backward compa

Re: [gdal-dev] Error in Derived Band in Virtual raster (re-post)

Hi Jukka Rahkonen Thanks for the reply. Actually the add2 function is inside the code. I feel the browser excluded that portion the code was -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___

Re: [gdal-dev] Error in Derived Band in Virtual raster (re-post)

Hi Jukka Rahkonen Thanks for the reply. Actually the add2 function is inside the code. I feel the browser excluded that portion the code was -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev ma

Re: [gdal-dev] Error in Derived Band in Virtual raster (re-post)

Hi Jukka Rahkonen Thanks for the reply. Actually the add2 function is inside the code. I feel the browser excluded that portion the code was -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev ma

Re: [gdal-dev] Error in Derived Band in Virtual raster (re-post)

Hi Jukka Rahkonen thank you for your reply But the code of add2 function is in the same VRT file. Need I store in a separate file as well. GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0],UNI

Re: [gdal-dev] Error in Derived Band in Virtual raster (re-post)

GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4326"]] 7.8318056012634287e+01, 1.1839023066784193e-04, 0.e+00, 3.08665472

Re: [gdal-dev] Error in Derived Band in Virtual raster (re-post)

Hi Jukka Rahkonen thank you for your reply But the code of add2 function is in the same VRT file. Need I store in a separate file as well. -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-de

Re: [gdal-dev] Error in Derived Band in Virtual raster (re-post)

Hi, Re-posting because the code section that Nabble wrote as html formatted was dropped out. Did the same thing happen for you with your original mail? It seems that you have defined a Python function "add2" that does nothing because it has no code add2 Python

Re: [gdal-dev] Error in Derived Band in Virtual raster

Hi, It seems that you have defined a Python function "add2" that does nothing because it has no code add2 Python You have perhaps tried to modify the example from https://gdal.org/drivers/raster/vrt.html add Python Have you saved your