Hi,
lately I've been solving some issues in my code to finally do a pull request of
the MiraMon vector driver.
There some things about test in the action I don't understand. I haven't commit
any test yet. So I assume it's not my fault.
Anyone knows why some of them are failing?
At macos_build
Hi,
On Tue, 20 Feb 2024 at 21:44, Robert Coup
wrote:
> Hi Simon,
>
> On Tue, 20 Feb 2024 at 21:11, Simon Eves wrote:
>
>> Here's the stack trace for the original assert. Something is stepping on
>> scratch_ to make it 0x10 instead of null, which it starts out as
>> when the flatbuffer
gdb) p m_fbb
$5 = (flatbuffers::FlatBufferBuilder &) @0x7fff9070: {static
kFileIdentifierLength = 4, buf_ = {allocator_ = 0x0, own_allocator_ =
false, initial_size_ = 1024, buffer_minalign_ = 8, reserved_ = 0, size_ =
0, buf_ = 0x0, cur_ = 0x0,
scratch_ = 0x1 }, num_field_loc =
Here's the stack trace for the original assert. Something is stepping on
scratch_ to make it 0x10 instead of null, which it starts out as
when the flatbuffer object is created, but by the time it gets to
allocating memory, it's broken.
On Tue, Feb 20, 2024 at 1:05 PM Simon Eves wrote:
>
(starting a new thread to avoid derailing the static-build one any further)
Totally agreed on the mismatch idea, but the code in question is all
self-contained down in *ogr/ogrsf_frmts/flatgeobuf* and the *flatbuffers*
sub-project (which is a snapshot of a Google OSS project) so I'm struggling
to
Hi Simon,
On Tue, 20 Feb 2024 at 18:58, Simon Eves via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> We still have one VERY strange issue whereby FlatGeoBuf export fails in a
> very consistent and reproducible form down in the flatbuffer code, but only
> in the static build, and only in the full
One of our build variants is a fully-static (or as-static-as-possible) done
on CentOS 7 for old-Linux compatibility.
In reverse-dependency order we have static builds of
SQLite 3450100
Expat 2.5.0
KML 1.2.0
HDF5 1.12.1
NetCDF 4.8.1
TIFF 4.5.1
Proj 9.3.0
GeoTIFF 1.7.1
LittleCMS 2.15
WebP 1.3.2
Hi,
On Tue, 20 Feb 2024 at 12:50, Michael Otto
wrote:
>
> I have now tried it with 'vcpkg install gdal[tools]'. The tools/apps are
> there, but they are not statically linked!
>
> See for example gdalinfo:
>
> root@vmuser-VirtualBox:/home/vmuser/Git/vcpkg/installed/x64-linux/tools/gdal#
> ldd
Jukka,
I would probably completely remove that paragraph, or at least remove
the wrong hint on how to check if permissions are correct. Correct
permission settings of a PostgreSQL/PostGIS database is probably out of
scope of the driver documentation. But your suggestion for an alternate
Hi,
I don't undestand this part of the PosgGIS driver documentation
https://gdal.org/drivers/vector/pg.html#faqs
"Permission issues on geometry_columns and/or spatial_ref_sys tables can be
generally confirmed if you can see the tables by setting the configuration
option PG_LIST_ALL_TABLES to
Thanks to all who have responded.
I have now tried it with 'vcpkg install gdal[tools]'. The tools/apps are
there, but they are not statically linked!
See for example gdalinfo:
root@vmuser-VirtualBox:/home/vmuser/Git/vcpkg/installed/x64-linux/tools/gdal#
ldd gdalinfo
linux-vdso.so.1
> > The directory './vcpkg/packages/_x64-linux' now contains the
> > compiled static versions of the libraries. But where can I find the GDAL
> > apps? These are not contained in this directory.
Ignore packages. It is a staging area. `installed` is the real thing.
Kai
Hi Michael,
On Tue, 20 Feb 2024 at 11:22, Michael Otto
wrote:
> The directory './vcpkg/packages/_x64-linux' now contains the
> compiled static versions of the libraries. But where can I find the GDAL
> apps? These are not contained in this directory.
Great! So if you change your vcpkg
When you install gdal[tools], the apps are installed to
`/tools/gdal`.
(The vcpkg focus is on providing libs build from source.)
To explore port features, you can look at the port's vcpkg.json (aka
manifest), or start from
https://vcpkg.link/ports/gdal
Regards,
Kai
Am 20.02.24 um 12:22
Le 20/02/2024 à 11:15, Elena Ruiz via gdal-dev a écrit :
Hello, I have version 3.6.2 of GDAL and I need to crop an image using
a contour from a GML file, so far there is no problem.
The problem begins when the original image is a GEOTIFF with
transparency and it generates a cropped image,
Hi Robert,
because I'm not getting anywhere with the "standard" CMake solution, I've
now used the vcpkg you mentioned and am using it in a Virtualbox VM with
Linux Mint.
I got the installation instructions from here:
https://github.com/microsoft/vcpkg?tab=readme-ov-file#quick-start-unix. I
Hello, I have version 3.6.2 of GDAL and I need to crop an image using a contour
from a GML file, so far there is no problem.
The problem begins when the original image is a GEOTIFF with transparency and
it generates a cropped image, the information of both images is a little lower.
The color
17 matches
Mail list logo
