Markus Metz

I see, the problem is the rather old `G_compare_projections()` used by `r.in.gdal`, `r.external`, `v.in.ogr`, `v.external`. There are two possible solutions: * optionally enforce reprojection with a new flag in `r.import`...

Wow: With the new PR #6579 , github pipeline tests will fail if test data have been generated with `nc_basic_spm_grass7` or `nc_spm_08_grass7` which have an EPSG code in `PERMANENT/PROJ_EPSG` because...

The call `"g.proj", epsg=options["epsg"], datum_trans=options["datum_trans"]` comes from the old PROJ4 times when WGS84 was the pivot datum. Nowadways since PROJ 6 this does not make sense any more because WGS84...

In this particular case, there might be a mix of different reasons causing poor performance. The reasons here seem to be NFS + GDAL-linked raster maps + GRASS vrt, which...

> We have the same problem with CleanFaces() and a similar one with CleanVertices() too. indeed > > @metzm I'm not quite sure of the implications if `edges == edges->next`...

The GRASS display does longitude wrapping for geographic projections, so drawing a line from -180, 0 to 180, 0 can create unexpected results because these are the same points on...

This is actually a bug in `v.in.ascii` because negative category values are not allowed. This is not documented in https://grass.osgeo.org/grass84/manuals/vectorintro.html but there is a admittedly hdden hint in the [GRASS...

You could try `projinfo -o PROJ -s {srs_def} -t {srs_def}` on the different systems to check if the exact same projection pipeline is used on the different systems.

The reason why this fails with parallelization is that for each thread, each input raster is opened separately, i.e. each input raster is opened nprocs times, multiplying the number of...

> I am also experiencing this in a workflow on main. This wasn't happening ~ 5 months ago. This happens with 120 large tiles, a group of up to ~3...