Tim,
You guessed right.
> Is there any way to write a geodatabase to a vsimem path,
No
> or is that
> something ESRI would have to change in their SDK?
Yes. There is no customizable file abstraction layer in the SDK.
On Linux, you could probably use a tmpfs mount as a workaround.
Even
--
Is there any way to write a geodatabase to a vsimem path, or is that something
ESRI would have to change in their SDK? It looks like it just writes to the
filesystem under a /vsimem directory at the moment...
___
gdal-dev mailing list
gdal-dev@lists.osg
Thanks Even;
>> There's a specific processing for the 'id' field indeed. It is written at
>> the
>> 'id' JSon member, at the same level of 'properties'. And thus on reading, it
>> is exposed in the OGR Feature ID, not as an attribute.
Im not getting the id field at all. Each feature just has
>
> Sounds like either you lack the libgdal.so in your library search path, or it
> is an older version of it. You can tune that with LD_LIBRARY_PATH for example
>
Right, but no matter I define LD_LIBRARY_PATH jupyter always look in /usr/lib64
(on Fedora).
So I've solved the issue linking my v
On vendredi 14 septembre 2018 16:25:27 CEST David McKelvie wrote:
> Hi;
>
> I have a question about ogr2ogr output from a postgres database to geojson.
>
> One of the fields in my table, ie the primary key called 'id' is not being
> output to the json file. I wonder if this is a bug or a 'feature
Hi;
I have a question about ogr2ogr output from a postgres database to geojson.
One of the fields in my table, ie the primary key called 'id' is not being
output to the json file. I wonder if this is a bug or a 'feature'.
Can anybody clarify this?
The database table is:
---
Hi Even,
Thanks for your kind response and information.
I'm sorry, I should have clarified that I'm using GDAL ver. 2.3.1. I have
used /MTd both in the test app and in nmake.opt when compiling GDAL.
Changing both to /MDd doesn't seem to make a difference - the same fatal
exception occurs.
The ca
On vendredi 14 septembre 2018 09:09:17 CEST Chiara Marmo wrote:
> Hello,
>
> I'm on Fedora28
> I'm working on a custom version of GDAL (only fitsdataset.cpp is modified),
> up to date with the last upstream version from github.
>
> I need to test python bindings: so I've followed the instructions
On mercredi 12 septembre 2018 01:48:34 CEST krikr42 wrote:
> Hi,
>
> I have two tiff images, of which the first one is a GeoTIFF image and the
> second is a tiff image created from the first one by opening it with pyvips
> in Python, modifying it (blurring it) and saving it as a new file (so I
> d
If you're willing to use command line tools, there is a pair of
tools that ship with libgeotiff for extracting metadata from a
geotiff and importing into a tiff to make it a geotiff.
Given a
GeoTIFF file
named original.tif, and a modified file (modified.tif)
Hello,
I'm on Fedora28
I'm working on a custom version of GDAL (only fitsdataset.cpp is modified), up
to date with the last upstream version from github.
I need to test python bindings: so I've followed the instructions here[1] in
order to have them linked with my gdal version.
The build proces
Hi Kristofer,
We have a function to transfer the tags manually, but most of the information
is in the domain without a name - you have to call ds.GetMetadata(''). It goes
something like this. For the bands, we're only copying some items, but you
could take out the for loop and copy them all.
12 matches
Mail list logo
