Hi Chris,
this " ERROR: Unable to seek: Invalid argument" is a strange error because
v.select uses exactly the same functions to seek and read data as the
modules you used to produce the input vectors for v.select.
You have already listed the commands leading to the error, could you also
provide
Hi Martin,
must be the metadata with the GRASS color rules that cause these problems
in QGIS. My guess is that QGIS does not apply these color rules in the
metadata to the overviews, only to the full COG bands.
Markus M
On Mon, Feb 22, 2021 at 3:37 PM Martin Landa wrote:
> Dear all,
>
> I am
A spatial Gauss filter is available in r.resamp.filter. I use it regularly
for smoothing and interpolation.
HTH,
Markus M
On Wed, Jan 27, 2021 at 4:03 PM Eric Patton via grass-user <
grass-user@lists.osgeo.org> wrote:
>
> Hi all,
>
> I was wondering if there was any tool in grass that does a
On Sun, Jan 24, 2021 at 8:25 PM ming han wrote:
>
> Hi everyone
>
> Is it possible to let r.stats.zonal output raster to be CELL?
The output of r.stats.zonal should be as accurate as possible, thus in most
cases a floating point output is required and produced.
If you want to reduce the
What about v.net.path to get shortest paths from a start node to a number
of end nodes?
Markus M
On Mon, Jan 11, 2021 at 2:32 PM Daniel McInerney <
daniel.o.mciner...@gmail.com> wrote:
>
> Hi List,
>
> I've been using v.net.allpairs [1] for the calculation of shortest paths
> between pairs of
On Thu, Jan 21, 2021 at 5:22 AM Maris Nartiss wrote:
>
> Hello Ashutosh.
>
> Compilation and development issues are better to ask in dev mailing list.
>
> Also – do not send errors as images. I have no idea what the error
> message you got was and I assume I am not the only one. MS Windows
> does
,
GRASS_EPSILON will not detect meaningful differences. GRASS_EPSILON could
instead be modified with something like "max(abs(map_A), abs(map_B)) *
1.0e-15" to test for meaningful differences.
Markus M
On Sun, Jan 24, 2021 at 5:32 PM Markus Metz
wrote:
>
>
>
> On Sun, Jan 24, 20
liably measured. (De-)compression of the data and the operating
system's file cache have a much stronger influence on the runtime.
Markus M
>
> Thanks
> Ming
>
> Markus Metz 于2021年1月24日周日 上午10:57写道：
>>
>> Trying to answer the original question: with a DCELL map "c
Trying to answer the original question: with a DCELL map "cat1_acc_riv" and
a FCELL map "cat1_minacc", why is "float(cat1_acc_riv) ==
float(cat1_minacc)" not equal to "int(cat1_acc_riv) == int(cat1_minacc)" ?
int truncates to integer while float converts to single precision floating
point. E.g.
with v.net, you
can use the extract of all lines with the same stream order as it is.
Markus M
> I'll try as soon as possible and will report back on how this works.
> cheers,
> Johannes
>
> On Wed, Mar 11, 2020 at 10:16 PM Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
On Thu, Mar 12, 2020 at 12:43 PM Johannes Radinger <
johannesradin...@gmail.com> wrote:
>
> Hi all,
> I am using v.in.ogr to import a shape file (line vector) that has only
one layer. Although I am specifying the output parameter in v.in.ogr the
layer name of the imported map still remains the
Hi Johannes,
IIUC, what you want to do is an operation that involves topological
relations of vector geometries (connected lines) and a common attribute.
There is no easy common recipe for this.
Just a suggestion:
for each stream order:
extract all lines with this stream order (v.extract)
Hi Johannes,
On Fri, Feb 28, 2020 at 4:27 PM Johannes Radinger <
johannesradin...@gmail.com> wrote:
>
> Hi all,
>
> I have two line vectors: LV1) a complete stream network LV2) sections of
the same stream network representing impoundments.
>
> LV2 is a subset of LV1 and fully spatially
On Mon, Mar 2, 2020 at 4:58 PM Ken Mankoff wrote:
>
> I'm not totally sure how to find the size of a GRASS raster from within
GRASS.
There is no tool in GRASS that reports the disk usage of a GRASS raster
map. r.compress only reports the change in disk usage.
> I could go to the OS to find it.
may
not mean faster, because then there is more data to write and read and I/O
is generally a significant bottleneck. Markus Metz may say more about this
as he did tests when he was implementing the new compressions, but you
might be able to find some posts on this on the grass-dev mailing li
ith older versions of GRASS, please try to
install again.
Markus M
>
> Thanks.
>
> Best regards,
>
> Firman Hadi.
>
>
>
>
> On Feb 24 2020, at 12:16 am, Markus Neteler wrote:
>
> On Sun, Feb 23, 2020 at 4:39 PM Markus Metz
> wrote:
>
> On Sun, Feb 23, 2020
On Sun, Feb 23, 2020 at 12:12 PM Firman Hadi wrote:
>
> Dear all,
>
> I am trying to install GRASS Addons (r.in.nasadem) from GRASS GIS 7.8.2
in MS Windows.
> I use GRASS GIS from QGIS 3.10 installer. I couldn't install it due to
file not found as attached image.
it seems like the wingrass build
Hi all,
NASA via lpdaac has released a new global DEM with 1 arcsec spatial
resolution:
https://lpdaac.usgs.gov/news/release-nasadem-data-products/
"NASADEM extends the legacy of the Shuttle Radar Topography Mission (SRTM)
by improving the digital elevation model (DEM) height accuracy and data
Hi Olivier,
when dealing with not so easy to handle input data, I recommend to use the
tools to handle these data directly instead of some interface like QGIS or
GRASS GIS that might hide some important information. For raster data, this
would be gdalinfo, for vector data ogrinfo, for point
On Mon, Feb 10, 2020 at 7:37 PM Rich Shepard
wrote:
>
> On Mon, 10 Feb 2020, Markus Metz wrote:
>
> > have a look at the end of config.log, there should be more details about
> > the error.
>
> Markus M,
>
> Mea culpa! I should have thought of doing this. This see
On Mon, Feb 10, 2020 at 4:55 PM Rich Shepard
wrote:
>
> On Thu, 6 Feb 2020, Rich Shepard wrote:
>
> > I've not before needed to specify a separate libLAS library path as
there
> > installed:
> > /usr/lib64/liblas.so@
> > /usr/lib64/liblas.so.2.4.0*
> > /usr/lib64/liblas.so.3@
> >
Hi Nikos,
On Mon, Feb 3, 2020 at 7:28 PM Nikos Alexandris
wrote:
>
> >>I got it working, more or less. Recompiling only PROJ did away most of
> >>the errors but a few. I guess I need to recompile PROJ (+GEOS), then
> >>GDAL, then the rest.
> >
> >Still need to fix a few more:
> >
> >Errors in:
>
Hi Nikos,
PROJ is moving fast, please use the latest PROJ 6 release 6.3.0
On Sat, Feb 1, 2020 at 8:36 PM Nikos Alexandris
wrote:
>
> Dears,
>
> I cannot get GRASS GIS 7.8 to compile with
> proj
> Rel. 6.0.0, March 1st, 2019
if possible, never use a x.0.0 release of any software, these new
Hi Vero, Roberta,
there is no error output because of ...
On Wed, Jan 29, 2020 at 11:15 PM Veronica Andreo
wrote:
>
> Hi Robi,
>
> So I found that i.sentinel.import fails for latlong locations. I moved to
UTM as in the original data and all fine. I reached the cloud masking step,
and I find a
On Sun, Jan 26, 2020 at 9:13 PM Valter Albino
wrote:
>
> Hi,
> Looking to produce a TWI. When running "r.topix", this hangs up at 74%.
What should be the problem?
Does r.topix crash, if yes, what it the error message, or does it just take
a long time to proceed after 74% have been reached?
The
On Mon, Jan 13, 2020 at 3:01 PM Nikolai Hafner wrote:
>
> I tested it from an other location too but it´s the same problem:
> r.proj location=ASTER_lat-long mapset=PERMANENT
> input=DHM_SRTM30m_Aut-plus-Umgebung output=dhm_30m_ASTER_dachstein
> method=bilinear resolution=30
> ERROR: Unable to
On Wed, Jan 15, 2020 at 5:09 PM Rich Shepard
wrote:
>
> On Wed, 15 Jan 2020, Rich Shepard wrote:
>
> > I've noticed that, too, and no longer produce flowline maps.
>
> And the region is set to the DEM used for all analyses on those projects.
the example in the manual works and produces 217038
On Mon, Jan 13, 2020 at 1:00 PM Helmut Kudrnovsky wrote:
>
> nik wrote
> >
--
> >
> > I downloaded and installed
> >
http://www.bev.gv.at/portal/page?_pageid=713,2157075&_dad=portal&_schema=PORTAL
> >
> >
home/user/local/
>>
>> Thanks!
>> Laura
>>
>> On Fri, 20 Dec 2019 at 09:22, Markus Metz
wrote:
>>>
>>>
>>>
>>> On Fri, Dec 20, 2019 at 7:47 AM Laura Poggio
wrote:
>>> >
>>> > Dear Markus,
>
On Fri, Dec 20, 2019 at 7:47 AM Laura Poggio wrote:
>
> Dear Markus,
> thanks
>
> Below my configure (grass 7.6.1 compiles fine with a similar configure.)
>
> ./configure \
> -prefix=/home/user/grass/ \
is it possible that prefix and path to the GRASS source are identical? This
will not work and
On Thu, Dec 12, 2019 at 2:40 PM Luis Moreira wrote:
>
> "Can you inform us about the new methods you had in mind?"
>
> Well, there is a software (IPH-Hydro Tools) [from the Large Scale
Hydrology
> research group of the Institute of Hydraulic Research at the Federal
> University of Rio Grande do
On Wed, Dec 11, 2019 at 2:16 PM Luis Moreira wrote:
>
> Hello everyone,
>
> I'd like to know if Grass still uses the S.K. Jenson and J.O. Domingue
> (1988) method to filter the elevation map, in its original conception.
I've
> read about some new and more improved methods and was wondering if
, it relies on PROJ to select an appropriate
datum transformation depending on the source and target CRS.
Markus M
On Mon, Dec 9, 2019 at 10:15 PM Markus Metz
wrote:
>
>
> On Wed, Dec 4, 2019 at 12:23 PM Zoltan Szecsei
> wrote:
> >
> > Hi Helmut,
> > Thank
On Wed, Dec 4, 2019 at 12:23 PM Zoltan Szecsei
wrote:
>
> Hi Helmut,
> Thanks for your comments.
>
> I installed everything with OSGeo4W64, and QGIS get the EPSG:2932 but
> Grass not.
>
> Perhaps I have a PATH or some other setting problem?
> Perhaps let me know what search paths Grass uses for
Hi all,
we found a serious bug when importing polygons from a PostgreSQL/PostGIS
db: resultant areas might have wrong attributes because of a mix-up of the
connection from geometries to attributes. This bug has been fixed in master
and relbr78 (a new release of GRASS 7.8 should probably come out
There are some solutions to the problem of datum
not recognized by GRASS:
- add Qatar_National_Datum_1995 to the datums known by GRASS
- ignore the warning and use GRASS with PROJ6, granted that authority name
(e.g. EPSG) and authority code (e.g. 2932) are known for both CRS's in case
of
On Wed, Nov 20, 2019 at 6:37 PM Daniel McInerney <
daniel.o.mciner...@gmail.com> wrote:
>
> Hi List,
>
> We are using v.net.distance to calculate the shortest path between two
> points on a river network, but have been experiencing some issues in
> both grass 7.4 and 7.9. In some instances, we
best,
> Vero
>
> ---
> Hi Vero,
>
> On Wed, Nov 13, 2019 at 4:05 PM Veronica Andreo
wrote:
> >
> > Hi Markus
> >
> > Thanks for the answer :)
> >
> > El mié., 13 nov. 2019 a las 14:18, Markus Metz (<
markus.metz.gisw...@gmail.com>) escr
Hi Vero,
On Wed, Nov 13, 2019 at 12:59 PM Veronica Andreo
wrote:
>
> Hi all,
>
> I'm using i.atcorr for atmospheric correction of Pleiades imagery. The
data comes as DN in 12 bits.
That is, values can be in the range 0, 4095, but the full possible range is
not necessarily used.
> Reading the
Regarding GDAL 3 support, we still need to add the new GDAL library
versions to lib/raster/gdal.c for r.external to work.
Markus M
On Tue, Nov 12, 2019 at 8:56 AM Markus Neteler wrote:
> What's new in a nutshell
>
> As a follow-up to the recent GRASS GIS 7.8.0 release we have pusblished
> the
On Wed, Nov 6, 2019 at 8:30 PM Martin Landa wrote:
>
> Hi Markus,
>
> st 6. 11. 2019 v 20:27 odesílatel Markus Metz
> napsal:
>
> > Fixed in master 43fae79
>
> thanks for hard work! Are you planning backport to grass78?
no, because this is a cosmetic change.
Marku
On Wed, Nov 6, 2019 at 4:52 PM Markus Metz
wrote:
>
>
>
> On Wed, Nov 6, 2019 at 3:01 PM Markus Neteler wrote:
> >
> > Hi Daniel,
> >
> > On Mon, Nov 4, 2019 at 12:23 PM Daniel McInerney
> > wrote:
> > >
> > > Hi List,
> &g
On Wed, Nov 6, 2019 at 4:54 PM Markus Metz
wrote:
>
>
>
> On Wed, Nov 6, 2019 at 9:43 AM Helmut Kudrnovsky wrote:
> >
> > >next daily builds (32/64bit) should be built against GDAL3/PROJ6.
> >
> > daily build 78:
> >
> >
https://wingra
On Wed, Nov 6, 2019 at 9:43 AM Helmut Kudrnovsky wrote:
>
> >next daily builds (32/64bit) should be built against GDAL3/PROJ6.
>
> daily build 78:
>
>
https://wingrass.fsv.cvut.cz/grass78/x86_64/logs/log-r9c8923eb9-9/package.log
>
> ##
>
> [...]
> checking for location of
On Wed, Nov 6, 2019 at 3:01 PM Markus Neteler wrote:
>
> Hi Daniel,
>
> On Mon, Nov 4, 2019 at 12:23 PM Daniel McInerney
> wrote:
> >
> > Hi List,
> >
> > As part of a workflow, we are importing ESRI Shapefiles into GRASS so
> > that we can manage the vector topology, before re-exporting the
On Fri, Nov 1, 2019 at 12:11 AM Veronica Andreo
wrote:
>
> Hi Micha
>
> El jue., 31 oct. 2019 a las 22:36, Micha Silver ()
escribió:
>>
>>
>> On 31/10/2019 22:20, Markus Metz wrote:
>>
>>
>>
>> On Tue, Oct 29, 2019 at 7:40 PM Veronica
On Tue, Oct 29, 2019 at 7:40 PM Veronica Andreo
wrote:
>
> Hi Daniel,
>
> I agree that if there's a NULL in the column, there should be NULL in the
resulting raster. I suggest to open a ticket here:
https://trac.osgeo.org/grass/
easy solution: v.to.rast where=" is not null"
or the new PR #173
On Tue, Oct 29, 2019 at 7:40 PM Veronica Andreo
wrote:
>
> Hi Daniel,
>
> I agree that if there's a NULL in the column, there should be NULL in the
resulting raster. I suggest to open a ticket here:
https://trac.osgeo.org/grass/
that would require to change db_select_CatValArray on library level
On Tue, Sep 24, 2019 at 12:34 AM Rich Shepard
wrote:
>
> On Mon, 23 Sep 2019, Markus Neteler wrote:
>
> > Well, without error message nor link to the data it is hard to say.
> > In addition, it is usually worthwhile to check a dataset with gdalinfo.
>
> Markus,
>
> I'm dealing with two separate
On Fri, Sep 20, 2019 at 3:08 PM Markus Metz
wrote:
>
>
>
> On Fri, Sep 20, 2019 at 2:21 PM Luís Moreira de Sousa <
luis.de.so...@protonmail.ch> wrote:
> >
> > Hi again Markus, thank you for following up.
> >
> > In your example we can see this:
> >
On Fri, Sep 20, 2019 at 2:21 PM Luís Moreira de Sousa <
luis.de.so...@protonmail.ch> wrote:
>
> Hi again Markus, thank you for following up.
>
> In your example we can see this:
>
> rm /home/mneteler/tmp//grass76/include/Make/Platform.make
> make
On Thu, Sep 19, 2019 at 4:51 PM Rich Shepard
wrote:
>
> When I run r.proj grass presents information about the source and target
> maps; e.g.,
>
> Input:
> Cols: 8 (8)
> Rows: 15536 (15536)
> North: 1515424.50 (1515424.50)
> South: 1468816.50 (1468816.50)
> West:
On Thu, Sep 19, 2019 at 12:36 AM Rich Shepard
wrote:
>
> On Wed, 18 Sep 2019, Moritz Lennert wrote:
>
> > You cannot launch GRASS GIS within the script in this way. You have to
> > put the actual module calls into a script and then either
> >
> > - launch GRASS GIS and from the GRASS command line
On Thu, Sep 12, 2019 at 2:24 AM Rich Shepard
wrote:
>
> Importing a large (4.4G) vector map of wetlands takes a long time even on
my
> 8-core/16-thread, 32G desktop. When it finally completed grass recommended
> re-importing with an additional 'snap' distance specified:
>
> Command line: >
On Sun, Sep 15, 2019 at 8:39 PM Rich Shepard
wrote:
>
> On Sat, 14 Sep 2019, Markus Metz wrote:
>
> > gdalwarp estimates the target extents unless you use the -te option. In
> > contrast, r.proj uses the current region. r.proj can estimate the target
> > extents with t
On Sat, Sep 14, 2019 at 1:15 AM Helmut Kudrnovsky wrote:
>
> Rich Shepard wrote
> > Reprojecting a 10m DEM fails. Following are the command and input/output
> > projection and map description information. Screenshots of the input and
> > output maps are attached.
> >
> > I need to understand why
0:15E res=00:00:30
-s
after that start GRASS again in the mapset with your data.
Markus M
> Thanks a lot again for your help.
> Regards,
> Gabriel
>
>
>
>
>
>
>
>
> On Tue, Aug 27, 2019 at 4:02 PM Markus Metz
wrote:
>>
>>
>>
>> On Tue, Aug 27,
On Mon, Aug 26, 2019 at 11:10 PM Rich Shepard
wrote:
>
> The region in the project location is incorrect. With only one small data
> set imported I decided to start over by deleting that location in
> /data/grassdata/.
>
> I created a subdirectory for the project /data/grassdata/mohler/ then
>
QGIS uses GDAL to fetch metadata of raster maps, therefore the output of
gdalinfo would be more informative, but you know the relevant parts
already: these raster maps need to be imported with r.in.gdal -a
Markus M
>
>
>
> On Mon, Aug 26, 2019 at 4:01 PM Markus Metz
wrote:
>>
On Mon, Aug 26, 2019 at 1:14 AM Gabriel Cotlier wrote:
>
> Dear Markus,
>
> I uninstall and reinstall grass 7.6.1 64 bits and still my log for the
commands
>
> g.region -p
>
> and
>
> g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30
>
> are respectively :
>
> (Sun Aug 25
n to w=179:59:45W e=180:00:15E, am I not only avoiding
the warning, but also changing the layers to be physically correct, right?
>>
>> Thanks again for your help.
>> regards,
>> Gabriel
>>
>>
>> On Tue, Aug 20, 2019 at 4:24 PM Markus Metz <
markus.metz.gisw...
Maybe according to my attached log file is possible to know if all the
intercallibration operation was correctly done and thus the layers are
ready for further study and analysis.
>
>
> Thanks a lot again for your help.
> Kind regards,
> Gabriel
>
> Virus-free. www.avast.com
&
On Mon, Aug 19, 2019 at 12:05 AM Gabriel Cotlier
wrote:
>
> Hello,
> My question is how does it influence the fact that it say:
> 360 degree EW extent is exceeded by 0.999827 cells
this is caused by the truncated resolution of 0.0083330
with a corrected resolution of 00:00:30, the
On Mon, Aug 19, 2019 at 6:51 PM Rich Shepard
wrote:
>
> On Thu, 15 Aug 2019, Rich Shepard wrote:
>
> > /usr/local/grass79/etc/VERSIONNUMBER is 7.9.dev 86354090c.
>
> I just ran 'git pull' and configured, made, and installed the results. The
> version number is the same as above and the initiation
On Thu, Aug 15, 2019 at 10:50 PM Rich Shepard
wrote:
>
> On Thu, 15 Aug 2019, Markus Metz wrote:
>
> > but the gui is looking in /usr/lib64/python2.7/site-packages/
> > -> wrong python version
> > make sure wxpython for python3 is installed, make distclean, configu
On Thu, Aug 15, 2019 at 8:12 PM Rich Shepard
wrote:
>
> Starting grass-7.9 in a new location and mapset fails:
>
> wxnviz.py: This module requires the NumPy module, which could not be
imported. It probably is not installed (it's not part of the standard
Python distribution). See the Numeric
On Thu, Aug 15, 2019 at 9:48 AM Markus Metz
wrote:
>
>
>
> On Wed, Aug 14, 2019 at 8:32 PM Veronica Andreo
wrote:
> >
> > Hello,
> >
> > I'm preparing a workshop for geostat and I want to use r.bioclim. Data
was converted to degree C. This is the command i
On Wed, Aug 14, 2019 at 8:32 PM Veronica Andreo
wrote:
>
> Hello,
>
> I'm preparing a workshop for geostat and I want to use r.bioclim. Data
was converted to degree C. This is the command i use:
>
> r.bioclim \
> tmin=`g.list type=raster pattern="lst_minimum_??" separator=,` \
> tmax=`g.list
iver GML does not support open option REMOVE_UNUSED_LAYERS
> Warning 6: driver GML does not support open option REMOVE_UNUSED_FIELDS
> ERROR 6: The GeoJSON driver does not overwrite existing files.
> ERROR 1: GeoJSON driver failed to create SMALL.json
>
> Best,
> peter
>
>
reach the person managing the list at
> > grass-user-ow...@lists.osgeo.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of grass-user digest...&qu
Hi Eric,
On Tue, Aug 6, 2019 at 8:23 PM Eric Patton
wrote:
>
> Hi,
>
> I have a massive Delaunay polygon tessellation that I converted to lines
with v.type. I then stripped this vector of centroids using v.edit
tool=delete type=centroids, and added categories to the line segments with
Hi Peter,
On Tue, Aug 6, 2019 at 12:23 PM "Peter Löwe" wrote:
>
> Hi Stefan,
>
> thanks for the link: That's also the latest information we found so far,
except for several OSGeo conference recordings (e.g.
https://doi.org/10.5446/40913 https://doi.org/10.5446/40694).
GML and GMLAS are
On Mon, Aug 5, 2019 at 5:35 PM Sebastián Dietrich
wrote:
>
> Hi everyone, when i try to launch g.gui i get the following message:
>
> GRASS 7.4.1 (EPSG5344):~/Documentos/grassdata > g.gui
> Lanzando GUI en el fondo, por favor espere...
> Traceback (most recent call last):
> File
On Sun, Jul 21, 2019 at 7:01 PM Rich Shepard
wrote:
>
[...]
so you want to define a boundary with 5 coordinates and no categories: that
is
B 5
and make sure you do not define a category for the boundary
and a centroid with one coordinate and one category
C 1 1
therefore remove the line with " 1
On Fri, Jul 19, 2019 at 11:44 PM Rich Shepard
wrote:
>
> Trying to re-project a vector file from location lon_lat to the project's
> location fails:
>
> Reprojecting primitives ...
> WARNING: proj_trans() failed: latitude or longitude exceeded limits
> ERROR: Unable to re-project vector map from
On Fri, Jul 19, 2019 at 11:44 PM Rich Shepard
wrote:
>
> Trying to re-project a vector file from location lon_lat to the project's
> location fails:
>
> Reprojecting primitives ...
> WARNING: proj_trans() failed: latitude or longitude exceeded limits
Which version of proj are you using? Note
On Thu, Jul 18, 2019 at 6:39 PM Rich Shepard
wrote:
>
> On Thu, 18 Jul 2019, Markus Metz wrote:
>
> > You wrote
> > "On my systems there's libgeos-3.7.2.so."
> > Is there also libgeos-3.7.1.so?
>
> Markus M,
>
> No. Only libgeos-3.7.2.so on all ho
On Thu, Jul 18, 2019 at 6:24 PM Rich Shepard
wrote:
>
> On Thu, 18 Jul 2019, Markus Metz wrote:
>
> > that does not make sense to me. Other software/libraries also link
against
> > geos, e.g. gdal, maybe one of those needs to be updated because of
updated
> > geos. Is &
On Thu, Jul 18, 2019 at 5:58 PM Rich Shepard
wrote:
>
> On Thu, 18 Jul 2019, Markus Metz wrote:
>
> >> Aha! On my systems there's libgeos-3.7.2.so.
>
> > yes, that's the error. Either "make distclean" or if that does not help
> > figure out if
On Thu, Jul 18, 2019 at 5:48 PM Rich Shepard
wrote:
>
> On Thu, 18 Jul 2019, Rich Shepard wrote:
>
> > / error while loading shared libraries: libgeos-3.7.0.so: cannot open
shared
>
> Aha! On my systems there's libgeos-3.7.2.so.
yes, that's the error. Either "make distclean" or if that does not
Hi Rich,
On Thu, Jul 18, 2019 at 4:49 PM Rich Shepard
wrote:
>
> On Thu, 18 Jul 2019, Markus Neteler wrote:
>
> > Please check in the lines above (there must have been output in the
> > terminal in which you compile) for error messages.
>
> Markus,
>
> My apologies for not doing this before.
>
>
On Thu, Jul 18, 2019 at 6:07 AM Stephane Goldstein wrote:
>
> I am getting a weird result when using v.overlay since I upgraded from
version 7.4 to 7.6.
this was a bug in finding line intersections, fixed in d729e94:
https://github.com/OSGeo/grass/commit/d729e9406ac1bff0d68b0e10b3de44b62bc2d064
On Thu, Jun 27, 2019 at 5:42 PM Alessandro Sebastiani <
alessandro.sebasti...@uniroma1.it> wrote:
>
> Hello to everybody,
> i tried to run r.li.mps module in order to perform mean patch size index
over a raster map. I used a raster with 4 values (1,2,3,4) rapresenting
different Land cover types.
On Thu, Jun 27, 2019 at 7:37 AM Micha Silver wrote:
>
>
> On 26/06/2019 23:44, Markus Metz wrote:
>
>
>
> On Wed, Jun 26, 2019 at 10:16 PM Micha Silver wrote:
> >
> >
> >
> >
> >
> > micha@TP480:code$ ogrinfo -so ../GIS/Ashalim
On Wed, Jun 26, 2019 at 10:16 PM Micha Silver wrote:
>
>
> On 26/06/2019 23:03, Markus Metz wrote:
>
>
>
> On Wed, Jun 26, 2019 at 4:58 PM Micha Silver wrote:
> >
> > I am trying to import some geopackage files. Some are polygons, and one
is a points
On Wed, Jun 26, 2019 at 4:58 PM Micha Silver wrote:
>
> I am trying to import some geopackage files. Some are polygons, and one
is a points vector. The polygons import fine, but the point vector fails
with:
>
> ERROR: Detected different projections of input layers. Input layers must
be
>
On Fri, Jun 21, 2019 at 2:19 PM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:
>
> Ah, OK. Got that wrong, sorry.
>
> I don`t think holes have an area (but I may be wrong)
> So you might have to add a centroid first?
> https://grass.osgeo.org/grass76/manuals/v.centroids.html
No,
solution that is really enhancing
the spatial detail not just multiplying existing spatial detail (more
content, same amount of info).
With these region settings, I get a minimum size of 120 cells for resultant
segments according to "r.stats -c", with both i.segment.hierarchical and
i.segment as used by
Hi Lara,
On Wed, Jun 19, 2019 at 7:06 PM Lara DC wrote:
>
> Hello!
>
> I am just starting to use GRASS.
> I am trying to import a new Modis product about atmospheric aerosols.
> I need to import hdf files, which have 13 bands (I am interested in band
1).
this hdf has 13 subdatasets, not 13
Hi Robert,
On Wed, Jun 19, 2019 at 4:26 PM Robert Nuske
wrote:
>
> Dear Listers,
>
> I would like to smooth polygons coming from a raster via r.to.vect using
> v.generalize methods=snakes.
>
> If I understood the documentation correctly, snakes is the only method
> that tries to go the middle
On Tue, Jun 18, 2019 at 3:31 PM Jamille Haarloo
wrote:
>
> Dear Grass members,
>
> I have been testing i.segment and i.segment.hierarchical on a small
region with Sentinel bands. However, the results consistently include
segments of just one pixel even-though minimal segment sizes of 10 and 20
On Tue, Jun 18, 2019 at 4:08 PM Micha Silver wrote:
>
> It looks like you've run out of integer values for the "category" primary
key.
>
> Do you really want a vector polygon map with > 2 billion features?
>
>
> On 18/06/2019 15:14, Ken Mankoff wrote:
>
> Hello,
>
> I think I'm experiencing a
On Fri, Jun 7, 2019 at 10:44 AM Margherita Di Leo
wrote:
>
>
>
> On Fri, Jun 7, 2019 at 12:16 AM Markus Neteler wrote:
>>
>> On Fri, May 24, 2019 at 6:36 PM Martin Landa
wrote:
>> >
>> > Hi,
>> >
>> > pá 24. 5. 2019 v 15:48 odesílatel Margherita Di Leo
napsal:
>> > > as far as I remember, it
Hi Madi,
On Thu, Jun 6, 2019 at 4:13 PM Margherita Di Leo wrote:
>
> Hi,
>
> reading the training material here:
http://training.gismentors.eu/grass-gis-irsae-winter-course-2018/units/23.html
> I have a doubt. When cloud mask is applied to calculate NDVI
>
> t.rast.mapcalc input=b4,b8,cloud
r areas for points within GRASS, i.e., using
v.buffer, the problem appears again when buffer areas overlap, which it's
pretty common when creating buffers around neighbouring points. Then, to
get zonal stats for those areas the approach suggested by Markus Metz
should be followed. I believe it is a
ls, try the proj
5.9.3 release?
As I wrote earlier, GRASS should now build with proj 6, but coordinate
operations can produce wrong results.
proj-5.2.0 is the latest proj 5 release, GRASS is working with proj-5.2.0
Markus M
> ~ Eric.
>
>
>
> From: Markus Metz
> Sent: May
https://github.com/OSGeo/grass.git’ – so shouldn’t that fix already be
present in my source tree?
It depends when you updated master the last time. If in doubt, git pull
again.
Markus M
>
>
>
> ~ Eric.
>
>
>
> From: Markus Metz
> Sent: May 22, 2019 12:25
> To: Markus
On Wed, May 22, 2019 at 4:39 PM Markus Neteler wrote:
>
> Hi Eric,
>
> On Wed, May 22, 2019 at 3:32 PM Patton, Eric (NRCan/RNCan)
> wrote:
> >
> > Hi Markus,
> >
> > I noted your new installation instructions for the git repo and have
used those.
> >
> > The first error in error.log occurs in
On Tue, May 14, 2019 at 12:26 AM Tyler Smith wrote:
>
> Hello,
>
> I am trying to import a shapefile that contains polygons. Using v.in.ogr
with default settings works, but generates overlapping areas:
>
> ```
> v.in.ogr input=~/path/to/data/ output=soils_omafra
>
> ...
>
>
Hi Vero,
On Thu, May 16, 2019 at 3:11 AM Veronica Andreo
wrote:
>
> Dear all,
>
> thanks for the answers...
>
> @Madi, I know, but that's how I got the data from a colleague using
SaTScan to get cluster sizes.
>
> So, these "clusters" are 3, they are represented by circular areas and 2
of them
1 - 100 of 1346 matches
Mail list logo
