Varying tile sizes: we definitely don't support that, and I don't think
any of the OGC tiling specifications do. I guess that could be
implemented (what can't?) but the WMS driver definitely doesn't
currently. The code you spotted is for tiles at the right and bottom
edges of the virtual
We recently began seeing the following error (which doesn’t seem to produce
incorrect output images)
ERROR 1: _TIFFVSetField:/vsimem/gtiff/thread/job/0x1f5d0970: Bad value 4 for
"ExtraSamples" tag
when creating a geotif image from C++ with creation options:
char *disk_create_options[] =
Le 08/03/2024 à 18:34, Javier Jimenez Shaw a écrit :
I don't like that the behaviour of a command line depends on the
configuration of the user (that is usually not aware of). So a command
that works for me doesn't work for you. That is bad.
I was perhaps not clear. Let me clarify, but at
> I don't like that the behaviour of a command line depends on the
> configuration of the user (that is usually not aware of). So a command that
> works for me doesn't work for you. That is bad.
>
+1
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
I don't like that the behaviour of a command line depends on the
configuration of the user (that is usually not aware of). So a command that
works for me doesn't work for you. That is bad.
I don't know in GDAL, but in proj there is the option --bbox, that has
comma separated coordinates. That can
In principle the idea sounds good.
How is it parsing the numbers? is it locale agnostic? I think it is
not, because it is using "strtod". That means that if I have my locale
in Spanish, French, German, ... it will expect "," as the decimal
separator, right?
if running under a non-C
Some options have related environment variables, eg --debug /CPL_DEBUG.
Options are also passed through to several drivers.
I assume that the implications for these are not significant ?
This wouldn't change the general logic of GDAL and so the existing
(possibly confusing) set of various type
Hi Even.
In principle the idea sounds good.
How is it parsing the numbers? is it locale agnostic? I think it is not,
because it is using "strtod". That means that if I have my locale in
Spanish, French, German, ... it will expect "," as the decimal separator,
right?
... well, how is GDAL
Le ven. 8 mars 2024, 17:42, Even Rouault a
écrit :
> Thomas,
> >
> > my number 1 requirement would be that the rewrite not cause any
> > backwards compatibility issues compared to today's argument handling.
> > I suspect many users are calling the gdal utilities through scripts
> > and it would
Hi all,
I've been trying to set up the GDAL WMS driver to work with an ArcGIS tile
service, as described at
https://gdal.org/drivers/raster/wms.html#arcgis-rest-api
Everything works fine for Web Mercator services, but I'm not able to get this
to work with a different projection.
I've used the
On Fri, 8 Mar 2024, Even Rouault via gdal-dev wrote:
Hi,
Our command line C++ utilities use ad-hoc manual parsing, which means that:
- the usage message must be manually composed,
- you must take care to check that there are enough remaining arguments for
the ones that take value to avoid
Thomas,
my number 1 requirement would be that the rewrite not cause any
backwards compatibility issues compared to today's argument handling.
I suspect many users are calling the gdal utilities through scripts
and it would be a pain to have to update those when upgrading gdal.
Yes,
Hi Even,
my number 1 requirement would be that the rewrite not cause any backwards
compatibility issues compared to today's argument handling. I suspect many
users are calling the gdal utilities through scripts and it would be a pain
to have to update those when upgrading gdal.
a nice to have
Hi,
Our command line C++ utilities use ad-hoc manual parsing, which means that:
- the usage message must be manually composed,
- you must take care to check that there are enough remaining arguments
for the ones that take value to avoid out-of-bounds accesses (tests like
argc + 1 < argn)
Le 07/03/2024 à 20:44, Kurt Schwehr a écrit :
+0 KurtS. It seems like a good idea, but I worry about
unintended consequences, but can't come up with any.
I'm quite confident that as most new features (or sometimes even
bugfixes), it will cause issues in some scenarios. Hopefully it will
Hi,
Varying tile sizes: we definitely don't support that, and I don't think
any of the OGC tiling specifications do. I guess that could be
implemented (what can't?) but the WMS driver definitely doesn't
currently. The code you spotted is for tiles at the right and bottom
edges of the virtual
Hi,
I only managed to force the creation of the .aux.gml file with a workaround.
gdal_translate p4433h.tif test.tif -co profile=baseline
In this case it seems that not even --config GDAL_PAM_ENABLED YES is needed but
test.tif.aux.xml gets created. Maybe the same PAM file works also for the
I hate that.
I never use "long" exactly for that problem. When the size is important,
uint64_t and friends are very useful, and well defined.
On Fri, 8 Mar 2024 at 10:16, Abel Pau via gdal-dev
wrote:
> FINALLY!
>
> I discovered the problem.
>
>
>
> I was using “unsigned long” as 4 bytes
Dear Developers,
I am reaching out to seek advice or potential solutions regarding the
creation of .aux.xml files for GeoTIFF Or GOG using GDAL. I have attempted
using the following commands, like so:
os.environ['GDAL_PAM_ENABLED'] = 'YES'
os.environ['GDAL_GEOREF_SOURCES'] =
FINALLY!
I discovered the problem.
I was using “unsigned long” as 4 bytes variable. On windows it’s like that.
BUT on linux this kind of variable has a 8-bytes size.
This caused a mess in linux (but not in wondows).
So, mistery closed!
Thanks you all.
De: gdal-dev En nombre de Abel Pau
20 matches
Mail list logo
