Hi,
we from mundialis, mainly Markus Neteler and me, are thinking about giving
a 90 minute GDAL workshop during the upcoming FOSSGIS conference in
Switzerland. We are not part of the core GDAL team, but confident that we
are able to give such a workshop for a German-speaking audience. Before we
of
On Fri, Feb 5, 2021 at 3:40 PM Karsten Tebling wrote:
>
> Hello,
>
> i'm struggling with how to use the -ct option in ogr2ogr and could need
> some help.
>
> i copied a NTv2.gsb to osgeo4w64/share/proj and edited the proj.db by
> inserting a new row in the grid_transformation-table. using this
> t
Is /usr/local/lib64 known to your system as a path to libraries? Check the
env var LD_LIBRARY_PATH or add "/usr/local/lib64" to some file in
/etc/ld.so.conf.d/ followed by "ldconfig" as root.
You can also set the var LDFLAGS for configure if you have libraries in a
nonstandard directory, such as
L
in EPSG:31468, thus the need for the axis swap.
If you trust the QGIS coordinate operation, then why do you provide a
custom coordinate operation to ogr2ogr with the -ct option?
>
> Am 06.02.2021 um 22:24 schrieb Markus Metz:
>
>
>
> On Fri, Feb 5, 2021 at 3:40 PM Karsten Tebling
+z=418.2 +rx=0.202 +ry=0.045
+rz=-2.455
> +s=6.7 +convention=position_vector
> +step +inv +proj=cart +ellps=GRS80
> +step +proj=pop +v_3
> +step +proj=utm +zone=33 +ellps=GRS80
>
>
> It seems your custom definitions of the coordinate operation are missing
the axi
On Tue, Feb 9, 2021 at 10:54 AM Hernán De Angelis <
variablestarli...@gmail.com> wrote:
>
>
> On 2021-02-09 10:49, Andrew C Aitchison wrote:
> > On Tue, 9 Feb 2021, Hernán De Angelis wrote:
> >
> >> On 2021-02-08 20:22, Markus Metz wrote:
> >>> Is /u
Hi,
for the raster and vector GRASS drivers, can someone please add "@metzm,
@neteler (mundialis)"? Thanks!
Markus M+N
On Fri, Mar 5, 2021 at 7:31 PM Even Rouault
wrote:
> Hi,
>
> following recent discussions about maintenance, I've initiated
>
> https://github.com/OSGeo/gdal/wiki/Maintainers
Hi Even,
IMHO it has been a bit of a luxury that the GDAL GRASS driver was allowed
to exist as a regular GDAL supported format within frmts/grass. With every
new release of GDAL, you (the GDAL maintainers) also released a separate
new GDAL GRASS driver which was really nice of you!
Considering th
There is an important difference between the PROJ4 and the PROJ5+
API/syntax:
The old PROJ4 API uses latlong WGS84 as pivot datum for coordinate
transformations like
projection1 -> latlong WGS84 -> projection2
or in '+to' syntax
projection1 +to projection2
The new PROJ5+ API no longer uses a piv
On Mon, Mar 26, 2018 at 10:51 PM, Kristian Evers wrote:
>
>
> On 26 Mar 2018, at 21:21, Markus Metz
> wrote:
>
> There is an important difference between the PROJ4 and the PROJ5+
> API/syntax:
>
> The old PROJ4 API uses latlong WGS84 as pivot datum for coordi
rom the hub datum to the custom CRS.
It will be a best guess as to how to that transformation but better than
nothing, and probably correct in most cases.
>
> I might have overlooked something, so no promises on the final
implementation yet!
>
>
>
> /Kristian
>
>
>
> Fra:
I observed a segfault in gdalinfo (2.2.3, 2.2.4, 2.3.0dev-71e2ada881) when
compiled against proj-5.0.0/proj-5.0.1
The dataset is a GeoTIFF with EPSG:25832, and I get
Corner Coordinates:
ERROR 1: illegal axis orientation combination
Upper Left ( 375000.000, 5631000.000)
ERROR 1: illegal axis ori
Even,
On Sun, Apr 15, 2018 at 8:17 PM, Even Rouault
wrote:
>
> Markus,
>
> From a quick test generating a GeoTIFF in EPSG:25832, I can't reproduce.
>
> I suspect you may link at runtime against different proj versions.
You are right. I compiled GDAL with
libproj.so -> libproj.so.13.0.1
there is
On Sun, Apr 15, 2018 at 10:07 PM, Even Rouault
wrote:
>
> > OK, I recompiled gdal-2.2.4 --with-static-proj4 and got
> >
> > ldd libgdal.so | grep proj
> > libproj.so.13 => /usr/local/lib64/libproj.so.13 (0x7fe2ff181000)
> > libproj.so.12 => /lib64/libproj.so.12 (0x7fe2f31c7000)
> >
Many raster bands contain nodata, therefore it would be helpful if the
number of non-nodata grid cells could be reported by gdalinfo in some way.
The number of non-nodata grid cells is not available through
GDALGetRasterStatistics() / GDALRasterBand::GetStatistics(), probably
because approximation
On Wed, Jun 13, 2018 at 11:03 PM, Even Rouault
wrote:
>
> On mercredi 13 juin 2018 22:14:07 CEST Markus Metz wrote:
> > Many raster bands contain nodata, therefore it would be helpful if the
> > number of non-nodata grid cells could be reported by gdalinfo in some
way.
> &g
On Thu, Jun 14, 2018 at 10:55 PM, Even Rouault
wrote:
>
> > > Wanna take a crack at implementing this ?
> >
> > Too many API changes required, starting with GDALGetRasterStatistics(),
> > GDALComputeRasterStatistics() and all else following. There must be an
> > easier solution. But thanks for you
On Sat, Jun 16, 2018 at 6:38 PM, jratike80 <
jukka.rahko...@maanmittauslaitos.fi> wrote:
>
> Markus Metz-3 wrote
> > My workaround is to use GRASS r.external to get correct raster band
> > statistics.
>
> Hi,
>
> Wouldn't it be good to have an option in GD
On Fri, Jun 15, 2018 at 10:43 PM, Even Rouault
wrote:
>
> > Thinking about it, I do not want to support approximate statistics,
> > therefore something like STATISTICS_VALID_RATIO does not work for me,
only
> > something like STATISTICS_N_VALID which requires exact statistics.
>
> STATISTICS_VALID
On Sat, Jun 16, 2018 at 10:00 PM, Even Rouault
wrote:
>
> >
> > I checked, results with gdalinfo -stats are wrong because existing
> > STATISTICS_* metadata are reported even if approximate statistics are
not
> > allowed.
>
> No, if STATISTICS_APPROXIMATE=YES and is set in .aux.xml (because initia
On Sun, Jun 17, 2018 at 7:51 PM, Even Rouault
wrote:
>
> > It would be nice if gdalinfo -stats would also trigger forced
recomputation
> > of exact statistics. Currently there is no difference between gdalinfo
with
> > and without -stats if statistics already exist in metadata and
> > STATISTICS_A
On Thu, Apr 5, 2018 at 11:44 AM, Even Rouault
wrote:
>
> Hi,
>
> This is something most people doing GDAL development, and not wanting to
install each time they
> build, have probably reinvented by themselves, so now master has a
scripts/setdevenv.sh that
> you can source to define PATH, LD_LIBRAR
On Thu, Sep 13, 2018 at 4:52 PM Dalia Prizginiene wrote:
>
> Hello,
>
> Is it possible to use gdalwarp together with pipelines "+proj=pipeline
+step +inv +proj=lcc +lat_1=64...
>
> to transform the raster into different datum?
>
>
> In here
http://osgeo-org.1560.x6.nabble.com/gdal-dev-proj-5-su
j=pipeline ..." which is supported in GRASS GIS
7.6 if compiled with PROJ 5.x
Best regards,
Markus M
>
>
>
> Best regards
>
> Dalia
>
>
>
> From: Markus Metz
> Sent: Thursday, September 13, 2018 8:15:41 PM
> To: Dalia Pri
I have a NetCDF file with west > east, gdalinfo reports
Corner Coordinates:
Upper Left ( 335.257, 70.000)
Lower Left ( 335.257, 30.000)
Upper Right ( 44.7424710, 69.970)
Lower Right ( 44.7424710, 29.954)
Center ( 190.000, 50.000)
west = 335.257 > east
On Sat, Nov 24, 2018 at 5:07 PM Even Rouault
wrote:
>
> On samedi 24 novembre 2018 16:27:33 CET Markus Metz wrote:
> > I have a NetCDF file with west > east, gdalinfo reports
> > Corner Coordinates:
> > Upper Left ( 335.257, 70.000)
> > Lower Left (
On Sat, Nov 24, 2018 at 5:56 PM Even Rouault
wrote:
>
> > This particular NetCDF file, PM10 analysis from CAMS
> > http://www.regional.atmosphere.copernicus.eu/, does not have a longitude
> > variable, also no subdatasets. Resolution should be 0.1 degrees, but
GDAL
> > reports
> > Pixel Size = (-0
( 10.000, 50.000)
Markus M
On Sat, Nov 24, 2018 at 6:24 PM Markus Metz
wrote:
>
>
> On Sat, Nov 24, 2018 at 5:56 PM Even Rouault
> wrote:
> >
> > > This particular NetCDF file, PM10 analysis from CAMS
> > > http://www.regional.atmosphere.coperni
On Sun, Nov 25, 2018 at 2:24 AM Even Rouault
wrote:
>
> On samedi 24 novembre 2018 23:09:34 CET Markus Metz wrote:
> > I have created a PR for this, but there are still issues:
> >
> > is
> > Pixel Size = (0.09991285714,-0.1000400)
> > Corner Coordi
On Sun, Nov 25, 2018 at 9:49 PM Even Rouault
wrote:
>
> > About the PR: if the tested nc files are formally legal with their
> > longitude jump at 359.95, 0.04998779, then this could be regarded as a
bug
> > fix, right?
>
> Hard to tell what is legal from what is not sometimes. Anyway the mission
On Thu, Jan 17, 2019 at 7:27 PM Even Rouault
wrote:
>
> On lundi 14 janvier 2019 12:42:08 CET Even Rouault wrote:
> > On mercredi 9 janvier 2019 16:23:44 CET Even Rouault wrote:
> > > Hi,
> > >
> > > RFC 73 "Integration of PROJ6 for WKT2, late binding capabilities,
> > > time-support and unified C
On Tue, Jan 22, 2019 at 10:30 PM Even Rouault
wrote:
>
> Hi Markus,
>
> Thanks for your feedback
>
> > Regarding WKT2, a remark from a GRASS GIS developer being a user of
> > GDAL/PROJ:
> >
> > I understand that WKT2 is long overdue and thus should be pushed as much
> > and as early as possible. O
I have a NetCDF file with
Size is 1800, 3600
Coordinate System is `'
Origin = (89.96946545821,179.96947394237)
Pixel Size = (-0.09996607273,-0.09998304108)
Metadata:
Latitude#long_name=Latitude
Latitude#units=degrees_north
Latitude#_CoordinateAxisType=Lat
Longitude#long_nam
Even,
On Tue, Mar 19, 2019 at 4:53 PM Even Rouault
wrote:
>
> Markus,
>
> yes this file has unconventionnal indexing of variables, with the fastest
> varying dimension being latitude, which confuses the driver
>
> In https://github.com/OSGeo/gdal/pull/1377, I've made a number of changes
that
> ma
On Fri, Apr 5, 2019 at 3:38 PM Markus Neteler wrote:
>
> On Mon, Apr 1, 2019 at 11:17 PM Andrew C Aitchison
> wrote:
> > On Mon, 1 Apr 2019, Markus Neteler wrote:
> > > Now I am stuck at
> > > ...
> > >
> > > BUILD SUCCESSFUL
> > > Total time: 10 seconds
> > > + popd
> > > + %mvn_artifact swig/ja
Extents and spatial filter settings with Geopackage are unprecise such that
they are unusable.
For example I created a Geopackage with a single point: 176418.99585285,
317579.62751027
ogrinfo reports extents of
Extent: (176419.00, 317580.00) - (176419.00, 317580.00)
I think this ca
On Tue, May 21, 2019 at 10:16 PM Even Rouault
wrote:
>
> Makus,
>
> > Extents and spatial filter settings with Geopackage are unprecise such
that
> > they are unusable.
> >
> > For example I created a Geopackage with a single point: 176418.99585285,
> > 317579.62751027
> > ogrinfo reports extents
Hopefully some package maintainers are listening.
A CRS constructed from a proj string (deprecated in GDAL 3 + PROJ 6, I
know), works either in PROJ 6 or in GDAL 2, but not in both. The reason is
that for PROJ 6, "+type=crs" is needed, but unfortunately GDAL 2 does not
recognize this parameter and
On Sun, Nov 3, 2019 at 10:42 PM Even Rouault
wrote:
>
> On dimanche 3 novembre 2019 21:20:56 CET Markus Metz wrote:
> > Hopefully some package maintainers are listening.
> >
> > A CRS constructed from a proj string (deprecated in GDAL 3 + PROJ 6, I
> > know), works
In the GRASS module v.in.ogr we follow pretty much the vector API tutorial.
The only difference is that we first fetch the geometry of a feature, then
the fields. When input is a PG database, sometimes the wrong field entries
are associated with the geometries, as if geometries and field entries we
Even,
On Mon, Dec 2, 2019 at 7:46 PM Even Rouault
wrote:
>
> Markus,
> [...]
>
> Are you sure there's no latent memory corruption in v.in.ogr ? Did you
check
> with Valgrind ?
Yes, I checked with valgrind, no memory corruption. I tried v.in.ogr with
other OGR formats, no problem. I am out of ide
Thanks for your feedback! I think I figured it out. The GRASS module
v.in.ogr goes through the input features twice, but only for polygons. This
is needed to properly convert non-topological polygons to topological areas
in GRASS. The order of features can be different between the first and
second
Regarding this EASE-2 grid (https://nsidc.org/ease/ease-grid-projection-gt),
I found that
On Sat, Feb 1, 2020 at 1:22 PM Even Rouault
wrote:
> - the spacing of the lat variable is not constant
the spacing of the lat variable increases drastically towards the poles.
You could convert the netcdf
43 matches
Mail list logo
