Re: [GRASS-user] Start in text mode: define new location with proj.4 string

On Wed, Jul 11, 2018 at 2:44 PM, Rich Shepard wrote: > > On Wed, 11 Jul 2018, Nikos Alexandris wrote: > >> The grass --help does not mention support for "Proj" strings. Only >> geo(-referenced)file and EPSG. > > > Nikos, > > Yep. That's why I asked. So, on the infrequent occasions when source

Re: [GRASS-user] limit number of confluent streams in r.steam.extract or r.watershed

On Wed, Jul 11, 2018 at 3:55 AM, Huidae Cho wrote: > > Hello, > > Not sure if I understood your question. Are you trying to extract major streams only? r.stream.extract already returns a valid stream network with confluences snapped to the main stem. Also, limiting the number of confluent streams

Re: [GRASS-user] Setting region to add map to location

On Mon, Jul 9, 2018 at 6:11 PM, Rich Shepard wrote: > > On Mon, 9 Jul 2018, Markus Metz wrote: > >> The source's region does not matter, what matters are the extents of the >> source raster map. > > > Markus, > > I should have remembered that they're differe

Re: [GRASS-user] Setting region to add map to location

On Sun, Jul 8, 2018 at 1:41 AM, Rich Shepard wrote: > > On Sun, 8 Jul 2018, Markus Neteler wrote: > >> r.patch does exactly that, no flags needed. > > > Markus, > > A related issue: when I want to reproject raster DEMs from their source > location to a common target location r.proj fails

Re: [GRASS-user] question on i.nightlights.intercalibration code

extent is exceeded by 1 cells > 360 degree EW extent is exceeded by 1 cells > r.region complete. > > > On Wed, Jun 27, 2018 at 4:55 AM, Nikos Alexandris wrote: >> >> * Markus Metz [2018-06-26 14:40:25 +0200]: >> >> >>> O

Re: [GRASS-user] Finding EPSG code based on prj.adf; importing with v.in.gdal

