clang-format keeps the blocks independent, yes. We usually divide in three
(or more) blocks: internal headers, third party, std. But it is a matter of
taste, of course.
This is the example of a file that uses gdal:
#pragma once
#include "CommandOptions.h"
#include
#include
#include
#include
On Thu, 24 Nov 2022, Javier Jimenez Shaw wrote:
In my opinion if the order of the includes affects the output there is
something wrong in the code. I hope md5 is not recommending the order.
It turns out that although 'man md5' says:
#include
#include
the header file /usr/include/m
Le 24/11/2022 à 19:18, michael.smith.e...@gmail.com a écrit :
I don’t believe these are huge features, its OSM building for the
world. Must be the memory constraint since it is a lot of features.
This doesn’t happen (i think, am retesting now) if created from the
osm pbf file directly but does
I don’t believe these are huge features, its OSM building for the world. Must be the memory constraint since it is a lot of features. This doesn’t happen (i think, am retesting now) if created from the osm pbf file directly but does from the fgb created from the pbf. Do either of the columnar forma
Mike,
Le 24/11/2022 à 18:56, michael.smith.e...@gmail.com a écrit :
Basically, can one create a spatial index in a flatgeobuf file if the
source does not have one?
yes, through ogr2ogr by creating a new file, as you did
Also, when trying to just create a new flatgeobuf with a spatial inde
Basically, can one create a spatial index in a flatgeobuf file if the source
does not have one?
Also, when trying to just create a new flatgeobuf with a spatial index from one
without (using ogr2ogr), I get a lot of
ERROR 2: ICreateFeature: Too big feature
Mike
--
Michael Smith
US Army
Refer to Kakadu docs & support for that. There's definitely a way of
generating it, but Kakadu build system is ahem ... "particular"
Le 24/11/2022 à 14:37, Johannes Paul a écrit :
Hello Even,
Thanks for your reply, i did notice that, however libkdu_a82R.so is
not generated at kakadu compi
Hello Even,
Thanks for your reply, i did notice that, however libkdu_a82R.so is not
generated at kakadu compilation.
I only get libkdu_v82R.so and libkdu.a
Rgds,
Johannes
Le jeu. 24 nov. 2022 à 14:14, Even Rouault a
écrit :
> The value of KDU_AUX_LIBRARY is wrong. See
>
> https://gdal.org/develo
The value of KDU_AUX_LIBRARY is wrong. See
https://gdal.org/development/building_from_source.html#cmdoption-arg-KDU_AUX_LIBRARY
It should be -DKDU_AUX_LIBRARY="${INSTALLDIR}"/lib/libkdu_a82R.so"
Even
Le 24/11/2022 à 10:35, Johannes Paul a écrit :
Hello,
I'm having trouble compiling GDAL 3.6.
I'm pretty sure that in the past I've fought against issues related to
include orders, at least on some platforms, and some things were beyond
our control (system headers or dependency headers), so I think it is
best to exclude it for now as Alessandro just did for something that is
intended to
In my opinion if the order of the includes affects the output there is
something wrong in the code. I hope md5 is not recommending the order.
I find the ordering feature very useful as a way to detect those errors
(not definitive because it is not testing every combination, but a fixed
criterion i
Il 24/11/22 10:55, Andrew C Aitchison ha scritto:
On Thu, 24 Nov 2022, ElPaso wrote:
Hi,
Motion:
Adopt RFC88: RFC69 C/C++ Code Formatting [1]
I have updated the RFC [1] to use pre-commit and I have created a
draft implementation of the pre-commit hook and the CI integration
with a GH workf
On Thu, 24 Nov 2022, ElPaso wrote:
Hi,
Motion:
Adopt RFC88: RFC69 C/C++ Code Formatting [1]
I have updated the RFC [1] to use pre-commit and I have created a draft
implementation of the pre-commit hook and the CI integration with a GH
workflow [2].
If adopted, we still have to agree on wh
Hello,
I'm having trouble compiling GDAL 3.6.0 on Centos7 with JP2KAK driver using
Kakadu 8.2.
I'm following the below instructions to compile KDU
https://trac.osgeo.org/gdal/wiki/JP2KAK
And I'm using the following cmake options to compile GDAL
-DGDAL_USE_KDU=ON -DKDU_INCLUDE_DIR="${INSTALLDIR}"
Hello,
I'm having trouble compiling GDAL 3.6.0 on Centos7 with JP2KAK driver using
Kakadu 8.2.
I'm following the below instructions to compile KDU
https://trac.osgeo.org/gdal/wiki/JP2KAK
And I'm using the following cmake options to compile GDAL
-DGDAL_USE_KDU=ON -DKDU_INCLUDE_DIR="${INSTALLDIR}"
-D
Hi,
Motion:
Adopt RFC88: RFC69 C/C++ Code Formatting [1]
I have updated the RFC [1] to use pre-commit and I have created a draft
implementation of the pre-commit hook and the CI integration with a GH
workflow [2].
If adopted, we still have to agree on which coding style to apply (for
now I
16 matches
Mail list logo