like the location of proj.db used.
The point is if you can see the std out.
On Wed, 11 Oct 2023, 15:18 Jonathan Moules via gdal-dev,
wrote:
Hi List,
So, after more investigation:
* Using Python Anaconda on either Mac or Linux for GDAL (3.7.1),
`GetSpatialRef` triggers a R
GDAL,
Conda, Pycharm, something else?
Cheers,
Jonathan
On 2023-09-28 14:58, Jonathan Moules via gdal-dev wrote:
Well, it seems that PROJ_DATA isn't set in their environment. But it's
not set in mine either (`print(os.environ['PROJ_DATA']`)! So no idea
why mine works just fi
system.
On 2023-09-28 12:37, Rahkonen Jukka wrote:
Hi,
Then they should add that environment if they do not know that they do not belong to
"most users" https://proj.org/en/9.3/usage/environmentvars.html
-Jukka Rahkonen-
-Alkuperäinen viesti-
Lähettäjä: gdal-dev Puolesta
Hi Even,
The colleague doesn't have either a PROJ_LIB or a PROJ_DATA environment
variable.
I asked another colleague to try it; they're on Ubuntu 20.04, and it
worked for them. I believe using the same setup instructions.
Cheers,
Jonathan
On 2023-09-24 22:37, Jonathan Moules vi
to use to diagnose the issue.
On 2023-09-24 22:52, Jan Heckman wrote:
Sorry to break in, but surely, we would like to see the .prj file in
question for a simple try at reproducing?
On Sun, Sep 24, 2023 at 11:37 PM Jonathan Moules via gdal-dev
wrote:
Thanks Even. I don't have access
Thanks Even. I don't have access to the machine either as the colleague
is moving to another project. I'll have to see if it fails for another
*nix user.
On 2023-09-24 22:35, Even Rouault wrote:
Le 24/09/2023 à 23:22, Jonathan Moules via gdal-dev a écrit :
> Also check if th
variable
Le 21/09/2023 à 14:34, Jonathan Moules via gdal-dev a écrit :
Yeah, I'm afraid the error message is pretty much non-existent:
Traceback (most recent call last):
File
"/home/name/Code/DSHub/PoC/Extract-Transform-Load-POC/Metadata/AME/src/info_vect
Tested against the following data types (OGR and GDAL):
GeoJSON, KML, KMZ, Shapefile, ECW, IMG, TIF, GML, ASC, Geopackage, NetCDF.
Only the shapefile fails.
On 21/09/2023 13:34, Jonathan Moules wrote:
Yeah, I'm afraid the error message is pretty much non-existent:
Traceback
untimeError
Suggestions welcome.
On 18/09/2023 12:51, Javier Jimenez Shaw wrote:
Hi Jonathan
Which exact RuntimeError are you getting? It can be for several
reasons (probably an installation or configuration issue).
Best,
Javier
On Mon, 18 Sept 2023 at 11:06, Jonathan Moules
wrote:
d a wheel).
Cheers,
Jonathan
On 18/09/2023 12:51, Javier Jimenez Shaw wrote:
Hi Jonathan
Which exact RuntimeError are you getting? It can be for several
reasons (probably an installation or configuration issue).
Best,
Javier
On Mon, 18 Sept 2023 at 11:06, Jonathan Moules
wrote:
Hi List
Hi List,
I'm trying to get vector layer information via OGR and Python:
```
layer.GetSpatialRef()
```
This works fine for me on Windows with GDAL 3.7.1 on various different
types of files (Shapefile, GPKG, GML, KML, GDB).
But for my colleague on Ubuntu 22.0.4.3, also on GDAL 3.7.1 (via Con
Hi Isabel,
If you don't get an answer here, you may want to try the SQLite forum:
https://sqlite.org/forum/forum - If anyone knows, it'll be someone there.
Maybe also of interest: https://sqlite.org/howtocorrupt.html#cfgerr
Cheers,
Jonathan
On 2022-02-14 08:17, Isabel Kiefer wrote:
Hi ever
I guess this is what you want:
132000
248000
Which I'm assuming means it's not tile.
On 2020-08-09 15:46, Even Rouault wrote:
On dimanche 9 août 2020 15:30:12 CEST Jonathan Moules wrote:
> Hi Even,
>
> Ah, it's comma delimited. I tried spaces.
ATE=YES
STATISTICS_MAXIMUM=255
STATISTICS_MEAN=243.35889029004
STATISTICS_MINIMUM=168
STATISTICS_STDDEV=16.164314681862
STATISTICS_VALID_PERCENT=100
Image Structure Metadata:
COMPRESSION=JPEG2000
...
GDAL: GDALClose(FILENAME.jp2,this=060407F0)
On 2020-08-09 15
Hi Even,
Thanks for getting back to me. I'm a little rusty with GDAL; it has
probably been 5+ years since I last used it.
I can confirm my QGIS install version (OSGEO4W) does have the JP2ECW
driver (`gdalinfo --formats`).
I'm using the Python GDAL build from
https://www.lfd.uci.edu/~gohlke/
Hi List,
I have a JP2 file I'm trying to process with Rasterio in Python. But I'm
getting this error:
rasterio.errors.RasterioIOError: Read or write failed. FILENAME.jp2,
band 1: IReadBlock failed at X offset 40, Y offset 90: opj_decode() failed
That error seems to come from GDAL. I've tried
Hi Craig,
For my suite I've used pytest_make_parameterize_id to auto-create id's
using the first parameterised value as the id name if that parameter is
called "_" (just underscore - the Python convention for a throwaway
variable). It works really well, although would need some work for
backw
Hi,
PyTest is a great test-suite.
If I may make one suggestion as someone who has used it for a while -
it's worth spending a little thought on coming up with a scheme for
test-ids. Especially if you're going to use parameterisation.
Otherwise PyTest comes up with names that may be accurate
Hi Jukka,
I'm still very new to ElasticSearch (so take with plenty of salt!), but
if you want to keep the geom in _source and calculate on the fly, I
guess you could maybe try it with one of the scripting languages:
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripti
Hi List,
I'm running the following four queries against the same data (a packbits
compressed geotiff):
gdaladdo -r average --config COMPRESS_OVERVIEW JPEG --config
PHOTOMETRIC_OVERVIEW YCBCR i1.tif 2 4 8 16
gdaladdo -r average --config PHOTOMETRIC_OVERVIEW YCBCR i2.tif 2 4 8 16
gda
7;m surprised this doesn't happen more often with various
>packages\files. I thought projections were nice and reasonably well defined
>things.
Thanks again,
Jonathan
On Tue, 17 Nov 2015 10:33:37 -0800 Even
Rouault<even.roua...@spatialys.com> wrote
Le mardi 17 novemb
ion?
Thanks,
Jonathan
On Tue, 17 Nov 2015 09:18:49 -0800 Even
Rouault<even.roua...@spatialys.com> wrote
Le mardi 17 novembre 2015 17:55:15, Jonathan Moules a écrit :
> Hi List,
> I have a Geotiff which includes this projection:
>
> PROJ.4 : '+proj=merc
Hi List,
I have a Geotiff which includes this projection:
PROJ.4 : '+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs
'
OGC WKT :
PROJCS["Mercator",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY
Hi Stefan,
How large is the image? As in, pixel width & height.
Also the GDALinfo would be helpful.
7 days is a very long time. I've seen times like that myself for images that
were 100,000*50,000 or similar dimensions where there was (still is?) an issue
with the pyramiding function in GDAL (i
Hi List,
I have four band (RGB plus Infrared) imagery from some aerial photography
we've had flown. I've already used GDAL to create suitable optimised RGB
GeoTIFFs using this data and now want to do it with the Infrared band too.
The RGBI data is about 1TB uncompressed, currently stored as 2732
Hi David,
> Here's a crazy idea could you perhaps use mm and then output to an integer
> raster? No problem representing 50597mm.
>
I like you thinking! But on reflection suspect that would confound a few
too many of our users. It's certainly a nice lateral-thinking solution to
bear in mind for
Hi Even,
> Well, I don't know MapInfo limits with raster files. Perhaps is it just big
> raster dimensions that cause problem, or tiling, or .. ?
>
I guess it's size. I've tried with no compression, no tiles, and both no
compression or tiling, all fail. So I guess a MapInfo thing then.
Thanks,
J
Hi List,
I've created a GeoTIFF with GDAL. It works fine in QGIS and ArcMap, but
MapInfo refuses to load it, giving me a "Image file open error" message.
I've come across several problems and was wondering if anyone else had
experience with GDAL created files in MapInfo.
Problems:
1) MapInfo can'
Hi Even,
Thanks for the information.
> >
> > I tried the Float64 but the values are identical (16 significant figures)
> > even though the filesize is predictably larger.
> >
> > I guess I'll have to make do, but it does introduce the problem of False
> > Precision.
>
> Very few formats take into
>
> TIFF stores floating point values as IEEE754 floats. Talking about
> significant
> figures doesn't make much sense. You could test using Float64 with the hope
> that 50.597 can be exactly represented as a Float64. Otherwise you'll have
> to
> do the rounding when reading back from TIFF.
>
Hi
ficant digits
> (~16) than your source, so it's representation is "ok" in double format
>
> see [1] for an explanation on floating-point precision
>
> the following argument would do this "-ot Float32"
>
> [1] http://en.wikipedia.org/wiki/Floa
ion
How do I get GDAL to merge these into a GeoTIFF without altering the data?
Thanks,
Jonathan
On 24 January 2014 16:12, Jonathan Moules <
jonathanmou...@warwickshire.gov.uk> wrote:
> Thanks Norman. I'd already seen that page but failed to read it!
> However, having tested it,
-co DECIMAL_PRECISION=3 abc.vrt abc.asc
>
> see http://www.gdal.org/frmt_various.html
> HTH
> Norman
>
> On Jan 24, 2014, at 10:01 AM, Jonathan Moules <
> jonathanmou...@warwickshire.gov.uk> wrote:
>
> Hi List,
> I'm trying to mosaic some ASCII grid tiles in
Hi List,
I'm trying to mosaic some ASCII grid tiles into a single large ASCII file
(which can then easily be handled).
I'm using this process:
> REM Create list of files
> dir /b /s *.asc > asc_list.txt
>
> REM Turn into VRT
> gdalbuildvrt -srcnodata "-" -vrtnodata "0" -a_srs "EPSG:27700"
>
5,255,254) so I won't
get the white-border-effect. I guess I'll find out if/when I get to that
point.
Cheers,
Jonathan
On 4 December 2013 06:58, Jukka Rahkonen wrote:
> Jonathan Moules warwickshire.gov.uk> writes:
>
> >
> >
> >
> > Hi Even,
&g
Many thanks!
Jonathan
On 3 December 2013 16:02, Even Rouault wrote:
> Selon Jonathan Moules :
>
> > Hi List,
> > I have a question about setting a value as "noData" in GeoTIFFs.
> >
> > I'm creating a Geotiff with this two stage process (mosaicing a l
Hi List,
I have a question about setting a value as "noData" in GeoTIFFs.
I'm creating a Geotiff with this two stage process (mosaicing a lot of
tiles together):
gdalbuildvrt -hidenodata -srcnodata 255 -vrtnodata 255 -input_file_list
>> tiff_list.txt 255.vrt
>
>
>> gdal_translate -of GTiff -co
rk. Useful to know it's not here.
Thanks again,
Jonathan
On 2 December 2013 19:03, Even Rouault wrote:
> Le lundi 02 décembre 2013 19:42:59, Jonathan Moules a écrit :
> > On 2 December 2013 18:32, Even Rouault
> wrote:
> > > Le lundi 02 décembre 2013 19:12:07, Jo
On 2 December 2013 18:32, Even Rouault wrote:
> Le lundi 02 décembre 2013 19:12:07, Jonathan Moules a écrit :
> > Hi Even,
> > To hit the 10GB limit I'm using (Windows Server 2008):
> >
> > gdal_translate -of GTiff -co TILED=YES -co BIGTIFF=YES -co COMPRESS=
ouault wrote:
> Le lundi 02 décembre 2013 18:49:42, Jonathan Moules a écrit :
> > Hi Even,
> > A further thought while we're on the issue of limits, it appears that
> gdal
> > (both gdal_translate and gdalwarp) have an internal limit of 10GB when
> > they're
December 2013 17:25, Jonathan Moules <
jonathanmou...@warwickshire.gov.uk> wrote:
> Hi Even,
> Thanks for the detailed reply. It seems in the end that I can use a
> combination of gdalbuildvrt and gdal_translate to get the same results
> without having to bother with manual memory managem
Hi List,
I've just tried the following:
call gdalwarp -of GTiff *-wm 13000* -co TILED=YES -co BIGTIFF=YES -co
COMPRESS=JPEG -co JPEG_QUALITY=80 -co BLOCKXSIZE=512 -co BLOCKYSIZE=512 -co
PHOTOMETRIC=YCBCR SP1937.tif SP1938.tif SP1939.tif 1.tif
The documentation says:
> -wm memory_in_mb:
> Set the
ndersteuning
>
> voor MapWindow GIS <http://www.mapwindow.org/>
>
>
>
> 2013/12/2 Jonathan Moules
>
>> Hi List,
>> I'm trying to batch (Windows) a fairly simple task - mosaic and then
>> pyramid some rasters.
>>
>> While testing, I'
Hi List,
I'm trying to batch (Windows) a fairly simple task - mosaic and then
pyramid some rasters.
While testing, I've simplified my batch file down to two lines:
gdal_merge -o %THIS_DIR%.tif -of GTiff -co TILED=YES -co BIGTIFF=YES -co
> COMPRESS=JPEG -co JPEG_QUALITY=80 -co BLOCKXSIZE=512 -co B
>- From there I've tried both the msi (plus python bindings extra) and
>> the
>> zip "Compiled binaries in a single .zip package"- both work for the
>> pure-GDAL stuff (gdalinfo) but none of the python scripts works (i.e.
>> gdal_merge.py).
>>
>
> I prefer the zip version, expand it to a folder
Wow, that actually worked!
/me is pleasantly surprised. :-)
Thanks!
On 27 November 2013 16:15, Mateusz Loskot wrote:
> On 27 November 2013 16:02, Jonathan Moules
> wrote:
> > So in short, where can I go to find a pre-compiled (Windows, ideally
> 64bit)
> > version of
Hi List,
I'm bringing this one over from the GeoServer-Users list. Basically I can't
for the life of me get a good install of GDAL for Windows where everything
*just works*.
To date I've tried:
http://gisinternals.com/SDK/P
- But there are far too many options and I can never be sure I'm getting
47 matches
Mail list logo
