Re: [GRASS-dev] Crash in g.proj on Ubuntu

Hi, this is quite typical of a program linking to 2 different version of libproj at the same time, often when mixing repositories, where some components of one haven't been rebuilt against updated components of the other one Check the output of "ldd /path/to/g.proj" Even Le 24/04/2024 à

Re: [GRASS-dev] GRASS Teams on GitHub

FYI I see this thread referencing the GDAL github team organization. As far as I know, nobody has "designed" it with deep thoughts. It has the current structure most likely as an accident of history... If I were to design it, I would keep it simple and stupid. With git workflows, the concept

Re: [GRASS-dev] Proposal for using ClangFormat, replacing GNU indent, for C/C++ code formatting

I'd suggest you use pre-commit so that clang-format is automatically run on git commit operations like we have done with GDAL. Then it is a no-brainer to do changes. You need to add a .pre-commit-config.yaml at the root of the repository (only the part referencing clang-format at

Re: [GRASS-dev] [OSGeo/grass] Pre-release 7.8.8RC3 - GRASS GIS 7.8.8RC3 ---> wrong branch!

Markus, maybe try with the command line: "git push --delete origin 7.8.8RC3" Even Le 16/12/2022 à 22:46, Markus Neteler a écrit : Hi devs, Seems we (I) am not releasing not often enough. Unfortunately I created this tag on "main" rather than "releasebranch_7_8". :-(( Any chance to delete

Re: [GRASS-dev] GitHub backport label proposal

Le 22/11/2022 à 19:51, Nicklas Larsson a écrit : Looks like a clever little bot. In case that is the way the community choose to go then the label will have to be “backport releasebranch_8_2”, which is very long… I also wonder how useful it would be at the moment for GRASS, e.g. wide ranging

Re: [GRASS-dev] GitHub backport label proposal

For the backport bot (https://github.com/OSGeo/gdal/blob/master/.github/workflows/backport.yml) to work, I believe the label must be exactly "backport {git_branch_name}" Le 22/11/2022 à 18:47, Nicklas Larsson via grass-dev a écrit : I think this is a splendid idea! Would be good to keep the

Re: [GRASS-dev] Debugging, parallelism, etc.

Hi, just wanted to point that if you are interested in a "framework" for submit jobs to a thread pool, I can point to https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/thread.h https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/thread.c which is a port in C

Re: [GRASS-dev] [gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?

week. Even Le 28/04/2022 à 22:31, Markus Neteler a écrit : Hi Even, (back to your wish) On Thu, Nov 18, 2021 at 7:12 PM Even Rouault wrote: Hi, (writing to both GDAL and GRASS lists) Working on the transition to CMake as the GDAL build system, the particular status of the GRASS driver in

Re: [GRASS-dev] [gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?

of projects use the GDAL GRASS driver. Feedback from any affected projects would be helpful. Markus M On Thu, Nov 18, 2021 at 7:13 PM Even Rouault wrote: Hi, (writing to both GDAL and GRASS lists) Working on the transition to CMake as the GDAL build system, the particular status

[GRASS-dev] Moving GDAL GRASS driver in a dedicated repository ?

Hi, (writing to both GDAL and GRASS lists) Working on the transition to CMake as the GDAL build system, the particular status of the GRASS driver in GDAL raised my attention. (The following is based on my understanding. It has been ages since I didn't try this...) This driver is a bit odd

Re: [GRASS-dev] GRASS 7.8.5 compile errors

It might be possible that your GDAL build is linking against libgeotiff and/or libspatialite built against libproj.so.15 Le 12/08/2021 à 19:00, Thomas Adams a écrit : Hi Māris, Thank you. I did earlier find that I did have two proj libraries, so I removed libproj.so.15. I also ran sudo

Re: [GRASS-dev] Milestone management: 7.8.5 or 7.10 or 8.0.0?

> > Regarding PROJ, some critical changes are coming for the PROJ 7.2.0 > > release on 1st November (a lot has to do with network/SSL/CA bundle, > > which is important these days), and then another release 7.2.1 is set > > for 1st January, which could work nicely with your planned early 2021 > >

Re: [GRASS-dev] [GRASS-user] GRASS GIS 7.8.1 released with PROJ 6 and GDAL 3 support

On mardi 12 novembre 2019 17:43:56 CET Markus Neteler wrote: > On Tue, Nov 12, 2019 at 5:08 PM Markus Metz > > wrote: > > Regarding GDAL 3 support, we still need to add the new GDAL library > > versions to lib/raster/gdal.c for r.external to work. > Which .so and .dll names need to be registered

Re: [GRASS-dev] PROJ6 support in GRASS

> Indeed messy. Look at the WKT2 representation of projinfo -o WKT2_2018 > EPSG:3857: projection on the ellipsoid "WGS 84", not on a sphere. as does the authority says: https://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::3857 > I don't understand "lying on the ellipsoid definition

Re: [GRASS-dev] PROJ6 support in GRASS

On jeudi 7 novembre 2019 19:50:33 CET Markus Metz wrote: > On Thu, Nov 7, 2019 at 6:47 PM Martin Landa wrote: > > Hi, > > > > čt 7. 11. 2019 v 15:17 odesílatel Markus Metz > > > > napsal: > > > PROJ 6 support is not yet finished in GRASS. Currently it sort of works > > in master and relbr78,

Re: [GRASS-dev] PROJ6 support in GRASS

> The (my) idea is that proj suggests reasonable paths to store grids, search > paths should be available in PJ_INFO. Otherwise applications may decide for > a directory specific to that application, not generally valid for proj used > by different applications. Applications can then check the

Re: [GRASS-dev] PROJ6 support in GRASS

On mercredi 25 septembre 2019 22:47:21 CEST Markus Metz wrote: > Several different methods might be available to reproject from one CRS to > another CRS. PROJ6 can select the most appropriate method if a bounding box > is provided. This means that the selected method depends on the bounding > box

Re: [GRASS-dev] GitHub: how to fwd pull requests to this list?

> > Patches in svn tickets sometimes got old too. When no one cares (or has > time), then it doesn't matter if we use svn or github. I would say PRs on > github are easier to find and track than what we used before, > although seem > harder to test, but that's what we signed up for. Given a

Re: [GRASS-dev] Setting up the Github backport application

On dimanche 26 mai 2019 16:31:04 CEST Markus Neteler wrote: > Hi, > > we activated the backport bot also for GRASS GIS in the Gihub OSGeo > organization. > As far as I understood from Even's email > > https://lists.osgeo.org/pipermail/gdal-dev/2019-March/049928.html > > the system is fairly

Re: [GRASS-dev] git: how to avoid bogus merge commits

On mercredi 22 mai 2019 21:30:58 CEST Markus Metz wrote: > Hi git gurus, > > when I modify my local copy and do git commit + git push, I sometimes get > an error: > "failed to push some refs" > and a hint: > "Updates were rejected because the remote contains work that you do not > have locally.

Re: [GRASS-dev] [GRASS-user] Motion: Migrate SVN and trac tickets to github under OSGeo organization

On lundi 22 avril 2019 17:27:06 CEST Markus Neteler wrote: > On Thu, Apr 18, 2019 at 10:22 PM Markus Neteler wrote: > > PSC members, > > > > RFC6 [1] about the migration from OSGeo SVN and tickets on trac to > > github under the OSGeo organization Hi, Congrats for the decision t move to git !

Re: [GRASS-dev] Fwd: [PROJ] [gdal-dev] github backporting application

On mercredi 20 mars 2019 13:26:40 CET Markus Neteler wrote: > Hi devs, > > See below for cool new stuff. > I guess we also want such a Backport bot... You also need tweaking the travis.yml/appveyor.yml to avoid useless builds to be triggered, to save some carbon emissions and time. The bot

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

> I'm assuming there is no error handler to hook onto, to divert errors to > R's error handler. Actually you can install your own error handler with proj_log_func() Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

On vendredi 8 mars 2019 18:22:42 CET Markus Metz wrote: > On Fri, Mar 8, 2019 at 5:56 PM Even Rouault > > wrote: > > On vendredi 8 mars 2019 17:01:57 CET Markus Metz wrote: > > > My question is, what should GRASS do with a SRS without proj string? The > > >

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

On vendredi 8 mars 2019 17:01:57 CET Markus Metz wrote: > On Fri, Mar 8, 2019 at 12:41 PM Even Rouault > > wrote: > > On vendredi 8 mars 2019 12:27:37 CET Markus Metz wrote: > > > On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand > > wrote: > > > > S

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

On vendredi 8 mars 2019 12:27:37 CET Markus Metz wrote: > On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand wrote: > > Since rgdal::make_EPSG() is facing the same problems of listing tabulated > > EPSG fields as g.proj -l, I was very happy to see Markus' code in > > g.proj/main.c mentioned in this

Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5

On lundi 25 février 2019 15:10:10 CET Markus Metz wrote: > Hi all, > > GRASS needs some adjustments in order to be compatible with PROJ 6 + GDAL > 2.5 > > The plain text file "share/proj/epsg" no longer exists. This file is > currently required by the GUI location wizard to retrieve a list of

Re: [GRASS-dev] Fwd: [PROJ] PROJ 6RC2

On samedi 23 février 2019 15:59:28 CET Markus Neteler wrote: > Hi devs, > > there is some discussion about packages that need to be patched to use > proj_api.h or proj.h which will no longer be available in recent PROJ. > > Is there anything to do in GRASS GIS (trunk)? From what I can see in

Re: [GRASS-dev] GSoC 2019 Idea: Continuous Fuzzing for GRASS GIS to uncover software bugs

Note that OSS-Fuzz only supports C/C++ libs. Not Python Fuzzed binaries must statically link all their dependencies: https://github.com/google/oss-fuzz/blob/master/docs/fuzzer_environment.md Even > Hi, > > here an idea for https://trac.osgeo.org/grass/wiki/GSoC/2019 > > Since I am not the

Re: [GRASS-dev] GRASS GIS and OSS-FUZZ: automated bug hunting

On mercredi 23 mai 2018 09:21:21 CEST Markus Neteler wrote: > Hi devs, > > perhaps it would be worthwhile to submit GRASS GIS to Google's > OSS-FUZZ [1] like GDAL (of course we don't know it we would be > accepted). > > To get it done, we may learn from GDAL: > * related GDAL ticket:

Re: [GRASS-dev] problem with reading KML

On lundi 5 février 2018 10:04:25 CET Anna Petrášová wrote: > Hi, > > I ran into a weird problem with KML with 3D line, v.import failed when > reprojecting it: > > WARNING: pj_transform() failed: latitude or longitude exceeded limits > > This happened with GRASS 7.4.0 64bit (GDAL 2.2.3) on

[GRASS-dev] EPSG v9.2 upgrade

Hi, I've updated to the EPSG v9.2 database. The relevant tickets/commits are: * libgeotiff: https://trac.osgeo.org/geotiff/changeset/2802 * GDAL: https://trac.osgeo.org/gdal/ticket/7125 * proj.4: https://github.com/OSGeo/proj.4/issues/711 * postgis: https://trac.osgeo.org/postgis/ticket/3944

Re: [GRASS-dev] winGRASS not built/broken

On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote: > On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault <even.roua...@spatialys.com> > > wrote: > > > --> > > > > > > Index: port/cpl_port.h > > > > > > ==

Re: [GRASS-dev] winGRASS not built/broken

> --> > Index: port/cpl_port.h > === > --- port/cpl_port.h(revision 40701) > +++ port/cpl_port.h(working copy) > @@ -219,7 +219,7 @@ > /* 64bit support */ > /*

Re: [GRASS-dev] winGRASS not built/broken

On dimanche 12 novembre 2017 00:07:49 CET Markus Metz wrote: > Stupid question: such a #define has only effect on compile time. If GDAL > has been compiled without HAVE_LONG_LONG being defined, and then we define > HAVE_LONG_LONG when compiling against GDAL, is this creating a big mess? With

Re: [GRASS-dev] winGRASS not built/broken

> If GDALSetCacheMax64 must evaluate to GDALSetCacheMax64 ( int ), My hypothesis might be wrong, but if it is true, then it *wrongly* evaluates to GDALSetCacheMax64 ( int ) when currently called by GRASS. If you define HAVE_LONG_LONG before including cpl_port.h or any other GDAL include files,

Re: [GRASS-dev] winGRASS not built/broken

On samedi 11 novembre 2017 17:44:18 CET Markus Metz wrote: > On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky wrote: > > it seems there is an issue with winGRASS: > > > > 32 bit: > > > > https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log > > > > GRASS GIS

Re: [GRASS-dev] GRASS GIS raster files: LZW compression?

On jeudi 26 octobre 2017 18:57:10 CEST Markus Neteler wrote: > On Thu, Oct 26, 2017 at 9:25 AM, Markus Metz > > wrote: > > On Wed, Oct 25, 2017 at 10:40 PM, Markus Neteler wrote: > >> Hi devs, > >> > >> while playing with the SRTM 30m world I

Re: [GRASS-dev] prefer GeoPackage over Shapefile

On mercredi 18 octobre 2017 12:28:36 CEST Jachym Cepicky wrote: > Hi, > > I would like to submit following commit to GRASS GIS - master > > Index: vector/v.out.ogr/args.c > === > --- vector/v.out.ogr/args.c (revision 71566) > +++

Re: [GRASS-dev] Cloud optimized GeoTIFF support

On dimanche 15 octobre 2017 21:28:24 CEST Markus Neteler wrote: > On Sun, Oct 15, 2017 at 7:47 PM, Markus Metz > > wrote: > > What do you mean with "a more direct GRASS GIS integration" regarding > > cloud > > storage and/or Cloud Optimized GeoTIFF? > > Well, I

Re: [GRASS-dev] v.in.osm working?

On jeudi 24 août 2017 15:34:11 CEST Markus Metz wrote: > On Thu, Aug 24, 2017 at 11:15 AM, Even Rouault <even.roua...@spatialys.com> > > wrote: > > > You can use v.in.ogr directly for OSM PBF files ( > > > > > > http://gdal.org/drv_osm.html). >

Re: [GRASS-dev] v.in.osm working?

> You can use v.in.ogr directly for OSM PBF files ( > http://gdal.org/drv_osm.html). > > BTW, with GDAL 2.2.1, using OGR_INTERLEAVED_READING=YES does not work for > me (empty vector). Caution: you cannot just specify OGR_INTERLEAVED_READING=YES and loop over layers as usual. See the

[GRASS-dev] EPSG v9.0 upgrade

/geotiff/ changeset/2747 and https://trac.osgeo.org/gdal/changeset/37080 Even (*) From libgeotiff ChangeLog: 2017-01-10 Even Rouault * csv/datum_shift_pref.csv: add overrides for PCS 2065 (S-JTSK (Ferro) / Krovak) Fixes https://trac.osgeo.org/gdal/ticket/4762 and https

Re: [GRASS-dev] r.out.gdal and Rasterlite driver

Le mardi 25 octobre 2016 12:02:01, Vincent Bain a écrit : > Hi Maciek, > > thanks for your suggestion. In fact, the script runs without error or > warning but it does not change anything : > > gdalinfo Rasterlite:my_db.sqlite,table=my_raster > [...] >

Re: [GRASS-dev] geocoding module

Le mardi 18 octobre 2016 16:42:25, Markus Neteler a écrit : > On Tue, Oct 18, 2016 at 2:54 PM, Luca Delucchi wrote: > > Hi devs, > > > > do you know if a geocoding module for GRASS already exists ? > > Hi Luca, > > a tool using an address database such as OSM nominatim? >

Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory

Le lundi 25 avril 2016 22:02:20, Paul Kelly a écrit : > Hi Markus, Even, > > On 04/24/2016 10:29 PM, Markus Neteler wrote: > > Hi Paul, > > > > you are probably the person with most insights into lib/proj/convert.c. > > > > I try to debug why the North Carolina Location cannot be generated > >

Re: [GRASS-dev] Error: undefined reference to `OGR_GT_Flatten' when compiling grass with GDAL

> -L/misc/fluo6/andre/projekte/custom_gfz_python/tmp/grass/grass-7.0.2/dist.x > 86_64-unknown-linux-gnu/lib > -L/misc/fluo6/andre/projekte/custom_gfz_python/tmp/grass/grass-7.0.2/dist. > x86_64-unknown-linux-gnu/lib -Wl,--export-dynamic >

[GRASS-dev] Fwd: [MetaCRS] Common SQLite-based dictionaries

Forwarding to a few lists that might be interested in the below proposal as metacrs is perhaps not widely followed. But please keep the discussion to metacrs to avoid cross postings. -- Forwarded Message -- Subject: [MetaCRS] Common SQLite-based dictionaries Date: Sunday 02

Re: [GRASS-dev] Re: [gdal-dev] gdaldem hillshade directions / GRASS r.shaded.relief

Hamish, I've taken some time to experiment a bit with GRASS and GRASS behaviour is correct of course, so sorry for the noise. I've finally identified why gdaldem (and initially Matt's hillshade utility) got it wrong. GRASS r.mapcalc atan(x,y) function has its parameters reversed in comparison

[GRASS-dev] Re: [gdal-dev] gdaldem hillshade directions / GRASS r.shaded.relief

Vincent, I'm CC'ing the grass-dev list as gdaldem shares the same formula with the GRASS r.shaded.relief utility and I also think they are affected (I've only compared the code, not tested r.shaded.relief, so I could be wrong of course) I think your analysis is right. To check, I've created an