I ran into the same problem a while back.
My solution was to change the AxisMapStrategy to OAMS_TRADITION_GIS_ORDER.
You can read more about this here:
https://gdal.org/tutorials/osr_api_tut.html
My code in C#:
var source = new SpatialReference("");
var destination = new
+1
On Tue, Jan 28, 2020 at 2:19 PM Howard Butler wrote:
> +1
>
> Howard
>
> > On Jan 28, 2020, at 8:52 AM, Daniel Morissette
> wrote:
> >
> > +1
> >
> > Daniel
> >
> >
> > On 2020-01-28 05:48, Even Rouault wrote:
> >> Hi,
> >> The bug raised yesterday regarding the odd formulation of EPSG:3857
+1
Howard
> On Jan 28, 2020, at 8:52 AM, Daniel Morissette
> wrote:
>
> +1
>
> Daniel
>
>
> On 2020-01-28 05:48, Even Rouault wrote:
>> Hi,
>> The bug raised yesterday regarding the odd formulation of EPSG:3857 exported
>> GeoTIFF files is quite annoying regarding interoperability, and we'
Nicolas,
> It's easy to go from coordinate space to pixel space in python using
> something like.
>
> pixel_x = int(-124114.3 - geo_transform[0])/geo_transform[1])
>
> What is the trick when there is an image rotation?
Compute the inverse geotransform with
https://gdal.org/api/raster_c_api
Hi,
It's easy to go from coordinate space to pixel space in python using
something like.
pixel_x = int(-124114.3 - geo_transform[0])/geo_transform[1])
What is the trick when there is an image rotation? Also, as a second
very beginner question, what is the difference between geo_transfor
> What might I need to do to get it working correctly? I know there was a lot
> of changes with gdalbarn/proj.
Indeed. See
https://lists.osgeo.org/pipermail/gdal-dev/2020-January/051425.html
--
Spatialys - Geospatial professional services
http://www.spatialys.com
So, I'm finding a difference between results
def epsg_test():
import ogr
import osr
wgs84_osr = osr.SpatialReference()
wgs84_osr.ImportFromEPSG(4326)
utm17_osr = osr.SpatialReference()
utm17_osr.ImportFromEPSG(32617)
transform = osr.CoordinateTransformation(
+1
Daniel
On 2020-01-28 05:48, Even Rouault wrote:
Hi,
The bug raised yesterday regarding the odd formulation of EPSG:3857 exported
GeoTIFF files is quite annoying regarding interoperability, and we'd
better stop generation of such odd files ASAP. Hence this release without
prior notice.
Bot
+1
-Jukka-
Even Rouault-2 wrote
> Hi,
>
> The bug raised yesterday regarding the odd formulation of EPSG:3857
> exported
> GeoTIFF files is quite annoying regarding interoperability, and we'd
> better stop generation of such odd files ASAP. Hence this release without
> prior notice.
>
> Both
>> Should be -of MEM. That's tested in autotest/utilities/test_gdal_grid_lib.py
> An alternative is to use a /vsimem/temp.tif with the GTiff driver (but you
> need to VSIUnlink() > the file once done to avoid mem leaks). But the MEM
> driver should do it.
Cool, with -of MEM and still using "N
> Do you see a chance to push
> https://github.com/OSGeo/gdal/commit/66ea9bfa6e0e4ba27b0ae8ce7c75f3d5ad11da6
> 3
>
> also to the 2.x branch?
Probably not. This is a new feature, so the general rule is master only. And
I'm not even sure we'll release a new 2.4 point release. Personnaly, I don't
Hi Even,
On Tue, Jan 28, 2020 at 12:33 PM Even Rouault
wrote:
> I've just added in GDAL master support for extracting the GCPs from the ESRI
> GeodataXform object of .aux.xml files
>
> $ gdalinfo txu-pclmaps-oclc-6540922-tunis-20.jpg
> [...]
> GCP Projection =
> PROJCRS["NW Africa Grid",
> [
Joaquim,
> -Note that I'm using "NUL" for the output file name because that was the
> only way I found to prevent saving the file in disk (remember, I want to
> have it memory).
That's bound to fail. NUL or /dev/null are files that can't be re-read, and as
you call GDALRasterIO(), you do intend
Hi Even,
I'm playing with the C API for the GDAL programs inside GMT. More specifically
with the gdal_grid C API. All in all I managed to make it work but there are
some issues.
The main problem is that apparently the API was not thought to keep the result
in memory.
What ended up doing was th
Hi Evan,
That change in 2.4.0 looks like it's the answer. Looking at the returned data
in detail, there is indeed a column of pixels which is duplicated (sampled
twice) with the option set, and is replaced by an extra column on the right
hand side without it set.
Thanks!
Daniel
-Original
On mardi 28 janvier 2020 11:49:01 CET Daniel Evans wrote:
> Hi all,
>
> I've recently tried enabling the GDAL_FORCE_CACHING option, and found it
> gives some significant improvements to TIFF/VRT read speeds.
>
> However, using GDAL 2.3.0, I've now found that when reading large VRTs, I
> can somet
Hi all,
I've recently tried enabling the GDAL_FORCE_CACHING option, and found it gives
some significant improvements to TIFF/VRT read speeds.
However, using GDAL 2.3.0, I've now found that when reading large VRTs, I can
sometimes get subtly different values - up to about 1% summed difference ac
Markus,
> Sorry for the misunderstanding: I used to GRASS GIS' g.gui.gcp to
> generate GPCs from scratch, interactively.
Makes more sense :-)
I've just added in GDAL master support for extracting the GCPs from the ESRI
GeodataXform object of .aux.xml files
$ gdalinfo txu-pclmaps-oclc-6540922-t
+1
Good idea, thank you!
Mateusz
On Tue, 28 Jan 2020 at 11:48, Even Rouault wrote:
>
> Hi,
>
> The bug raised yesterday regarding the odd formulation of EPSG:3857 exported
> GeoTIFF files is quite annoying regarding interoperability, and we'd
> better stop generation of such odd files ASAP. Henc
Hi,
The bug raised yesterday regarding the odd formulation of EPSG:3857 exported
GeoTIFF files is quite annoying regarding interoperability, and we'd
better stop generation of such odd files ASAP. Hence this release without
prior notice.
Both announcement of availability of release candidate an
and always remember as stated in the doc-link: "Disks are the slowest
part of the process."
As fast I/O and file system as technically possible ... e.g. do not use
your laptop
Hi,
You can read considerations about memory from
https://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#WillincreasingR
21 matches
Mail list logo