On Thu, Jul 5, 2018 at 12:44 AM, Rich Shepard wrote: > > The ESRI GRID formatted LiDAR raw data file can be imported using > r.in.gdal using the appropriately defined location. Running 'gdalinfo > | less' on the prj.adf file reports: > > Coordinate System is: > PROJCS["unnamed", >

Re: [GRASS-user] Semi-automatic classification with GRASS modules

On Wed, Jul 4, 2018 at 11:36 AM, Giuseppe Cillis wrote: > > Hello everyone, > I'm applying between QGIS and GRASS to apply a semi-automatic classification of aerial photos. > In practice I would like to use the combination of the grass modules in the processing of QGIS; i.cluster and i.maxlink.

Re: [GRASS-user] Switching databases for holding attributes in Grass 7.4.1

On Tue, Jul 3, 2018 at 8:09 AM, Moritz Lennert wrote: > > > > Am 2. Juli 2018 21:06:15 MESZ schrieb Markus Metz < markus.metz.gisw...@gmail.com>: > >On Mon, Jul 2, 2018 at 4:54 PM, Moritz Lennert > > > >wrote: > >> > >> Le Mon

Re: [GRASS-user] 7.5svn: issue with finding EPSG codes for new locations

On Tue, Jul 3, 2018 at 12:04 AM, Markus Neteler wrote: > > On Thu, Jun 28, 2018 at 9:24 PM, Solano Barajas Ramon wrote: > > I was struggling with the same problem since some time ago. I’m using a Mac with MacPorts so currently I have GRASS 7.4.0 installed, but the problem dates from before. > >

Re: [GRASS-user] Switching databases for holding attributes in Grass 7.4.1

On Mon, Jul 2, 2018 at 4:54 PM, Moritz Lennert wrote: > > Le Mon, 2 Jul 2018 16:36:30 +0200, > Markus Metz a écrit : > > > On Mon, Jul 2, 2018 at 4:04 PM, Paul Shapley > > wrote: > > > > > > Hi Markus, > > > > > > Used 'db.connect'

Re: [GRASS-user] Switching databases for holding attributes in Grass 7.4.1

On Mon, Jul 2, 2018 at 4:36 PM, Markus Metz wrote: > > > > On Mon, Jul 2, 2018 at 4:04 PM, Paul Shapley wrote: > > > > Hi Markus, > > > > Used 'db.connect' driver=sqlite database=$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db > > > > I had to

Re: [GRASS-user] Switching databases for holding attributes in Grass 7.4.1

AME/$MAPSET/sqlite/sqlite.db > > I had to delete 'database schema=grass_gis' > > I had to delete 'default group=postgis_reader' > > Then 'RUN' > > > > On 2 July 2018 at 14:41, Markus Metz wrote: >> >> >> >> On Mon, Jul 2, 2018 at 3:25 PM, Paul Shapley

Re: [GRASS-user] Switching databases for holding attributes in Grass 7.4.1

nnection settings, e.g. I get in the North Carolina sample dataset > db.connect -g driver=sqlite database=$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db schema= group= The database is not a real path but contains GRASS variables that are evaluated on the fly. This is the default c

Re: [GRASS-user] Switching databases for holding attributes in Grass 7.4.1

On Mon, Jul 2, 2018 at 2:00 PM, Paul Shapley wrote: > > Hi Users, > > I want to use 'r.to.vect' but it seems to default to a 'Postgis' table that has no geometry column just a table with a 'cat' id. I would like to export to 'sqlite'. I have both postgres an sqlite login details stored in

Re: [GRASS-user] v.clean: recommend tools and sequence

On Fri, Jun 29, 2018 at 5:49 PM, Rich Shepard wrote: > > On Wed, 27 Jun 2018, Markus Neteler wrote: > >> You may want to take a look here: >> https://grasswiki.osgeo.org/wiki/Vector_topology_cleaning > > > Markus, > > After repeating v.in.ogr with larger snap thresholds until it told me it >

Re: [GRASS-user] v.in.ogr: too many overlaps

On Mon, Jun 25, 2018 at 8:26 PM, Rich Shepard wrote: > > While importing a polygon file grass7.5svn balked: > > "23125 areas represent multiple (overlapping) features, because polygons > overlap in input layer(s). Such areas are linked to more than 1 row in > attribute table. The number of

Re: [GRASS-user] v.out.postgis

gt; > > It looks like it is trying to read the input attrubute table from postgresql (schema grass_gis). Do you use PostgreSQL as attribute table backend ? Could you provide the output of db.connect -p in that mapset ? ore precise would be v.db.connect -p APGB_aerial_2_i_segment_dra

Re: [GRASS-user] v.clean: recommend tools and sequence

On Wed, Jun 27, 2018 at 8:59 PM, Rich Shepard wrote: > > On Wed, 27 Jun 2018, Markus Neteler wrote: > >> You may want to take a look here: >> https://grasswiki.osgeo.org/wiki/Vector_topology_cleaning > > >> Normally the module gives you a suggestion. > > > Markus, > > Thanks for the URL. The

Re: [GRASS-user] question on i.nightlights.intercalibration code

On Tue, Jun 26, 2018 at 9:53 AM, Nikos Alexandris wrote: > > * Markus Metz [2018-06-25 08:29:45 +0200]: > > [..] > >> The resolution is a bit wrong, it is 0.0083330 but should be >> 0.008, i.e. exactly 30 arc-seconds. This can be solved with

Re: [GRASS-user] question on i.nightlights.intercalibration code

gards, > > Gabriel > > > > > On Mon, Jun 25, 2018 at 3:29 AM, Markus Metz < markus.metz.gisw...@gmail.com> wrote: >> >> >> >> On Mon, Jun 25, 2018 at 5:40 AM, Gabriel Cotlier wrote: >> > >> > Hello, >> > >> > I thi

Re: [GRASS-user] question on i.nightlights.intercalibration code

NING: As requested, timestamp transferring not attempted. >> WARNING: No data base element files found >> >> (Sun Jun 24 17:05:31 2018) Command finished (1 min 2 sec) >> >> What could be doing wrong? >> In addition I'm doing it for one layer here, is there a way t

Re: [GRASS-user] installing 7.4.1 on Centos7

On Sat, Jun 23, 2018 at 7:31 PM, Markus Neteler wrote: > > Dear Laura, > > On Sat, Jun 23, 2018 at 6:14 PM, Laura Poggio wrote: > > Dear Markus, > > the packages with wxpython in the name are (centos 7.5.1804): > > wxPython-devel.x86_64 > > wxPython-docs.x86_64 > > wxPython.x86_64 > > > > yum

Re: [GRASS-user] question on i.nightlights.intercalibration code

On Sat, Jun 23, 2018 at 11:10 AM, Veronica Andreo wrote: > > Hi, > > El sáb., 23 jun. 2018 4:35, Markus Metz escribió: >> >> >> >> On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo wrote: >> > >> > Hi Gabriel, >> > >> >

Re: [GRASS-user] question on i.nightlights.intercalibration code

On Fri, Jun 22, 2018 at 10:34 PM, Veronica Andreo wrote: > > Hi Gabriel, > > What you could do is import with r.in.gdal -a that adjusts resolution for lat long maps [0] that will help to fix the resolution from 0.0083330 to 0.008, i.e. exactly 30 arc-seconds. The software

Re: [GRASS-user] Spatial data exchange formats

it should be. So this makes me believe that we are looking at just one > corner of the data, where it happens to have a lot of NODATA cells. > > Cheers > Daniel > > > On Thu, Jun 21, 2018 at 3:17 PM Markus Metz > wrote: > >> >> >> On Thu, Jun 21, 2018 at

Re: [GRASS-user] Spatial data exchange formats

On Thu, Jun 21, 2018 at 7:24 PM, Rich Shepard wrote: > > My problems are that pointing r.in.gdal to the hdr.adf files display only > the strange wedge/rectangle I attached to messages earlier in this thread. > They should be retangles for a full 1 degree x 1 degree topographic quad map > with

Re: [GRASS-user] G_malloc errors in i.segment

than the 300mb? The memory option of r.in.gdal applies to the input image, not the output image. Sometimes more memory can help, sometimes it does not have any effect. However, it does not affect subsequent processing steps. Markus M > > Thanks again Markus...I appreciate your help. > > P

Re: [GRASS-user] G_malloc errors in i.segment

On Wed, Jun 20, 2018 at 1:30 PM, Paul Shapley wrote: > > Hi Users, > > Apologies if i'm posting this error again but i need to get pass the memory allocation issue of trying to allocate 3gb memory. The Grass version is (using file r.contour). Processor has 32 gb ram and i've allocated 3 mb

Re: [GRASS-user] i.segment

On Mon, Jun 18, 2018 at 4:16 PM, Paul Shapley wrote: > > Hi Users, > > I am getting an error when i run i.segment on a small subset of an image:- > > 'ERROR: Insufficient number of non-NULL cells in current region' Either the subset is too small (only one cell) or the current region does not

Re: [GRASS-user] Problem importing ESRI grid file (.adf)

On Fri, Jun 8, 2018 at 9:48 PM, Rich Shepard wrote: > > I have several LiDAR files from a state agency I want to import into > grass75. For one file I've used this command: > > r.in.gdal -o --overwrite input=Bare_Earth/bh45122c3/w001001.adf output=bare_earth > > and get the output in the

Re: [GRASS-user] g.proj fails on winGRASS trunk with AIG/Arc/Info Binary Grid input

On Wed, Jun 13, 2018 at 10:25 PM, Helmut Kudrnovsky wrote: > > >as of r72802, it should be possible to create a location from the data, and > the projection check should work. > > confirmed, it works now also in winGRASS trunk. Great, thanks a lot for testing on winGRASS! Markus M > > > > -

Re: [GRASS-user] g.proj fails on winGRASS trunk with AIG/Arc/Info Binary Grid input

On Tue, Jun 12, 2018 at 4:07 PM, Rich Shepard wrote: > > On Tue, 12 Jun 2018, Markus Metz wrote: > >> Gotcha! Valgrind gave me a hint, hopefully fixed in trunk r72802. > > > Markus M, > > Here, running 7.5svn r72804 there's no change with my data set. as of

Re: [GRASS-user] g.proj fails on winGRASS trunk with AIG/Arc/Info Binary Grid input

On Mon, Jun 11, 2018 at 11:01 PM, Helmut Kudrnovsky wrote: > > >No information: can you please try this on the true CLI? > > C:\>g.proj -p georef=D:\temp\rich\Bare_Earth\bh45122c3 > D1/3: G_set_program_name(): g.proj > D1/3: Trying to open with OGR... > D1/3: Trying to open with GDAL... > D1/3:

Re: [GRASS-user] rshep...@appl-ecosys.com sent you a file

On Mon, Jun 11, 2018 at 9:50 PM, Rich Shepard wrote: > > On Mon, 11 Jun 2018, Markus Metz wrote: > >> But you succeeded with importing the data with r.in.gdal. They are not >> what you expected, though. As Helmut suggested, > > > Markus, > > Well, not correc

Re: [GRASS-user] rshep...@appl-ecosys.com sent you a file

On Mon, Jun 11, 2018 at 3:41 PM, Rich Shepard wrote: > > On Mon, 11 Jun 2018, Helmut Kudrnovsky wrote: > >> what I can observe here with > > > ... > >> no SRS information is reckognized at, new location can't be build. and I >> can't import the raster data by r.in.gdal. >> >> whereas both above

[GRASS-user] g.proj fails on winGRASS trunk with AIG/Arc/Info Binary Grid input

[ creating a new thread because this is a different issue ] On Mon, Jun 11, 2018 at 7:47 PM, Helmut Kudrnovsky wrote: > > >strange, works for me on Linux. > > > >can you provide the winGRASS 7.5 output of > >g.proj georef=D:\temp\rich\Bare_Earth\bh45122c3\hdr.adf -p > >and > >g.proj

Re: [GRASS-user] rshep...@appl-ecosys.com sent you a file

On Mon, Jun 11, 2018 at 3:05 PM, Helmut Kudrnovsky wrote: > > >I can not confirm, because ... > [...] > > identical, only that trunk is able to resolve the name of the unit > > what I can observe here with > > GRASS version: 7.5.svn > GRASS SVN revision: r72772 > Build date: 2018-06-06 > Build

Re: [GRASS-user] rshep...@appl-ecosys.com sent you a file

On Mon, Jun 11, 2018 at 10:55 AM, Helmut Kudrnovsky wrote: > > >Now to find why it's not working the same way here with 7.5svn release > > GRASS 7.4.0 and GRASS trunk seems to behave differently in set up this > incomplete CRS in this case. I can not confirm, because ... > > GRASS 7.4.0

Re: [GRASS-user] r.series weights to zero

On Fri, Jun 8, 2018 at 12:30 PM, Frank DAVID wrote: > > > > > Cordialement, > Frank David > > > Message d'origine > De : Markus Metz > Date :07/06/2018 17:30 (GMT+01:00) > À : Frank David > Cc : grass-user , GRASS developers list >

Re: [GRASS-user] r.series weights to zero

On Tue, Jun 5, 2018 at 2:51 PM, Frank David wrote: > > Hi all Grass users, > > It's seems that r.series weights does not accept zero as weight... Is it possible ? Yes, weights must be positive. > and so, why ? A zero weight means that all values in this map are ignored. Zero weights can also

Re: [GRASS-user] new GRASS virtual raster in trunk

On Mon, Jun 4, 2018 at 3:36 PM, Nikos Alexandris wrote: > > * Rich Shepard [2018-06-04 05:56:16 -0700]: > >> On Mon, 4 Jun 2018, Markus Metz wrote: >> >>> A new GRASS virtual raster format has been added to trunk in r72761-4, >>> together with a new

[GRASS-user] new GRASS virtual raster in trunk

A new GRASS virtual raster format has been added to trunk in r72761-4, together with a new module to build a GRASS VRT: r.buildvrt. *r.buildvrt* builds a virtual raster (VRT) that is a mosaic of the list of input raster maps. The purpose of such a VRT is to provide fast access to small subsets of

Re: [GRASS-user] GRASS GIS virtual raster data sets

On Thu, May 31, 2018 at 10:41 PM, Markus Neteler wrote: > > On Wed, May 30, 2018 at 4:21 PM, Nikos Alexandris > wrote: > > Dears, > > > > I guess there is no GRASS GIS built-in implementation of GDAL's VRT > > concept (several related ideas listed > >

Re: [GRASS-user] v.color takes a long time for 2E6 records

On Wed, May 30, 2018 at 11:50 PM, Mehrdad Varedi wrote: > > Hi Everyone, > > When using v.color on a map with 2 Million points, it takes more than 24 hours (I guess the last time it took near 40 hours). The CPU is busy less than 20% on a 8 core machine and a lot of memory is available (50% at

Re: [GRASS-user] geodatabase or shapefile?

On Wed, May 30, 2018 at 2:04 AM, Rich Shepard wrote: > > On Tue, 29 May 2018, knussear wrote: > >> I have had success reading data from geodatabases in R and QGIS, but only >> vector layers. If they have embedded rasters you will need Arc to get them >> out. > > > As I responded to Thomas, they

Re: [GRASS-user] v.select: difference between overlap and crosses for atype=areas and btype=lines

On Fri, May 25, 2018 at 7:45 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Fri, May 25, 2018 at 4:43 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > > > On 25/05/18 09:05, Moritz Lennert wrote: > >> > >> Hi,

Re: [GRASS-user] v.select: difference between overlap and crosses for atype=areas and btype=lines

On Fri, May 25, 2018 at 4:43 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > On 25/05/18 09:05, Moritz Lennert wrote: >> >> Hi, >> >> Could someone explain the difference between overlap and crosses in >> v.select for the case where atype is areas and btype is lines ? >> >> Using the

Re: [GRASS-user] reorder columns in vector attribute table

On Wed, May 23, 2018 at 12:41 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > > > Am 23. Mai 2018 12:23:45 MESZ schrieb Stefan Blumentrath < stefan.blumentr...@nina.no>: > >Ciao Vero, > > > >Unfortunately, it seems you have to create a new table with desired > >column order, copy

Re: [GRASS-user] v vol rst super slow

On Wed, May 23, 2018 at 1:40 PM, Markus Neteler wrote: > > On Wed, May 23, 2018 at 1:18 PM, Sören Gebbert > wrote: > > Hi, > > your region settings are interesting. > > Do you really need a resolution of 5m in x,y plane and 1m in z direction? > >

Re: [GRASS-user] v vol rst super slow

On Wed, May 23, 2018 at 1:09 PM, Francois Chartier wrote: > > see below > g.region -3p > > projection: 1 (UTM) > zone: 17 > datum: nad83 > ellipsoid: grs80 > north: 4870795 > south: 4825715 > west: 609204 > east: 651669 > top:

Re: [GRASS-user] r.import/r.in.gdal jpeg2000 image

On Mon, May 21, 2018 at 12:01 AM, Helmut Kudrnovsky wrote: > > Paul Shapley-2 wrote > > Hi Users, > > > > Trying to import a jpeg2000 image (size 8.78 gb) with both r.import and > > r.in.gdal but get the error below for each module. I am using the 64 bit > > version of Grass 7.4.0

Re: [GRASS-user] custom local map location

On Sat, May 19, 2018 at 11:35 AM, Ken Mankoff wrote: > > Hi GRASS List, > > I've just spent 30 days on a field campaign collecting data. I have a large amount of it in a GRASS mapset with location EPSG:3413. I'd like to set up a new location with (0,0) centered on our basecamp

Re: [GRASS-user] Redefining computational region for vector overlay

On Sun, May 13, 2018 at 7:06 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > Le Sun, 13 May 2018 17:48:41 +0200, > Hernán De Angelis a écrit : > > > Thanks for your answer and link, Moritz. > > > > Of course, slow or fast are relative terms. May be I wasn't

Re: [GRASS-user] To import from or to link to data stored in a PostgreSQL data base?

On Tue, May 8, 2018 at 4:01 PM, Nikos Alexandris wrote: > > Dears, > > the following concerns an update of an existing workflow, part of which > is GRASS GIS, that makes use of a large PostgreSQL data base which does > not reside locally. > > > The original data set

Re: [GRASS-user] Clustering process in i.segment

On Mon, May 7, 2018 at 4:03 PM, Giuseppe Esposito wrote: > > Dear GRASS GIS experts, > > I’m approaching segmentation in GRASS GIS and some doubts arised when reading the manual of the i.segment module ( https://grass.osgeo.org/grass74/manuals/i.segment.html). For this

Re: [GRASS-user] r.contour contour wrap

On Tue, May 1, 2018 at 9:57 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Tue, May 1, 2018 at 4:20 PM, Heidi Ochis <h...@ctmap.com> wrote: > > > > Using a USGS 10 meter NED elevation model, r.contour in versions 5, 64 and 72 create contours t

Re: [GRASS-user] flow accumulation (GRASS and Esri ArcGIS)

On Wed, May 2, 2018 at 8:29 PM, Anna Petrášová wrote: > > On Wed, May 2, 2018 at 2:21 PM, Markus Neteler wrote: > > On Wed, May 2, 2018 at 7:13 PM, Martin Landa wrote: > >> Hi, > >> > >> one of my colleague is dealing with flow

Re: [GRASS-user] v.clean Failed to build area

re these incorrect boundaries first appeared in the processing steps of your original vector. Markus M > > Very clumsy, but it worked. > > Thank you! > > Peter > > On Fri, Apr 27, 2018 at 11:51 AM, Markus Metz < markus.metz.gisw...@gmail.com> wrote: >> >> [ pleas

Re: [GRASS-user] r.contour contour wrap

On Tue, May 1, 2018 at 4:20 PM, Heidi Ochis wrote: > > Using a USGS 10 meter NED elevation model, r.contour in versions 5, 64 and 72 create contours that trace back on themselves anytime the contour exits the grid. Islands are the only lines that do not create a line with

Re: [GRASS-user] v.clean Failed to build area

external datasource without modification of the geometries inside GRASS, this version would be preferable. Otherwise the history of plot_pa_with_lidar@project_area would be helpful (v.info -h). Markus M > > Peter > > On Thu, Apr 26, 2018 at 11:19 PM, Markus Metz < markus.metz.gisw...

Re: [GRASS-user] v.clean Failed to build area

On Fri, Apr 27, 2018 at 1:37 AM, Peter Tittmann wrote: > > Hi, > > I am attempting to use the `rmarea` tool in v.clean with a threshold of ~ 1000 sq meters. > [...] > > I am getting a rather cryptic message ‘Failed to build area’. > > > v.clean -c --overwrite --verbose

Re: [GRASS-user] problem with g.in.ogr

as input polygons don't overlap. In case polygons overlap, the number of centroids can be different from the number of input polygons. Markus M > > > > > Le 18/04/2018 à 18:55, Markus Metz a écrit : > > > > On Wed, Apr 18, 2018 at 5:39 PM, Camille Bezzina < camille.bez

Re: [GRASS-user] problem with g.in.ogr

can be imported successfully with v.in.ogr -2, forcing 2D output. In this case I don't understand (yet) why forcing 2D is necessary. Markus M > > Le 18/04/2018 à 17:30, Markus Metz a écrit : > > > > On Wed, Apr 18, 2018 at 5:27 PM, Camille Bezzina < camille.bezz...@geophom.fr

Re: [GRASS-user] problem with g.in.ogr

again, snapping with at least 1e-08: 'snap=1e-08'" > > Try importing with snap=0.01 or something like that (depending on the nature and precision of your data. > > Moritz > > > Thanks. > > > > Le 12/04/2018 à 16:39, Markus Metz a écrit : > > > > On Thu, Apr 12

Re: [GRASS-user] problem with g.in.ogr

n problem is close to the end, when building topology for the final output bati_D90_decoupe: WARNING: Nombre de contours incorrects: 8772 This is the reason for disappearing polygons. This is a bug that has been fixed a while ago, please update your GRASS version to the latest 7.2 or 7.4 release.

Re: [GRASS-user] problem with g.in.ogr

On Thu, Apr 12, 2018 at 3:04 PM, Camille Bezzina wrote: > > Hello all, > > I have a problem with v.in.ogr. > I would like to import a shape file (with 57851 polygons) with v.in.ogr. > > v.import --verbose

[GRASS-user] new addon v.clean.ogr to clean polygons

Hi all, there is a new addon v.clean.ogr that imports a single OGR layer with polygons, cleans the polygons, and exports the polygons again. Any overlaps are exported as a separate OGR layer. This tool should only be used with polygons that are not supposed to overlap. For example,

Re: [GRASS-user] Change the length and type of columns in an attribute table

5 15:01:50 2018) > v.patch -e --overwrite --verbose input=zone_vegetation_D90_decoupe@AIP_RONCHAMP_MNE ,zone_vegetation_D70_decoupe@AIP_RONCHAMP_MNE output=TEST_merge_D70_D90 > ERROR: Length of string columns differ > (Thu Apr 5 15:01:51 2018) La commande s'est terminée (1 sec) I see. v.db.drop

Re: [GRASS-user] Change the length and type of columns in an attribute table

On Wed, Apr 4, 2018 at 5:54 PM, Camille Bezzina wrote: > > Hello all, > > > I have a problem when I want to modify an attribute table. > > I add a new vector with v.in.ogr. My attribute table is build like that : > > name type

Re: [GRASS-user] [GRASS-dev] Helena Mitasova awarded 2018 Waldo-Tobler GIScience Prize

Congratulations, Helena! All the best, Markus M On Tue, Apr 3, 2018 at 11:25 PM, Markus Neteler wrote: > https://gi-science.blogspot.com/2018/04/helena-mitasova- > awarded-2018-waldo.html > > "The Austrian Academy of Sciences through its Commission for GIScience is >

Re: [GRASS-user] Need Help with speeding up v.import and reducing/removing null values from v.rast.stat results

d not be used? Markus M > > Cheers > > Stefan > > > > > > From: Markus Metz <markus.metz.gisw...@gmail.com> > Sent: fredag 23. mars 2018 17.57 > To: Mehrdad Varedi <var...@waterlix.com> > Cc: Stefan Blumentrath <stefan.blumentr...@nina.no>; g

Re: [GRASS-user] [GRASS-dev] PROJ 5 support in trunk

On Thu, Mar 22, 2018 at 4:38 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Thu, Mar 22, 2018 at 7:16 AM, Markus Neteler <nete...@osgeo.org> wrote: > > > > On Tue, Mar 20, 2018 at 8:04 PM, Markus Metz > > <markus.metz.gisw...@gmail

Re: [GRASS-user] [GRASS-dev] PROJ 5 support in trunk

On Thu, Mar 22, 2018 at 7:16 AM, Markus Neteler <nete...@osgeo.org> wrote: > > On Tue, Mar 20, 2018 at 8:04 PM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > > Hi all, > > > > I have added support for the new PROJ 5+ API in trunk, finished with r7243

Re: [GRASS-user] PROJ 5 support in trunk

On Tue, Mar 20, 2018 at 8:04 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > Hi all, > > I have added support for the new PROJ 5+ API in trunk, finished with r72433. Now really finished with trunk r72443. Markus M > This means, trunk is now using exclusivel

[GRASS-user] PROJ 5 support in trunk

Hi all, I have added support for the new PROJ 5+ API in trunk, finished with r72433. This means, trunk is now using exclusively the new PROJ 5+ API if available. This new PROJ 5 API is available e.g. in Debian testing. Please test! During testing, I discovered some dangerous naming conflicts

Re: [GRASS-user] r.in.lidar build errors

On Wed, Mar 7, 2018 at 10:27 PM, Rich Shepard <rshep...@appl-ecosys.com> wrote: > > On Wed, 7 Mar 2018, Markus Metz wrote: > >> Apparently your liblas installation does not find libproj.so.12. > > > Markus, > > There are two issues and I think they're becomin

Re: [GRASS-user] r.in.lidar build errors

On Tue, Mar 6, 2018 at 5:22 PM, Rich Shepard wrote: > > I think there was a recent thread on *.in.lidar modules, but I paid no > attention as I'm not currently using lidar data. > > After checking out the latest from the grass7_trunk svn repository I > configured the

Re: [GRASS-user] Multiple `r.proj` requests on the same raster map(s)

On Sun, Feb 25, 2018 at 6:34 PM, Nikos Alexandris wrote: > > Thanks a lot Markus. > > I didn't mean to "hide" details. Details are not so important here, and it is easy to get lost in details. The general workflow and design on how to run GRASS processing chains in

Re: [GRASS-user] r.cross doesn't work correctly.

On Mon, Feb 26, 2018 at 2:38 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Mon, Feb 26, 2018 at 1:31 PM, Nikos Alexandris <n...@nikosalexandris.net> wrote: > > > > * Markus Metz <markus.metz.gisw...@gmail.com> [2018-02-26 13:01:35 +010

Re: [GRASS-user] r.cross doesn't work correctly.

On Mon, Feb 26, 2018 at 1:31 PM, Nikos Alexandris <n...@nikosalexandris.net> wrote: > > * Markus Metz <markus.metz.gisw...@gmail.com> [2018-02-26 13:01:35 +0100]: > >> On Mon, Feb 26, 2018 at 11:19 AM, Gra <graz...@gmail.com> wrote: >>> >>>

Re: [GRASS-user] r.cross doesn't work correctly.

On Mon, Feb 26, 2018 at 11:19 AM, Gra wrote: > > Dear community > > I use r.cross to combine and then reclassify a set of indicators. > > I realised that r.cross doesn't work correctly. > > I have two inputs maps with values from 1 to 3 each. > > > the problem is that

Re: [GRASS-user] Multiple `r.proj` requests on the same raster map(s)

On Sun, Feb 25, 2018 at 9:44 AM, Nikos Alexandris <n...@nikosalexandris.net> wrote: > > * Markus Neteler <nete...@osgeo.org> [2018-02-24 23:00:32 +0100]: > >> On Sat, Feb 24, 2018 at 10:31 PM, Markus Metz >> <markus.metz.gisw...@gmail.com> wrote: >>

Re: [GRASS-user] Multiple `r.proj` requests on the same raster map(s)

On Sat, Feb 24, 2018 at 10:06 PM, Nikos Alexandris <n...@nikosalexandris.net> wrote: > > * Markus Metz <markus.metz.gisw...@gmail.com> [2018-02-24 21:39:40 +0100]: > >> On Sat, Feb 24, 2018 at 9:25 PM, Nikos Alexandris < n...@nikosalexandris.net> >> wrote: &

Re: [GRASS-user] Multiple `r.proj` requests on the same raster map(s)

On Sat, Feb 24, 2018 at 9:25 PM, Nikos Alexandris wrote: > > Dear community, > > I am asking for help to "debug" a situation. > > One ETRS89-based location, one Mapset with hundreds of land cover raster > map tiles. > > Then, hundreds of UTM Zones-based Locations, subset

Re: [GRASS-user] v.hull ignoring 'where' argument

On Thu, Feb 22, 2018 at 9:10 PM, Martin Landa wrote: > > Hi, > > 2018-02-22 21:02 GMT+01:00 Markus Neteler : > > I have added a related note to the v.hull manual page (maybe others > > should be extended as well?). > > probably. The module could print a

Re: [GRASS-user] v.hull ignoring 'where' argument

On Thu, Feb 22, 2018 at 10:05 AM, Helmut Kudrnovsky wrote: > > Vilem Ded wrote > > Hi, > > I have set of points with attribute table (let just say with column "A" > > containing 1s and 2s). > > I would love to use function v.hull in order to get two convex hulls > > (their > >

Re: [GRASS-user] installing grass 7.4 and grass-qgis plugin under fedora 27

On Mon, Feb 19, 2018 at 10:15 AM, Laura Poggio wrote: > > Dear Markus, > thank you very much for your help. > > In the error message, I used dnf install qgis* and it was trying to install both versions. But the same error happens with 64 bits. > > Regarding QGIS not

Re: [GRASS-user] LSMetrics - addon development

On Fri, Feb 16, 2018 at 10:05 AM, Markus Neteler <nete...@osgeo.org> wrote: > > On Fri, Feb 16, 2018 at 9:42 AM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > ... > > I can't reproduce with your compiler flags. A wild guess: in draw.c:L3 try > > t

Re: [GRASS-user] LSMetrics - addon development

On Thu, Feb 15, 2018 at 10:38 PM, Markus Neteler <nete...@osgeo.org> wrote: > > On Thu, Feb 15, 2018 at 7:49 PM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > > > > > > On Thu, Feb 15, 2018 at 5:57 PM, Markus Neteler <nete...@osgeo.org> wro

Re: [GRASS-user] LSMetrics - addon development

On Thu, Feb 15, 2018 at 5:57 PM, Markus Neteler wrote: > > On Thu, Feb 15, 2018 at 5:43 PM, Moritz Lennert > wrote: > > On 12/02/18 18:01, Bernardo Santos wrote: > ... > >> Regarding the comparison with the other GRASS tools, LSMetrics is > >>

Re: [GRASS-user] load vector map from PostGIS

an add a .pgpass file entry as such: thehost:5432:thedb:theuser:thepasswd then you don't need to provide username and password in the script, the PG client library will fetch them from the .pgpass file. Markus M > Thank you very much > Vil > -- Původní e-mail -- >

Re: [GRASS-user] load vector map from PostGIS

On Wed, Feb 14, 2018 at 4:44 PM, Vilem Ded wrote: > > Thank you a lot. I have managed to move forward, but i am not there yet:/ > I can definitely reach the database since the command: > v.in.ogr -l input= "PG:host=172.21.3.20 dbname=mydb user=dbusername password=passwd" >

Re: [GRASS-user] load vector map from PostGIS

On Tue, Feb 13, 2018 at 2:58 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > Le Tue, 13 Feb 2018 14:09:31 +0100 (CET), > "Vilem Ded" a écrit : > > > Hi, > > is there any possibility to download data into local grass database > > (topologcal) from remote postgis

Re: [GRASS-user] v.generalize failing on some geoms

On Tue, Feb 13, 2018 at 9:02 AM, Paolo Cavallini <cavall...@faunalia.it> wrote: > > Hi Markus, > > Il 12/02/2018 21:46, Markus Metz ha scritto: > > > The original data in EPSG:3003 and EPSG:3857 are not identical. The > > original data in EPSG:3003 are topologi

Re: [GRASS-user] v.generalize failing on some geoms

On Mon, Feb 12, 2018 at 6:22 PM, Paolo Cavallini <cavall...@faunalia.it> wrote: > > Il 11/02/2018 18:34, Markus Metz ha scritto: > > > This implies that the data have been reprojected at some stage somewhere > > from one SRS to the other. The most likely explanation fo

Re: [GRASS-user] v.generalize failing on some geoms

On Fri, Feb 9, 2018 at 6:19 PM, Paolo Cavallini wrote: > > Hi all, > v.generalize is failing to simplify some of my geometries when in > EPSG:3857. Same geoms in EPSG:3003 were simplified correctly. > Incorrect borders were reported, unclear to me why. > All the best, and

Re: [GRASS-user] i.atcorr range and rescale parameters for Sentinel 2 images

On Sat, Feb 10, 2018 at 6:11 PM, roberta fagandini wrote: > > Hi Markus and Žofie, > > thank you for your hints! > > I tested i.atcorr with range=1,1 and rescale=1,1. In this way, value 1 is assigned to all those pixels with reflectance greater than 1 in

Re: [GRASS-user] i.atcorr range and rescale parameters for Sentinel 2 images

On Thu, Feb 8, 2018 at 8:54 PM, roberta fagandini wrote: > > Hi all, > > I'm testing i.atcorr (grass 7.4) with Sentinel 2A images and i have some trouble defining the right values for range and rescale parameters. I read in other posts and lists that the suggested value

Re: [GRASS-user] i.atcorr with Sentinel2

On Thu, Jan 25, 2018 at 3:22 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Thu, Jan 25, 2018 at 3:11 PM, Stefan Blumentrath < stefan.blumentr...@nina.no> wrote: > > > > From: Markus Metz [mailto:markus.metz.gisw...@gmail.com] > > >

Re: [GRASS-user] i.atcorr with Sentinel2

gt; > Markus M found some issues in my version of create_iwave.py. > > I am fixing them right now! > > > > Cheers > > Stefan > > > > From: Žofie Cimburová [mailto:zoficimbur...@gmail.com] > Sent: onsdag 24. januar 2018 09.32 > To: Stefan Blumentrath <st

<    1   2   3   4   5   6   7   8   9   10   >