Re: [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-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-user] cannot write raster w/ max = inf

> inf is a perfectly valid number, meaning infinity. Unfortunately, a test > for inf is only available with C standard 99, and I don't know of a manual > test in C for inf (or -inf) to avoid C 99. The bug is in r.out.gdal, not > testing for input inf values. You could use the CPLIsInf() macro

Re: [GRASS-user] Unusual [Open|ESRI]FileGDB: how to import

On lundi 30 octobre 2017 22:28:27 CET Markus Metz wrote: > On Mon, Oct 30, 2017 at 10:16 PM, Rich Shepard > > wrote: > > On Mon, 30 Oct 2017, Rich Shepard wrote: > >> The projection information I see looks acceptable to grass: > >> > >> > >> Why is WGS_1984 not

Re: [GRASS-user] Unusual [Open|ESRI]FileGDB: how to import

On jeudi 26 octobre 2017 13:52:21 CEST Rich Shepard wrote: >I am trying to import/open data files from www.streamnet.org but their > GDB format is quite different from what I've seen before now and > grass-7.3.svn will not open them. As an aside, I was thrown for a while > looking for

Re: [GRASS-user] OpenFileGDB input error

> I tested with v.in.ogr, and OGR_G_GetLinearGeometry() does not convert > these beasts into a linear geometry. Yes that's why I mentionned it. Strictly speaking those geometries are linear (ie they don't have curves) > > Testing around a bit, the difference between OGR_G_GetLinearGeometry()

Re: [GRASS-user] OpenFileGDB input error

On jeudi 28 septembre 2017 22:34:55 CEST Even Rouault wrote: > > By now, v.in.ogr is peppered with #if GDAL_VERSION_NUM >= X, looks like at > > some stage we should have two versions, one for GDAL 1.x, another one for > > GDAL 2.x... > > Seems to me that having 2 versi

Re: [GRASS-user] OpenFileGDB input error

> By now, v.in.ogr is peppered with #if GDAL_VERSION_NUM >= X, looks like at > some stage we should have two versions, one for GDAL 1.x, another one for > GDAL 2.x... Seems to me that having 2 version of th code would be more difficult to maintain. To avoid cluttering the code with condition

Re: [GRASS-user] OpenFileGDB input error

> As of trunk r71513, v.in.ogr converts any curve types to linear equivalents > with OGR_G_GetLinearGeometry(). r71513 is going to leak memory. The return of OGR_G_GetLinearGeometry() must be freed with OGR_G_DestroyGeometry() (be careful to call it only on a Ogr_geometry returned by

Re: [GRASS-user] OpenFileGDB input error

> > You can force a curve geometry to its linearized version (curves are > > approximated with segments) with: > > hGeom = OGR_G_ForceTo(hGeom, > > OGR_GT_GetLinear(OGR_G_GetGeometryType(hGeom))) > > Thanks for the hint! > > I'm looking for a way to support non-linear geometries in v.in.ogr.

Re: [GRASS-user] OpenFileGDB input error

On lundi 25 septembre 2017 22:24:21 CEST Markus Metz wrote: > On Mon, Sep 25, 2017 at 8:23 PM, Even Rouault <even.roua...@spatialys.com> > > wrote: > > On lundi 25 septembre 2017 11:04:35 CEST Rich Shepard wrote: > > > On Mon, 25 Sep 2017, Markus Metz wrote

Re: [GRASS-user] OpenFileGDB input error

On lundi 25 septembre 2017 11:04:35 CEST Rich Shepard wrote: > On Mon, 25 Sep 2017, Markus Metz wrote: > > these multi-surfaces are in the layer with multi-polygons. OGR calls these > > geometries multi-surfaces. Investigating a bit more, I found > > curve-polygons within these multi-surfaces.

Re: [GRASS-user] OpenFileGDB input error

On lundi 25 septembre 2017 19:19:26 CEST Markus Metz wrote: > On Mon, Sep 25, 2017 at 6:07 PM, Rich Shepard > > wrote: > > On Mon, 25 Sep 2017, Markus Metz wrote: > >> A multi-surface has sneaked into the layer with multi-polygons, that's > >> causing the error in

Re: [GRASS-user] Change SQLite DB Column Width?

On vendredi 4 août 2017 16:22:57 CEST Jeshua Lacock wrote: > > On Aug 4, 2017, at 2:03 AM, Even Rouault <even.roua...@spatialys.com> > > wrote: > > > > As column width is just a hint in SQLite and has no influence on the > > database structure (you ca

Re: [GRASS-user] Change SQLite DB Column Width?

On jeudi 3 août 2017 17:19:56 CEST Jeshua Lacock wrote: > Greetings, > > I am attempting to patch vectors together with v.patch -e (I need the > attributes). But I am getting this error: > > ERROR: Length of string columns differ > > Upon inspecting the columns, I see that at least one vector

Re: [GRASS-user] importing Mars DEM takes too long

On dimanche 20 novembre 2016 17:38:19 CET Anna Petrášová wrote: > On Sun, Nov 20, 2016 at 5:02 PM, Helmut Kudrnovsky wrote: > >>11 seconds can be pretty long depending on the size of the file. Try > >>to convert it to tif and load again, it will be probably much faster. > >> > >

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

Le jeudi 15 septembre 2016 20:22:01, Rich Shepard a écrit : > On Thu, 15 Sep 2016, Even Rouault wrote: > > What do you exactly mean by "fail" ? Does it report something like > > > > FAILURE: > > Unable to open datasource `foo.gdb' with the following driver

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

>I just tried to import a different transportation map in OpenFileGDB > without success. The location is the same as the previous map so I let > grass create a new mapset, moved the source files there, restarted grass, > and was told there was no layers selected. That's because none were >

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

Le mercredi 14 septembre 2016 23:47:57, Rich Shepard a écrit : > On Wed, 14 Sep 2016, Helmut Kudrnovsky wrote: > > "." is this really your directory which holds the filegdb data? > > Helmut, > >Bash recognizes this as cwd (current working directory). However, ... I've just added support in

Re: [GRASS-user] Importing data in .atx/.gdb format

Le mercredi 14 septembre 2016 23:56:40, Helmut Kudrnovsky a écrit : > >PROJCS["NAD83 / Oregon Lambert (ft)", > > > >GEOGCS["NAD83", > > > >DATUM["North_American_Datum_1983", > > > > SPHEROID["GRS 1980", > > you have to find the correct EPSG code related to

[GRASS-user] Color harmonization

Hi all, I've skimmed through the algorithms listed in GRASS documentation but couldn't find what I'm looking for : is there an algorithm to do color harmonization between images that share overlapping areas ? Thanks, Even -- Geospatial professional services