Re: [GRASS-user] v.select disjoint operation. Grass 7.8.2

[Markus Metz]

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 the input files file.json, file2.gpkg for debugging?

Best,

Markus M


On Thu, May 20, 2021 at 6:39 PM Christopher Lloyd via grass-user <
grass-user@lists.osgeo.org> wrote:

> Hi Markus, Thanks for your reply - sure. In current and previous
> successful runs of the disjoint operation in v.select I have input
> shapefile subsets of up to 2 GB in file size (file size just the shp file
> extension itself - not dbf etc.). Shapefiles of 2.5 GB size failed and had
> to be split. These correspond to 10,659,000 features and 12,159,000
> features respectively. I don't believe that the error is linked to any
> intrinsic limitation of the shapefile format as I also receive the same
> error when I input to Grass the (unsplit) polygon datasets in geojson or
> geopackage format.
>
> Best wishes, Chris
>
> On Thursday, 20 May 2021, 16:48:14 BST, Markus Neteler 
> wrote:
>
>
> Hi Chris,
>
> On Thu, May 20, 2021 at 2:00 PM Christopher Lloyd
>  wrote:
> >
> > Hi Markus, Having split my input data into smaller sized shp files,
> these now process fine using v.select. So clearly the problem that I had
> lies with some file size limitation with the v.select 'disjoint' algorithm
> - also failing with one input file prior using the v.extract algorithm. The
> original (large) input files input to grass ok using v.in.ogr,
>
> The vector limit is as follows:
>
>
> https://grasswiki.osgeo.org/wiki/GRASS_GIS_Performance#Large_vector_data_processing
> --> In all GRASS versions, the limit with topology is at time 2^31 - 1
> (about 2 billion) features per vector map.
>
>
> > but then failed when using v.select. Might you be able to indicate the
> file size limitation for the v.select algorithm and the reasons for this?
> Thanks.
>
>
> This said, perhaps v.select lacks a proper declaration?
>
> Could you tell us how many vector features per map you are dealing
> with (say: those which work and those which fail)?
>
> Best wishes, Markus
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] cog float32 export smaller scale missing tiles

[Markus Metz]

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 facing to a strange problem when exporting floating-point raster
> data into COG format using GDAL 3.2.1 and GRASS 7.8.5.
>
> Attempt to export raster data by `r.out.gdal format=COG` including
> color table fails from obvious reasons:
>
> ERROR 1: pm_filled_map.tif: Unable to export color table to GeoTIFF
> file.  Color tables can only be written to 1 band or 2 bands Byte or
> UInt16 GeoTIFF files.
>
> GDAL says:
>
> Band 1 Block=512x512 Type=Float32, ColorInterp=Palette
> Metadata:
> COLOR_TABLE_RULES_COUNT=3
> ...
>
> QGIS loads data with invalid symbology (which can be easily "fixed" by
> "Classify" button in the "Symbology" tab).
>
> So far understandable. Data exported with `-c` and `-m` flags leads to
> a grayscale color interpretation.
>
> Band 1 Block=512x512 Type=Float32, ColorInterp=Gray
>
> BUT after loading a COG file into QGIS no data is displayed! But if I
> zoom in, the data is magically shown! Originally I thought that it's
> caused by a broken symbology. But it seems that COG file does not have
> tiles for smaller scales (identify tool reports no-data for whole AOI
> on smaller scales). If I create a regular GeoTIFF file the problem
> with zooming disappears.
>
> Another strange thing is that COG file created without `-c` and `-m`
> flags do not have problems with zoom levels.
>
> Any idea what could be wrong?
>
> Thanks in advance! Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Raster gaussian filter

[Markus Metz]

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 Gaussian blur
of a raster data set. I am trying to smooth out and blur survey-related
artefacts in a swath multibeam dataset. I seem to remember in Grass 6.x
there was r.gauss, but I don’t see it anymore in Grass 7.8.x.
>
> Thanks,
>
> ~ Eric.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.stats.zonal output raster type

[Markus Metz]

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 accuracy to integer, you can do so by creating a
new map with r.mapcalc's function round() and delete the original output
afterwards.

Markus M

>
> Thanks
> Ming
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.net.allpairs - reduce number of calculations

[Markus Metz]

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 nodes on a river network, and it is working very well.
> However, for some datasets there are several thousand individual nodes
> and I would like to reduce the associated processing time if possible.
>
> Based on the documentation and the current outputs, the module
> calculates the shortest paths between all pairs of nodes on the network.
> In my case, I'm only interested in the shortest paths from one specific
> node. I'm therefore,  wondering if it is possible to use the module in
> this way and limit the shortest path calculations from one node to all
> of the other nodes on network. I tried to use the 'cats' and 'where'
> options, but so far to no avail.
>
> I appreciate I am overlooking something, but would value any feedback or
> advice on how to reduce the associated processing time.
>
> Thanks in advance.
>
> Regards
>
> Daniel.
>
> [1]: https://grass.osgeo.org/grass79/manuals/v.net.allpairs.html
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Error in compilation of GRASS GIS

[Markus Metz]

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 support copying text from terminal.

IIRC, there are menu entries in the MS Windows terminal to select, copy,
and paste text content.

Markus M

>
> Māris.
>
> 2021-01-19 20:41 GMT+02:00, Ashutosh Mitra :
> > Dear community members
> > While compiling GRASS on windows, I am getting an error.
> > [image: Screenshot 2021-01-18 145457.png]
> > I did the same as written in the error log that move to the directory
where
> > there is an error and run 'make'
> > [image: Screenshot 2021-01-18 151800.png]
> >
> > It says that :
> >
> > error while loading shared libraries: libgrass_raster.7.9.dll: cannot
open
> > shared object file: No such file or directory
> > --
> >
> > Thanks and Regards,
> >
> > *Ashutosh Mitra*
> >
> > (Teaching Assistant)
> >
> > Geoinformatics (CSRE)
> >
> > IIT Bombay, India.
> >
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] compare a DCELL and FCELL question

[Markus Metz]

A note about the usage of GRASS_EPSILON = 1.0e-15:

The range of single precision floating point is about 1.4012984643e−45 to
3.4028234664e38
That means for large numbers, using GRASS_EPSILON will also detect floating
point precision limits, not only meaningful differences. For small numbers,
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, 2021 at 5:06 PM ming han  wrote:
> >
> > Hi Everyone
> >
> >Many thanks for your help. Is if(fabs(map_A - map_B) <= 1.0e-15, ...
) approach may increase the runtime compare to '==' way?
>
> The formulas are very simple, I don't think that differences in runtime
can be reliably 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
"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 cat1_acc_riv = 1.1 and cat1_minacc = 1.9,
"float(cat1_acc_riv) == float(cat1_minacc)" becomes "1.1 == 1.9" whereas
"int(cat1_acc_riv) == int(cat1_minacc)" becomes "1 == 1", thus the results
are different.
> >>
> >> Another reason for possible differences is that float can only
represent max 7 decimal digits. E.g. float(194320567) becomes 194320560 but
int(194320567) preserves the value 194320567.
> >>
> >> Thus the safest is to cast everything to the type with the highest
precision. In this case with FCELL and DCELL, use "double(cat1_acc_riv) ==
double(cat1_minacc)" or even better the suggestion of Markus N.
> >>
> >> Markus M
> >>
> >>
> >> On Sun, Jan 24, 2021 at 3:51 PM ming han  wrote:
> >> >
> >> > Hi Markus and Micha
> >> >
> >> >  I am just trying to find grids have the same values in these
two rasters, I will try the threshold approach.
> >> >
> >> > Thanks
> >> > Ming
> >> >
> >> > Markus Neteler  于2021年1月24日周日 上午6:58写道：
> >> >>
> >> >> Hi Ming,
> >> >>
> >> >> On Sun, Jan 24, 2021 at 10:49 AM ming han 
wrote:
> >> >> >
> >> >> > Hi Micha
> >> >> >
> >> >> >  Many thanks for your reply.
> >> >> >  Here is the command I am using:
> >> >> >
> >> >> >  if(float(cat1_acc_riv) == float(cat1_minacc), str_r, null())
> >> >> >
> >> >> >   The str_r is a CELL raster. the result is different when I
change it to:
> >> >> >if(int(cat1_acc_riv) == int(cat1_minacc), str_r, null())
> >> >>
> >> >> Note that numerical "equality" is better tested with a threshold
test
> >> >> against the map pixel difference.
> >> >> As the threshold, we use GRASS_EPSILON which is defined as 1.0e-15.
> >> >>
> >> >> Hence the test needs to be implemented in a different way, i.e. by
> >> >> using an epsilon.
> >> >> Essentially something like this:
> >> >>
> >> >> if(fabs(map_A - map_B) <= 1.0e-15, ... )
> >> >>
> >> >> In your case (untested):
> >> >> r.mapcalc diffepsilon = if( abs( map_A - map_B) <= 1.0e-15, str_r ,
null())
> >> >>
> >> >> See related discussions here: [1], [2] and elsewhere.
> >> >>
> >> >> [1] Comment by Glynn:
https://trac.osgeo.org/grass/ticket/2854#comment:9
> >> >> [2] Comment by Glynn:
> >> >>
https://lists.osgeo.org/pipermail/grass-user/2015-October/073200.html
> >> >>
> >> >> Best,
> >> >> Markus
> >> >
> >> > ___
> >> > grass-dev mailing list
> >> > grass-...@lists.osgeo.org
> >> > https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] compare a DCELL and FCELL question

[Markus Metz]

On Sun, Jan 24, 2021 at 5:06 PM ming han  wrote:
>
> Hi Everyone
>
>Many thanks for your help. Is if(fabs(map_A - map_B) <= 1.0e-15, ... )
approach may increase the runtime compare to '==' way?

The formulas are very simple, I don't think that differences in runtime can
be reliably 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 "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 cat1_acc_riv = 1.1 and cat1_minacc = 1.9,
"float(cat1_acc_riv) == float(cat1_minacc)" becomes "1.1 == 1.9" whereas
"int(cat1_acc_riv) == int(cat1_minacc)" becomes "1 == 1", thus the results
are different.
>>
>> Another reason for possible differences is that float can only represent
max 7 decimal digits. E.g. float(194320567) becomes 194320560 but
int(194320567) preserves the value 194320567.
>>
>> Thus the safest is to cast everything to the type with the highest
precision. In this case with FCELL and DCELL, use "double(cat1_acc_riv) ==
double(cat1_minacc)" or even better the suggestion of Markus N.
>>
>> Markus M
>>
>>
>> On Sun, Jan 24, 2021 at 3:51 PM ming han  wrote:
>> >
>> > Hi Markus and Micha
>> >
>> >  I am just trying to find grids have the same values in these two
rasters, I will try the threshold approach.
>> >
>> > Thanks
>> > Ming
>> >
>> > Markus Neteler  于2021年1月24日周日 上午6:58写道：
>> >>
>> >> Hi Ming,
>> >>
>> >> On Sun, Jan 24, 2021 at 10:49 AM ming han  wrote:
>> >> >
>> >> > Hi Micha
>> >> >
>> >> >  Many thanks for your reply.
>> >> >  Here is the command I am using:
>> >> >
>> >> >  if(float(cat1_acc_riv) == float(cat1_minacc), str_r, null())
>> >> >
>> >> >   The str_r is a CELL raster. the result is different when I
change it to:
>> >> >if(int(cat1_acc_riv) == int(cat1_minacc), str_r, null())
>> >>
>> >> Note that numerical "equality" is better tested with a threshold test
>> >> against the map pixel difference.
>> >> As the threshold, we use GRASS_EPSILON which is defined as 1.0e-15.
>> >>
>> >> Hence the test needs to be implemented in a different way, i.e. by
>> >> using an epsilon.
>> >> Essentially something like this:
>> >>
>> >> if(fabs(map_A - map_B) <= 1.0e-15, ... )
>> >>
>> >> In your case (untested):
>> >> r.mapcalc diffepsilon = if( abs( map_A - map_B) <= 1.0e-15, str_r ,
null())
>> >>
>> >> See related discussions here: [1], [2] and elsewhere.
>> >>
>> >> [1] Comment by Glynn:
https://trac.osgeo.org/grass/ticket/2854#comment:9
>> >> [2] Comment by Glynn:
>> >> https://lists.osgeo.org/pipermail/grass-user/2015-October/073200.html
>> >>
>> >> Best,
>> >> Markus
>> >
>> > ___
>> > grass-dev mailing list
>> > grass-...@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] compare a DCELL and FCELL question

[Markus Metz]

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 cat1_acc_riv = 1.1 and cat1_minacc = 1.9,
"float(cat1_acc_riv) == float(cat1_minacc)" becomes "1.1 == 1.9" whereas
"int(cat1_acc_riv) == int(cat1_minacc)" becomes "1 == 1", thus the results
are different.

Another reason for possible differences is that float can only represent
max 7 decimal digits. E.g. float(194320567) becomes 194320560 but
int(194320567) preserves the value 194320567.

Thus the safest is to cast everything to the type with the highest
precision. In this case with FCELL and DCELL, use "double(cat1_acc_riv) ==
double(cat1_minacc)" or even better the suggestion of Markus N.

Markus M


On Sun, Jan 24, 2021 at 3:51 PM ming han  wrote:
>
> Hi Markus and Micha
>
>  I am just trying to find grids have the same values in these two
rasters, I will try the threshold approach.
>
> Thanks
> Ming
>
> Markus Neteler  于2021年1月24日周日 上午6:58写道：
>>
>> Hi Ming,
>>
>> On Sun, Jan 24, 2021 at 10:49 AM ming han  wrote:
>> >
>> > Hi Micha
>> >
>> >  Many thanks for your reply.
>> >  Here is the command I am using:
>> >
>> >  if(float(cat1_acc_riv) == float(cat1_minacc), str_r, null())
>> >
>> >   The str_r is a CELL raster. the result is different when I
change it to:
>> >if(int(cat1_acc_riv) == int(cat1_minacc), str_r, null())
>>
>> Note that numerical "equality" is better tested with a threshold test
>> against the map pixel difference.
>> As the threshold, we use GRASS_EPSILON which is defined as 1.0e-15.
>>
>> Hence the test needs to be implemented in a different way, i.e. by
>> using an epsilon.
>> Essentially something like this:
>>
>> if(fabs(map_A - map_B) <= 1.0e-15, ... )
>>
>> In your case (untested):
>> r.mapcalc diffepsilon = if( abs( map_A - map_B) <= 1.0e-15, str_r ,
null())
>>
>> See related discussions here: [1], [2] and elsewhere.
>>
>> [1] Comment by Glynn: https://trac.osgeo.org/grass/ticket/2854#comment:9
>> [2] Comment by Glynn:
>> https://lists.osgeo.org/pipermail/grass-user/2015-October/073200.html
>>
>> Best,
>> Markus
>
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Merge spatially connected features

[Markus Metz]

On Thu, Mar 12, 2020 at 12:34 PM Johannes Radinger <
johannesradin...@gmail.com> wrote:
>
> Thank you Markus,
> indeed your approach looks like what I need..The hint with
v.net.components was the part that I was missing;

Note that v.net.components does not need a network prepared 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:
>>
>> 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)
>>   identify connected lines (v.net + v.net.components)
>>   update a new attribute of the original lines with the comp attribute
of the output of v.net.components plus some offset to separate different
stream orders
>>
>> HTH,
>>
>> Markus M
>>
>>
>> On Tue, Mar 10, 2020 at 5:20 PM Johannes Radinger <
johannesradin...@gmail.com> wrote:
>> >
>> > So...no also with GRASS-user as recipient...
>> >
>> > On 05.03.20 16:21, Micha Silver wrote:
>> > >
>> > > On 3/5/20 10:47 AM, Johannes Radinger wrote:
>> > >>
>> > >> Hi Micha, hi all,
>> > >>
>> > >> sorry for my late response...however, just today I managed to try
>> > >> your approach of building polylines to connect "touching stream
>> > >> lines"...but...
>> > >>
>> > >> On 24.02.20 16:48, Micha Silver wrote:
>> > >>>
>> > >>> On 24/02/2020 10:45, Johannes Radinger wrote:
>> > >>>> Hi all,
>> > >>>> I have a large river network dataset (lines). Now I'd to assign
>> > >>>> unique categories to each group of connected lines that have an
>> > >>>> attribute in common.
>> > >>>>
>> > >>>> For example, my rivers are categorized based on some kind of
stream
>> > >>>> order. I want to group all rivers that belong to stream order 2
and
>> > >>>> are spatially connected; each group should get a unique category
>> > >>>> value. I thought that I could first extract all rivers with a
>> > >>>> particular attribute (e.g. stream order = 2) which will provide me
>> > >>>> some scattered pattern of lines. Then I need a spatial join tool
to
>> > >>>> make subgroups of lines that are connected. How can I achieve the
>> > >>>> latter? Any idea?
>> > >>>
>> > >
>> > >
>> > >>>
>> > >>> Here's a procedure that might work for you. Somewhat clunky, but I
>> > >>> think it gets what you want.
>> > >>>
>> > >>> It's based on the v.build.polylines module to connect all touching
>> > >>> stream reaches. First extract each order from the stream vector
into
>> > >>> a new vector. Then build polylines. Patch them all together. Now
you
>> > >>> have a polyline vector with a single cat value for each set of
>> > >>> original stream reaches that had the same order and that were
touching.
>> > >>
>> > >> Unfortunately, the v.build.polylines tool does not work as it only
>> > >> does not connect multiple (intersecting) lines like in a river
>> > >> network. As an example I tried to build polylines from the stream
>> > >> network of the NC dataset. Yous suggested approach should result
that
>> > >> each sub-network (i.e. river network that is not connected to
another
>> > >> one) should get its own ID/cat...however, v.build.polylines results
>> > >> in a connected stream network that consists of multiple cats:
>> > >>
>> > > Maybe I misunderstood your question. The steps I tried use a
>> > > stream_order column to group stream segments, then apply a new
>> > > attribute "merged_id" to those stream orders that touch. i.e. that
>> > > connect to the same confluence point.
>> > >
>> > >
>> > > Here's what I get using the nc_basic_spm mapset:
>> > >
>> > &g

Re: [GRASS-user] v.in.ogr layer name

[Markus Metz]

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 original; it is only the
output map and the associated table that gets a new name as defined by
'output'.
>
> When checking the connections of that map using v.db.connect:
> v.db.connect -p map=my_new_map@analysis2

> Vector map  is connected by:
> layer <1/Watercourse> table  in database
 through driver  with key 
>
> Is that the intended behavior of v.in.ogr that the layer name does not
get renamed based on the output parameter?

Not sure how much intention is in this behaviour, but the GRASS-internal
layer name is mostly informative. GRASS vector layers are usually addressed
by number, not by name. It is probably safe to ignore the layer name of
native GRASS vectors.

Markus M

>
> cheers,
> Johannes
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Merge spatially connected features

[Markus Metz]

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)
  identify connected lines (v.net + v.net.components)
  update a new attribute of the original lines with the comp attribute of
the output of v.net.components plus some offset to separate different
stream orders

HTH,

Markus M


On Tue, Mar 10, 2020 at 5:20 PM Johannes Radinger <
johannesradin...@gmail.com> wrote:
>
> So...no also with GRASS-user as recipient...
>
> On 05.03.20 16:21, Micha Silver wrote:
> >
> > On 3/5/20 10:47 AM, Johannes Radinger wrote:
> >>
> >> Hi Micha, hi all,
> >>
> >> sorry for my late response...however, just today I managed to try
> >> your approach of building polylines to connect "touching stream
> >> lines"...but...
> >>
> >> On 24.02.20 16:48, Micha Silver wrote:
> >>>
> >>> On 24/02/2020 10:45, Johannes Radinger wrote:
>  Hi all,
>  I have a large river network dataset (lines). Now I'd to assign
>  unique categories to each group of connected lines that have an
>  attribute in common.
> 
>  For example, my rivers are categorized based on some kind of stream
>  order. I want to group all rivers that belong to stream order 2 and
>  are spatially connected; each group should get a unique category
>  value. I thought that I could first extract all rivers with a
>  particular attribute (e.g. stream order = 2) which will provide me
>  some scattered pattern of lines. Then I need a spatial join tool to
>  make subgroups of lines that are connected. How can I achieve the
>  latter? Any idea?
> >>>
> >
> >
> >>>
> >>> Here's a procedure that might work for you. Somewhat clunky, but I
> >>> think it gets what you want.
> >>>
> >>> It's based on the v.build.polylines module to connect all touching
> >>> stream reaches. First extract each order from the stream vector into
> >>> a new vector. Then build polylines. Patch them all together. Now you
> >>> have a polyline vector with a single cat value for each set of
> >>> original stream reaches that had the same order and that were
touching.
> >>
> >> Unfortunately, the v.build.polylines tool does not work as it only
> >> does not connect multiple (intersecting) lines like in a river
> >> network. As an example I tried to build polylines from the stream
> >> network of the NC dataset. Yous suggested approach should result that
> >> each sub-network (i.e. river network that is not connected to another
> >> one) should get its own ID/cat...however, v.build.polylines results
> >> in a connected stream network that consists of multiple cats:
> >>
> > Maybe I misunderstood your question. The steps I tried use a
> > stream_order column to group stream segments, then apply a new
> > attribute "merged_id" to those stream orders that touch. i.e. that
> > connect to the same confluence point.
> >
> >
> > Here's what I get using the nc_basic_spm mapset:
> >
> >
> > r.watershed elev=elevation accum=nc_facc drain=nc_fdir bas=nc_bas
> > stream=nc_str thresh=1000
> > r.stream.order stream_rast=nc_str direct=nc_fdir elev=elevation
> > accum=nc_facc stream_vect=nc_streams
> > ORDERS=`v.db.select -c nc_streams group=strahler column=strahler`
> > echo $ORDERS
> >
> > # Create a new stream vector for each stream order
> >
> > for o in $ORDERS; do
> >
> > v.extract input=nc_streams output=streams_${o} where="strahler=${o}"
> >
> > # Give each polyline it's own cat value
> >
> > v.build.polylines input=streams_${o} output=streams_${o}_polyline
> > type=line cat=first
> >
> > done
> >
> >
> > # patch the stream orders back together
> >
> > POLYLINES=`g.list vect pattern="streams*polyline" separator=comma`
> >
> > v.patch input=$POLYLINES output=streams_polylines
> >
> > v.db.addcolumn map=streams column="merged_id INTEGER"
> >
> >
> > # And use v.distance to update that merged_id column from cat values
> > in polylines vector
> > v.distance from=streams to=streams_polylines upload=cat column=merged_id
> > v.db.addcolumn map=nc_streams column="merged_id INTEGER"
> > v.distance from=nc_streams to=streams_polylines upload=cat
> > column=merged_id
> >
> > Now, all stream reaches that have the same order and are "touching"
> > have the same merged_id. See the attached image.
> >
> >
> > If that's not your purpose, then just ignore...
> >
> Micha thank you for your help and of course, you're fully correct!
> Merging lines that belong to the same stream order works in this case
> well...but this is because of the definition of the Strahler ordering
> system, where there is only one "touching node" (i.e. river junction) of
> two rivers of the same stream order (i.e. when two 2nd order streams
> meet, the become a 3rd order stream). Thus your solution works because
> of this specifics and might not work if streams 

Re: [GRASS-user] Splitting lines by other lines that overlap

[Markus Metz]

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 overlapping. However, the full
stream network consists of polylines with start/end nodes that do not
correspond to the impoundments vector:
>
> LV1 (complete network):
> +---+--+
> LV2 (subset with different start/end nodes)
>  +---+   +-+
>
> So how can I get the information of impoundments (LV2) into the attribute
table of the first line vector (LV1). A way that came into my mind but
which is somehow cumbersome:
>
> 1) Extract the start/end node coordinates each impoundment (LV2) using
v.to.db
> 2) Use these coordinates in v.edit to break the river network (LV1)
> 3) Add new categories in layer 2 of LV1 and add an attribute table
> 4) Use v.distance to query the information from LV2 and copy it to the
corresponding new reaches in LV1
> ..This is not yet tested and not the most straight forward way.
>
> All this I guess would be easier if there would be something like
v.overlay that works with two line vectors...

The only alternative I can think of is v.clean tool=break errors=nodes, but
this might not be exactly what you need: start/end nodes from LV2 might be
missing if there are matching nodes in LV1. Your approach seems to be
reasonable, even if it involves several steps.

Markus M

>
> Has anybody done similar analysis in GRASS so far?
>
> cheers,
> Johannes
>
> tart/end nodes of the
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Can I turn off compression

[Markus Metz]

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.

That's what I do too to find out disk usage of a GRASS raster map.

> A better report would include a scatter plot of time v. size, but I only
cared about time.
>
> Summary: Use LZ4 compression within GRASS.

Only if you don't care about disk space and if IO speed does not matter.
Particularly when sharing or archiving data, other compression methods
reducing disk space are more suitable.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Can I turn off compression

[Markus Metz]

Hi Ken,

turning off compression for all newly generated maps is indeed not
supported. If you don't care about disk usage and disk speed but processing
time, LZ4 is the compression method of choice. LZ4 compresses in near-real
time, i. e. in GRASS GIS there is no measurable CPU speed penalty, only
increased disk IO because more data need to be written and subsequently
read. I am using LZ4 myself as raster compression in workflows for
temporary intermediate maps and change the raster compression method before
writing out final results.

Currently, the default GRASS raster compression method can only be changed
with the environment variable GRASS_COMPRESSOR.

Markus M

On Sun, Mar 1, 2020 at 4:21 AM Vaclav Petras  wrote:
>
> Hi Ken,
>
> That sounds like a good experiment and I think there would be general
interest in what you find. However, please note that less compression 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 list.
>
> Best,
> Vaclav
>
> On Sat, Feb 29, 2020 at 11:40 AM Ken Mankoff  wrote:
>>
>>
>> Hm. Answer: No
>>
>> I just did:
>>
>> export GRASS_COMPRESSOR=none
>>
>> And then get this error message:
>>
>> WARNING: No compression is not supported for GRASS raster maps, using
default ZLIB
>>
>> Seems like a shame to not have this as an option. I'll try speeding it
up by tweaking the compression method and amount.
>>
>>   -k.
>>
>> On 2020-02-29 at 08:37 -08, Ken Mankoff  wrote...
>> > Hi,
>> >
>> > I'd like to turn off compression for all maps. Is this possible with
>> > g.gisenv or environment variables? The g.gisenv manual only shows how
>> > to choose among compression methods, not disable it.
>> >
>> > This does not seem to work:
>> >
>> > g.gisenv set="GRASS_COMPRESSOR=none" # optimize for speed
>> >
>> > I can decompress one map with:
>> >
>> > r.compress -u map=foo
>> >
>> > But I'm trying to skip the time spent compressing and decompressing
>> > altogether. I could use a small speed boost, and this seems like an
>> > easy way to speed things up - I can afford the disk space for all the
>> > temporary intermediate maps.
>> >
>> > Thanks,
>> >
>> >   -k.
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Error in installing r.in.nasadem

[Markus Metz]

On Tue, Feb 25, 2020 at 1:12 AM Firman Hadi  wrote:
>
> Hi Markus,
>
> Thanks for sending me the information.
>
> I have tried it again but still no r.in.nasadem binary in the repo.
> Now, I am using GRASS GIS 7.6dev on a Mac. I could install the add-on
after creating symbolic link of Pyhton3.
>
> But there is another problem. It failed to download the data with the
error message KeyError = 'version' as attached. Any suggestion on how to
solve the problem?

I think this is a problem of mixing python 2 and python 3. I have adjusted
r.in.nasadem to work also with 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 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 server has not updated yet the addons
from github.
>
>
> According to the timestamps in
> http://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.8.2/
>
> the job will run in 2 hs from now.
>
> Please try then again.
>
> best,
>
> markusN
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Error in installing r.in.nasadem

[Markus Metz]

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 server has not updated yet the addons from
github.
>
> Is there any way to modify the add-on installer to download the file from
specific website?
Not for Windows AFAIK.

Markus M

>
> Thank you.
>
> Best regards,
>
> Firman Hadi.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] NASADEM: new global 1 arcsec DEM

[Markus Metz]

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
coverage as well as providing additional SRTM radar-related data products.
The improvements were achieved by reprocessing the original SRTM radar
signal data and telemetry data with updated algorithms and auxiliary data
not available at the time of the original SRTM processing."

All layers of the NASADEM_HGT.001 product can be imported into GRASS with
the addon r.in.nasadem:
https://github.com/OSGeo/grass-addons/tree/master/grass7/raster/r.in.nasadem

Enjoy!

Markus M

https://lpdaac.usgs.gov/products/nasadem_hgtv001/
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Importing Point-Cloud with v.in.lidar

[Markus Metz]

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 clouds lasinfo or
pdal info.

If you want to import geodata to GRASS GIS, the safest way is to first
create a GRASS location using the CRS of the input data. The CRS of the
input data can be obtained with the appropriate *info tool. Then you can
import the data. If import does not succeed, the error messages should
explain why import failed.

For regular raster or vector geodata recognized by GDAL/OGR, using GRASS
GIS via QGIS should work. But point clouds are not always recognized by OGR
and not as easy to handle, in which case you need to use other tools than
OGR. It also depends on what you want to do with these point clouds.

Markus M


On Wed, Feb 12, 2020 at 5:30 PM 
wrote:

>
> Hello grass-community,
>
> Actually I’m working for a research project (master thesis) with point
> data, that were exported from dronedeploy one year ago.
> Unfortunately processing the exported LAS-files is quit challenging,
> as there are some issues with the file format (e.g. the projection).
> My aim is to import the data into Grass-GIS to process it there with
> the 3D-fragmentation tool. But till now I was not able to import it…
> So I thought I’ll ask for some help here.
>
> I tried to process the data with several tools, like lidR package in
> R-Studio and LAStools. First I had to change the projection with
> las2las to a appropriate (EPSG 3116) one, to be able to display it
> correctly in these tools. Now I can do further processing with the
> data, like creating grids. By the way, these grids are located
> correctly when loading them to a GIS-application. So coordinates seem
> to be correctly. Anyway loading the point-data to Grass-GIS (with
> v.in.lidar tool) fails, because the points are in a wrong
> location/projection. I did not use -r (limit to current region), so
> this can not be the problem. First it did calculate something and
> added a vector map that seemed to be empty, because there was nothing
> displayed.
> Actually it doesn’t even start calculating and there is no vector map
> produced. I copied the output below. I already got the hint to try
> importing a ASCII text by converting the LAS file with PDAL. So I will
> try installing PDAL on my PC. Anyway, maybe some has a solution for
> the v.in.lidar problem.
>
> Output:
> QGIS version: 3.10.2-A Coruña
> QGIS code revision: d4cd3cfe5a
> Qt version: 5.11.2
> GDAL version: 3.0.4
> GEOS version: 3.8.0-CAPI-1.13.1
> PROJ version: Rel. 6.3.0, January 1st, 2020
> Processing algorithm…
> Algorithm 'v.in.lidar' starting…
> Input parameters:
> { '-b' : False, '-c' : False, '-t' : False,
> 'GRASS_OUTPUT_TYPE_PARAMETER' : 0, 'GRASS_REGION_PARAMETER' :
> '1209933.8649246846,1210526.7738715957,820900.5310786865,821470.5180333158
>
> [EPSG:3116]', 'GRASS_VECTOR_DSCO' : '', 'GRASS_VECTOR_EXPORT_NOCAT' :
> True, 'GRASS_VECTOR_LCO' : '', 'class_filter' : '', 'input' :
> 'C:\\Users\\oc\\OneDrive - HH
> Gruppe\\Dokumente\\Uni\\Master\\Daten\\Daten_Stuktur\\points\\110_1.las',
> 'limit' : None, 'offset' : None, 'output' : 'TEMPORARY_OUTPUT',
> 'preserve' : None, 'return_filter' : [], 'skip' : None, 'spatial' :
> None, 'zrange' : [nan,nan] }
>
> g.proj -c proj4="+proj=tmerc +lat_0=4.5962004167
> +lon_0=-74.077507917 +k=1 +x_0=100 +y_0=100 +ellps=GRS80
> +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"
> g.region n=821470.5180333158 s=820900.5310786865 e=1210526.7738715957
> w=1209933.8649246846
> v.in.lidar -o input="C:\Users\oc\OneDrive - HH
> Gruppe\Dokumente\Uni\Master\Daten\Daten_Stuktur\points\110_1.las"
> output=output2221d86f3dd44a7c84ead4bac980f243 --overwrite
> v.out.ogr type="auto" input="output2221d86f3dd44a7c84ead4bac980f243"
> output="C:\Users\oc\AppData\Local\Temp\processing_073544cf878b4dd8b5311a6a5d27abcc\cc8523d5d751483b9922084e16845571\output.gpkg"
> format="GPKG" -c
> --overwrite
> Starting GRASS GIS...
> WARNING: Concurrent mapset locking is not supported on Windows
> Cleaning up temporary files...
> Executing
> 
>
> ...
> C:\Users\oc\OneDrive - HH Gruppe\Dokumente>chcp 1252 1>NUL
> C:\Users\oc\OneDrive - HH Gruppe\Dokumente>g.proj -c
> proj4="+proj=tmerc +lat_0=4.5962004167 +lon_0=-74.077507917
> +k=1 +x_0=100 +y_0=100 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0
> +units=m +no_defs"
> Default region was updated to the new projection, but if you have
> multiple mapsets `g.region -d` should be run in each to update the
> region from the default
> Projection information updated
> C:\Users\oc\OneDrive - HH Gruppe\Dokumente>g.region
> n=821470.5180333158 s=820900.5310786865 e=1210526.7738715957
> w=1209933.8649246846
> C:\Users\oc\OneDrive - HH Gruppe\Dokumente>v.in.lidar -o
> input="C:\Users\oc\OneDrive - HH
> 

Re: [GRASS-user] Configure error: liblas not found

[Markus Metz]

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 seems to be the
cause:
>
> configure:7007: gcc -o conftest -g -O2  -O2 -fPIC  -I/usr/include
> -I/usr/include -I/usr/include -I/usr/include -I/usr/include
> -Wl,--export-dynamic  -L/usr/lib64 conftest.c  -L/usr/lib -llas -llas_c
> -L/usr/lib64 /usr/lib64/libboost_program_options.so
> /usr/lib64/libboost_thread.so /usr/lib64/libgdal.so
> /usr/lib64/libgeotiff.so /usr/lib64/libtiff.so /usr/lib64/liblaszip.so
1>&5
>
/usr/lib64/gcc/x86_64-slackware-linux/5.5.0/../../../../x86_64-slackware-linux/bin/ld:
> warning: libgeotiff.so.2, needed by /usr/lib64/liblas.so, not found (try
>   ^^^
> Installed here is libgeotiff-1.5.1 and /usr/lib64/libgeotiff.so.5

You need to update liblas, i.e. rebuild it against the libgeotiff version
currently on your system
>
>
/usr/lib64/gcc/x86_64-slackware-linux/5.5.0/../../../../x86_64-slackware-linux/bin/ld:
> warning: libgdal.so.20, needed by /usr/lib64/liblas.so, not found (try
>   ^
> Installed here is gdal-3.0.2 and /usr/lib64/libgdal.so.26.

this might not work, liblas is no longer maintained, not sure if it can be
compiled against GDAL 3. In the worst case, it can be compiled against GDAL
3, but produce strange errors
>
> libLAS is looking for those specific versions of libgeotiff and libgdal.
> Where do I make grass aware of the newer versions of these libraries?

you need to make liblas aware of newer versions of these libraries, not
grass.

Markus M

>
> Thanks,
>
> Rich
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Configure error: liblas not found

[Markus Metz]

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@
> > /usr/lib64/liblas_c.so@
> > /usr/lib64/liblas_c.so.2.4.0*
> > /usr/lib64/liblas_c.so.3@
>
> I added to the configuation file
> --with-liblas-lib=/usr/lib64/
> and the configuration step fails at the same point

have a look at the end of config.log, there should be more details about
the error.

Markus M

>
> > Please advise me how to fix this configuration error.
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Failure to compile GRASS GIS 7.8 with Proj 6 and GDAL 3

[Markus Metz]

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:
> >/osgeo/grass/general/g.proj
> >/osgeo/grass/general/g.region
> >/osgeo/grass/raster/r.horizon
> >/osgeo/grass/raster/r.sun
> >/osgeo/grass/raster3d/r3.out.netcdf
> >
> >```
>
> Fixed, I had to remove left-over files from previous PROJ
> installation(s).
>
> (...why is there no `make uninstall` for PROJ, GEOS, etc.?)

if you compile from source, it is mostly your responsibility to clean up
old installations. Generally, cleaning up should happen in
${prefix}/lib[64]
${prefix}/include
${prefix}/share

regarding PROJ, cleaning up ${prefix}/share with the proj.db and grids is
quite important because PROJ is evolving fast and any leftovers from a
previous installation might confuse software compiled against PROJ.

Regarding GDAL compilation against PROJ, there was in GDAL 2 the configure
option
--with-static-proj4=ARG Compile with PROJ.4 statically (deprecated, use
--with-proj instead) (ARG=no or path)
in GDAL 3 there is only
--with-proj=ARG Compile with PROJ.x (ARG=yes or path)

This static proj linking in GDAL does not mean to link against a static
PROJ library, but to statically link against a given dynamic PROJ library,
i.e. the same PROJ library used at compile time will also be used at run
time. This is important to make sure that GDAL is not suddenly picking a
different PROJ library at run time when a new PROJ library becomes
available.

I ran in all these problems myself when adding support for PROJ 4, 5, and 6
in GRASS.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Failure to compile GRASS GIS 7.8 with Proj 6 and GDAL 3

[Markus Metz]

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 major
releases are usually full of bugs.

Markus M

> ```
> +
> ```
> geos-config --version
> 3.7.0
> ```
> +
> ```
> gdal-config --version
> 3.0.4
> ```
> +
> ```
> make distclean
> ./configure --with-freetype=yes
--with-freetype-includes="/usr/include/freetype2/" --with-readline
--with-geos
> make
> ```
>
> The `error.log` here: https://pastebin.com/rEgMmcPT
> Running make from inside few directories with error(s):
https://pastebin.com/PisKVBHP
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error in i.sentinel.mask: nan values in xml file

[Markus Metz]

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 different problem now.
[...]
>
> --- Start computing the east and north clouds shift at steps of 100m of
> clouds height---
> Traceback (most recent call last):
>   File "/home/veroandreo/.grass7/addons/scripts/i.sentinel.mask", line
638, in 
> main()
>   File "/home/veroandreo/.grass7/addons/scripts/i.sentinel.mask", line
561, in main
> quiet=True, stderr=subprocess.DEVNULL)

stderr=subprocess.DEVNULL means that stderr output is discarded, thus no
error output.


>   File
"/home/veroandreo/software/grass79-dev/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 499, in run_command
> return handle_errors(returncode, result=None, args=args,
kwargs=kwargs)
>   File
"/home/veroandreo/software/grass79-dev/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 392, in handle_errors
> returncode=returncode)
> grass.exceptions.CalledModuleError: Module run v.overlay v.overlay --o
--q ainput=addcat_5922 binput=cl_shift_5922 operator=and
output=overlay_5922 ended with error
> Process ended with non-zero return code 1. See errors in the (error)
output.
>
> Where is this error output to inspect?

disappeared in /dev/null

Markus M
>
> This is the UUID in case you want to test:
541021f8-63f5-4e9d-ba28-425c4c8451df
>
> Thanks much in advance
> Vero
>
> ps: I use grass-dev with python 3.7.4 (because of the ctypes issue)
>
>
>
> El mié., 29 ene. 2020 a las 14:53, Veronica Andreo ()
escribió:
>>
>> Hi Robi,
>>
>> My bad, region was wrong... anyway, trying to replicate from the
beginning I see that i.sentinel.import with -r is importing empty maps.
However, the jp2 files have data. I can visualize them in QGIS. I'll report
in a different thread. Once I can figure it out and reach this point again,
I'll report back to you. Thanks for the clarification!
>>
>> Cheers
>> Vero
>>
>> El mié., 29 ene. 2020 a las 9:08, roberta fagandini (<
robifagand...@hotmail.it>) escribió:
>>>
>>> Hi Vero,
>>> i.sentinel.mask doesn't retrieve the maximum from the xml file but
computes the value from the image using r.univar. The error could be due to
the computational region..has the region been set correctly?
>>> Can you send the MTD_TL.xml file? I can download the image and make
some tests.
>>>
>>> Roberta
>>>
>>> 
>>> Da: grass-user  per conto di
Veronica Andreo 
>>> Inviato: martedì 28 gennaio 2020 19:57
>>> A: grass-user 
>>> Oggetto: [GRASS-user] error in i.sentinel.mask: nan values in xml file
>>>
>>> Hello
>>>
>>> I try to use i.sentinel.mask but I get the following error:
>>>
>>> i.sentinel.mask blue=$blue green=$green red=$red swir11=$swir11
nir=$nir swir12=$swir12 nir8a=$nir8a cloud_mask=cloud shadow_mask=shadow
mtd_file=`find $out_dir -name 'MTD_TL.xml'`
>>>
>>> ADVERTENCIA: All subsequent operations will be limited to the current
>>>  computational region
>>> ADVERTENCIA: Any rescale factor has been applied
>>> --- Start computing maximum values of bands ---
>>> T21JYM_20200126T134201_B02_10m
>>> T21JYM_20200126T134201_B03_10m
>>> T21JYM_20200126T134201_B04_10m
>>> T21JYM_20200126T134201_B08_10m
>>> T21JYM_20200126T134201_B8A_20m
>>> T21JYM_20200126T134201_B11_20m
>>> T21JYM_20200126T134201_B12_20m
>>> --- Computed maximum value: dict_values([nan, nan, nan, nan, nan, nan,
>>> nan]) ---
>>> --- Statistics have been computed! ---
>>> --- Start clouds detection procedure ---
>>> --- Computing cloud mask... ---
>>> Mapa no válido 
>>> Parse error
>>> ERROR: error al parsear
>>> ERROR: An error occurred while running r.mapcalc with expression:
>>>cloud_def82115 = ifT21JYM_20200126T134201_B02_10m >
(0.08*nan))
>>>&& (T21JYM_20200126T134201_B03_10m > (0.08*nan)) &&
>>>(T21JYM_20200126T134201_B04_10m > (0.08*nan))) == 1) &&
>>>(((T21JYM_20200126T134201_B04_10m < ((0.08*nan)*1.5)) &&
>>>(T21JYM_20200126T134201_B04_10m >
>>>T21JYM_20200126T134201_B12_20m*1.3)) == 0) &&
>>>(((T21JYM_20200126T134201_B11_20m < (0.1*nan)) &&
>>>(T21JYM_20200126T134201_B12_20m < (0.1*nan))) == 0) &&
>>>((if(T21JYM_20200126T134201_B8A_20m ==
>>>max(T21JYM_20200126T134201_B8A_20m, 2 *
>>>T21JYM_20200126T134201_B02_10m, 2 *
T21JYM_20200126T134201_B03_10m,
>>>2 * T21JYM_20200126T134201_B04_10m))) == 0) &&
>>>((T21JYM_20200126T134201_B02_10m > 0.2) == 1), 0, null())
>>>
>>> I checked the xml file and there are a lot of nan's yes, but there are
also real values. Why doesn't the max function in this part:
https://github.com/OSGeo/grass-addons/blob/master/grass7/imagery/i.sentinel/i.sentinel.mask/i.sentinel.mask.py#L321
recognize them? Isn't there a way to avoid nan while computing max?
>>>

Re: [GRASS-user] Running r.topix hangs up

[Markus Metz]

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 following information will also help to solve the problem:
What is the size of the input file in terms of rows and columns, what is
the current region, which operating system and how much free RAM on this
operating system?

Alternatively, you can also use the tci output of r.watershed.

Markus M

> (Using 7.8.1.dev or 7.6.1 or from GRASS modules in QGIS)
>
> Cumprimentos,
> Valter Albino - Geógrafo Físico, M.Sc.
> Modelação H / Riscos ambientais / OT
> www.valteralbino.wixsite.com/hydrodynamics
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.proj ERROR

[Markus Metz]

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 open element file <> for 
>
> What does that mean?

This is a bug in r.proj: the mapset dachstein does not exist in the source
location, therefore also no WIND file in the mapset dachstein because this
mapset does not exist. The new PR #286
https://github.com/OSGeo/grass/pull/286 fixes this bug, but it exposes
another bug in r.import.

Markus M

>
> the pojection and region settings of both input and output are als
follows:
>
> g.proj -p
> -PROJ_INFO-
> name   : Lambert Conformal Conic
> proj   : lcc
> datum  : hermannskogel
> ellps  : bessel
> lat_1  : 49
> lat_2  : 46
> lat_0  : 47.5
> lon_0  : 13.33
> x_0: 40
> y_0: 40
> no_defs: defined
> towgs84: 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232
> -PROJ_UNITS
> unit   : metre
> units  : metres
> meters : 1
>
>
--
>
>
> g.region -p
> projection: 99 (Lambert Conformal Conic)
> zone:   0
> datum:  hermannskogel
> ellipsoid:  bessel
> north:  576922.51207363
> south:  273692.51207363
> west:   106549.26720377
> east:   694629.26720377
> nsres:  10
> ewres:  10
> rows:   30323
> cols:   58808
> cells:  1783234984
>
> 
>
> g.proj -p
> -PROJ_INFO-
> name   : Universal Transverse Mercator
> proj   : utm
> datum  : etrs89
> ellps  : grs80
> zone   : 33
> towgs84: 0,0,0,0,0,0,0
> no_defs: defined
> -PROJ_UNITS
> unit   : metre
> units  : metres
> meters : 1
>
>
--
>
>
> g.region -p
> projection: 1 (UTM)
> zone:   33
> datum:  etrs89
> ellipsoid:  grs80
> north:  5286581.58847414
> south:  5248335.67358037
> west:   380870.53610518
> east:   429633.13185005
> nsres:  9.998932
> ewres:  10.00053235
> rows:   3825
> cols:   4876
> cells:  18650700
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.flow

[Markus Metz]

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 flow lines

can you provide an example with input data where it does not work?

Markus M

>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.proj ERROR

[Markus Metz]

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
> >
> > r.proj -g location=MGI2wgs84_Austria_Lambert mapset=PERMANENT
> > input=dhm_10m_ogd_austria output=dhm_10m_ogd_dachstein_NEU
> > method=bilinear resolution=10 pipeline=+proj=pipeline  +step +inv
> > +proj=lcc +lat_0=47.5 +lon_0=13.3 +lat_1=49 +lat_2=46
> > +x_0=40 +y_0=40 +ellps=bessel +step +proj=hgridshift
> > +grids=AT_GIS_GRID.gsb +step +proj=utm +zone=33 +ellps=GRS80
> > n=1.#INF s=5132938.26037436 w=78264.72048991 e=1.#INF rows=30323
> > cols=58808
> > Eingabekarte dhm_10m_ogd_austria@PERMANENT in Location
> > 
> > :
> > (Mon Jan 13 10:19:18 2020) Befehl ausgeführt (0 Sek)
> >
> > But nothing happend!

Nik, have you set the current region correctly?

>
> for r.proj -g you don't need the pipeline, try just
>
> r.proj -g  location=MGI2wgs84_Austria_Lambert mapset=PERMANENT
> input=dhm_10m_ogd_austria
>
> see also example https://grass.osgeo.org/grass78/manuals/r.proj.html
>
> ---
> # same calculation, but in a form which can be cut and pasted into a
> g.region call
> r.proj input=elevation location=ll_wgs84 mapset=user1 -g
> ---
>
> the pipeline is needed later for the reprojection process.

A pipeline is not really needed, in case of several possible operations,
PROJ should automagically select the best available operation. Note that
also with r.proj -g coordinate transformation takes place.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error compiling grass 7.8.2 on centos 7

[Markus Metz]

On Fri, Dec 20, 2019 at 12:03 PM Laura Poggio 
wrote:
>
> Dear all,
> I managed to remove the error by specifying --without-zstd.

is it possible that your custom path to zstd libs
/home/user/grass/zstd/zstd-1.4.0/lib
is not in LD_LIBRARY_PATH?

That would explain it.

Markus M
>
> Thanks a lot!
> Laura
>
> On Fri, 20 Dec 2019 at 10:48, Laura Poggio  wrote:
>>
>> Dear Markus,
>> the path to the GRASS source (the directory where I compile) is
>> /home/user/grass/grass-7.8.2/
>>
>> I get the same when I try to compile with -prefix=/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,
>>> > 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 cause errors when running "make install". In this
case, prefix must be set to another location, e.g. /home/user/local if you
do not want or can not use the default /usr/local.
>>>
>>> Just a guess,
>>>
>>> Markus M
>>>
>>> > --enable-64bit
--with-fftw-includes=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/include/ \
>>> > --with-fftw-libs=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/lib/ \
>>> >
--with-freetype-includes=/home/user/grass/freetypes/freetype-2.9.1/include/
\
>>> > --with-netcdf --with-geos --with-blas --with-lapack --with-postgres \
>>> > --with-zstd-libs=/home/user/grass/zstd/zstd-1.4.0/lib/ \
>>> > --with-zstd-includes=/home/user/grass/zstd/zstd-1.4.0/lib/
>>> >
>>> > The freetype and zstd are in my home because they are not available
on the cluster, so I had to create them locally.
>>> > If I may, I add an additional question: which is the right option in
configure to point to a specific version of proj? --with-proj-libs?
>>> >
>>> > Thanks a lot
>>> >
>>> > Laura
>>> >
>>> >
>>> >
>>> > On Thu, 19 Dec 2019 at 23:36, Markus Neteler 
wrote:
>>> >>
>>> >> On Thu, Dec 19, 2019 at 8:12 AM Laura Poggio 
wrote:
>>> >> >
>>> >> > Dear list,
>>> >> > I am trying to compile grass 7.8.2 on an HPC cluster using centos
7 as operative system. I can not install binaries.
>>> >>
>>> >> Just to understand: for policy reasons?
>>> >>
>>> >> > I need to compile from source.
>>> >> >
>>> >> > The python version I am using is Python 3.7.4
>>> >> >
>>> >> > The configure and the make are working fine.
>>> >>
>>> >> Importantly, pls post your "configure" command to better understand
>>> >> the error below:
>>> >>
>>> >> > However I get the following errors at the make install stage:
>>> >> >
>>> >> > rm /home/user/grass//grass78/etc/fontcap
>>> >> > rm: cannot remove ‘/home/user/grass//grass78/etc/fontcap’: No such
file or directory
>>> >> > make[1]: [real-install] Error 1 (ignored)
>>> >> > make /home/user/grass//grass78/etc/fontcap
>>> >> > make[2]: Entering directory `/home/user/grass/grass-7.8.2'
>>> >> > make[2]: *** No rule to make target
`/home/user/grass/grass-7.8.2/dist.x86_64-pc-linux-gnu/etc/fontcap', needed
by `/home/user/grass//grass78/etc/fontcap'.  Stop.
>>> >> > make[2]: Leaving directory `/home/user/grass/grass-7.8.2'
>>> >> > make[1]: *** [real-install] Error 2
>>> >> > make[1]: Leaving directory `/home/user/grass/grass-7.8.2'
>>> >> > make: *** [install] Error 2
>>> >> >
>>> >> > Am I missing some dependencies in the fonts?
>>> >>
>>> >> ... probably in the configure step.
>>> >>
>>> >> > Is the python version ok or should I use a slightly older 3.x one?
>>> >>
>>> >> That should be fine.
>>> >>
>>> >> > are there any recommendations for the gcc version to use?
>>> >>
>>> >> No special recommendations.
>>> >>
>>> >> Best wishes
>>> >> Markus
>>> >
>>> > ___
>>> > grass-user mailing list
>>> > grass-user@lists.osgeo.org
>>> > https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error compiling grass 7.8.2 on centos 7

[Markus Metz]

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 cause errors when running "make install". In this case,
prefix must be set to another location, e.g. /home/user/local if you do not
want or can not use the default /usr/local.

Just a guess,

Markus M

> --enable-64bit
--with-fftw-includes=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/include/ \
> --with-fftw-libs=/cm/shared/apps/fftw/openmpi/gcc/64/3.3.7/lib/ \
>
--with-freetype-includes=/home/user/grass/freetypes/freetype-2.9.1/include/
\
> --with-netcdf --with-geos --with-blas --with-lapack --with-postgres \
> --with-zstd-libs=/home/user/grass/zstd/zstd-1.4.0/lib/ \
> --with-zstd-includes=/home/user/grass/zstd/zstd-1.4.0/lib/
>
> The freetype and zstd are in my home because they are not available on
the cluster, so I had to create them locally.
> If I may, I add an additional question: which is the right option in
configure to point to a specific version of proj? --with-proj-libs?
>
> Thanks a lot
>
> Laura
>
>
>
> On Thu, 19 Dec 2019 at 23:36, Markus Neteler  wrote:
>>
>> On Thu, Dec 19, 2019 at 8:12 AM Laura Poggio 
wrote:
>> >
>> > Dear list,
>> > I am trying to compile grass 7.8.2 on an HPC cluster using centos 7 as
operative system. I can not install binaries.
>>
>> Just to understand: for policy reasons?
>>
>> > I need to compile from source.
>> >
>> > The python version I am using is Python 3.7.4
>> >
>> > The configure and the make are working fine.
>>
>> Importantly, pls post your "configure" command to better understand
>> the error below:
>>
>> > However I get the following errors at the make install stage:
>> >
>> > rm /home/user/grass//grass78/etc/fontcap
>> > rm: cannot remove ‘/home/user/grass//grass78/etc/fontcap’: No such
file or directory
>> > make[1]: [real-install] Error 1 (ignored)
>> > make /home/user/grass//grass78/etc/fontcap
>> > make[2]: Entering directory `/home/user/grass/grass-7.8.2'
>> > make[2]: *** No rule to make target
`/home/user/grass/grass-7.8.2/dist.x86_64-pc-linux-gnu/etc/fontcap', needed
by `/home/user/grass//grass78/etc/fontcap'.  Stop.
>> > make[2]: Leaving directory `/home/user/grass/grass-7.8.2'
>> > make[1]: *** [real-install] Error 2
>> > make[1]: Leaving directory `/home/user/grass/grass-7.8.2'
>> > make: *** [install] Error 2
>> >
>> > Am I missing some dependencies in the fonts?
>>
>> ... probably in the configure step.
>>
>> > Is the python version ok or should I use a slightly older 3.x one?
>>
>> That should be fine.
>>
>> > are there any recommendations for the gcc version to use?
>>
>> No special recommendations.
>>
>> Best wishes
>> Markus
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] S.K. Jenson and J.O. Domingue (1988) method to filter the elevation map

[Markus Metz]

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 Sul, in Porto Alegre, Brazil]  which gives us
> three options as methods to remove depressions, namely:
> Heuristic Search (HS), Priority First Search (PFS) and Modified Heuristic
> Search (MHS).
> Do you know if GRASS uses one of theses methods?

I can't tell yet, but the search methods of the IPH-Hydro Tools could be
similar to what r.watershed/r.stream.extract/r.hydrodem use.
>
> As for my previous question:
> I read in Grass manual:
> "r.fill.dir filters and generates a depressionless elevation map and a
flow
> direction map from a given raster elevation map. The method adopted to
> filter the elevation map and rectify it is based on the paper titled
> "Extracting topographic structure from digital elevation model data for
> geographic information system analysis" by S.K. Jenson and J.O. Domingue
> (1988)."
> I just want to know if indeed r.fill.dir function still operates precisely
> in the same methodology described in the mentioned paper. I am asking
> specifically about r.fill.dir, no r.watershed or other funcion.

The manual of r.fill.dir is correct.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] S.K. Jenson and J.O. Domingue (1988) method to filter the elevation map

[Markus Metz]

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 there
> wasn't any improvement in Grass method.

r.watershed, available in GRASS since the late 1980's, uses an improved
method that provides more realistic results, especially with regard to
errors in the elevation map. As Stefan Blumentrath mentioned, there are by
now other modules that use the more realistic method of r.watershed,
particularly r.stream.extract and r.hydrodem.

Be aware that r.terraflow still uses the the method of Jenson and Domingue
(1988).

Markus M

>
> Thank you.
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Datum not recognized by Grass

[Markus Metz]

Within GRASS:

g.proj epsg=2932 -p
-PROJ_INFO-
name   : QND95 / Qatar National Grid
ellps  : international
proj   : tmerc
lat_0  : 24.45
lon_0  : 51.21667
k  : 0.9
x_0: 20
y_0: 30
towgs84:
-119.4248,-303.65872,-11.00061,1.164298,0.174458,1.096259,3.657065
no_defs: defined
-PROJ_EPSG-
epsg   : 2932
-PROJ_UNITS
unit   : meter
units  : meters
meters : 1

looks fine.

Outside GRASS, using projinfo from PROJ 6.2.1:
projinfo -o PROJ -s EPSG:2932 -t EPSG:4326
Candidate operations found: 1
-
Operation n°1:

unknown id, Inverse of Qatar National Grid + QND95 to WGS 84 (1), 0 m,
Qatar - onshore

PROJ string:
+proj=pipeline
+step +inv +proj=tmerc +lat_0=24.45 +lon_0=51.21667 +k=0.9
+x_0=20 +y_0=30 +ellps=intl
+step +proj=push +v_3 +step +proj=cart +ellps=intl
+step +proj=helmert +x=-119.4248 +y=-303.65872 +z=-11.00061 +rx=1.164298
+ry=0.174458 +rz=1.096259 +s=3.657065 +convention=position_vector
+step +inv +proj=cart +ellps=WGS84 +step +proj=pop +v_3
+step +proj=unitconvert +xy_in=rad +xy_out=deg +step
+proj=axisswap +order=2,1

Datum transformation happens with +proj=helmert which is the same as the
towgs84 parameters in GRASS. This does not matter, GRASS does not use these
parameters for reprojection, 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,
> > 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 proj4, and what
> > proj files and locations I should scan for.
>
> In this case where the EPSG code is known, there is no need to do anything
> but to ignore the warning. GRASS will use the EPSG code if available and
> passes it to PROJ when it comes to reprojection.
>
> Markus M
>
> >
> > Regards,
> > Zoltan
> >
> > On 2019/12/04 01:30, Helmut Kudrnovsky wrote:
> > >> 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 reprojection
> > >
> > > this issue is already by GRASS with PROJ6, see
> > >
> > > 
> > > GRASS version: 7.8.1
> > > Code revision: c865432c9
> > > Build date: 2019-11-10
> > > Build platform: x86_64-w64-mingw32
> > > GDAL: 3.0.2
> > > PROJ: 6.2.1  <=
> > > GEOS: 3.8.0
> > > SQLite: 3.29.0
> > > Python: 3.7.0
> > > wxPython: 4.0.7
> > > Platform: Windows-10-10.0.18362-SP0 (OSGeo4W)
> > > 
> > >
> > > and the output from the underlying PROJ: 6.2.1
> > >
> > > 
> > > C:\>projinfo EPSG:2932 -o PROJ,WKT2_2018
> > > PROJ.4 string:
> > > +proj=tmerc +lat_0=24.45 +lon_0=51.21667 +k=0.9 +x_0=20
> > > +y_0=30 +ellps=intl
> > >
> +towgs84=-119.4248,-303.65872,-11.00061,1.164298,0.174458,1.096259,3.657065
> > > +units=m +no_defs +type=crs
> > >
> > > WKT2_2018 string:
> > > PROJCRS["QND95 / Qatar National Grid",
> > >  BASEGEOGCRS["QND95",
> > >  DATUM["Qatar National Datum 1995",
> > >  ELLIPSOID["International 1924",6378388,297,
> > >  LENGTHUNIT["metre",1]]],
> > >  PRIMEM["Greenwich",0,
> > >  ANGLEUNIT["degree",0.0174532925199433]],
> > >  ID["EPSG",4614]],
> > >  CONVERSION["Qatar National Grid",
> > >  METHOD["Transverse Mercator",
> > >  ID["EPSG",9807]],
> > >  PARAMETER["Latitude of natural origin",24.45,
> > >  ANGLEUNIT["degree",0.0174532925199433],
> > >  ID["EPSG",8801]],
> > >  PARAMETER["Longitude of natural origin",51.21667,
> > >  ANGLEUNIT["degree",0.0174532925199433],
> > >  ID["EPSG",8802]],
> > >  PARAMETER["Scale factor 

Re: [GRASS-user] Datum not recognized by Grass

[Markus Metz]

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 proj4, and what
> proj files and locations I should scan for.

In this case where the EPSG code is known, there is no need to do anything
but to ignore the warning. GRASS will use the EPSG code if available and
passes it to PROJ when it comes to reprojection.

Markus M

>
> Regards,
> Zoltan
>
> On 2019/12/04 01:30, Helmut Kudrnovsky wrote:
> >> 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 reprojection
> >
> > this issue is already by GRASS with PROJ6, see
> >
> > 
> > GRASS version: 7.8.1
> > Code revision: c865432c9
> > Build date: 2019-11-10
> > Build platform: x86_64-w64-mingw32
> > GDAL: 3.0.2
> > PROJ: 6.2.1  <=
> > GEOS: 3.8.0
> > SQLite: 3.29.0
> > Python: 3.7.0
> > wxPython: 4.0.7
> > Platform: Windows-10-10.0.18362-SP0 (OSGeo4W)
> > 
> >
> > and the output from the underlying PROJ: 6.2.1
> >
> > 
> > C:\>projinfo EPSG:2932 -o PROJ,WKT2_2018
> > PROJ.4 string:
> > +proj=tmerc +lat_0=24.45 +lon_0=51.21667 +k=0.9 +x_0=20
> > +y_0=30 +ellps=intl
> >
+towgs84=-119.4248,-303.65872,-11.00061,1.164298,0.174458,1.096259,3.657065
> > +units=m +no_defs +type=crs
> >
> > WKT2_2018 string:
> > PROJCRS["QND95 / Qatar National Grid",
> >  BASEGEOGCRS["QND95",
> >  DATUM["Qatar National Datum 1995",
> >  ELLIPSOID["International 1924",6378388,297,
> >  LENGTHUNIT["metre",1]]],
> >  PRIMEM["Greenwich",0,
> >  ANGLEUNIT["degree",0.0174532925199433]],
> >  ID["EPSG",4614]],
> >  CONVERSION["Qatar National Grid",
> >  METHOD["Transverse Mercator",
> >  ID["EPSG",9807]],
> >  PARAMETER["Latitude of natural origin",24.45,
> >  ANGLEUNIT["degree",0.0174532925199433],
> >  ID["EPSG",8801]],
> >  PARAMETER["Longitude of natural origin",51.21667,
> >  ANGLEUNIT["degree",0.0174532925199433],
> >  ID["EPSG",8802]],
> >  PARAMETER["Scale factor at natural origin",0.9,
> >  SCALEUNIT["unity",1],
> >  ID["EPSG",8805]],
> >  PARAMETER["False easting",20,
> >  LENGTHUNIT["metre",1],
> >  ID["EPSG",8806]],
> >  PARAMETER["False northing",30,
> >  LENGTHUNIT["metre",1],
> >  ID["EPSG",8807]]],
> >  CS[Cartesian,2],
> >  AXIS["(E)",east,
> >  ORDER[1],
> >  LENGTHUNIT["metre",1]],
> >  AXIS["(N)",north,
> >  ORDER[2],
> >  LENGTHUNIT["metre",1]],
> >  USAGE[
> >  SCOPE["unknown"],
> >  AREA["Qatar - onshore"],
> >  BBOX[24.55,50.69,26.2,51.68]],
> >  ID["EPSG",2932]]
> > 
> >
> >> The problem is that GRASS still assumes datum transformation from X to
> > WGS84, whereas with PROJ6,
> >> WGS84 is no longer required as pivot datum. Datum transformations from
> > datum X to datum Y can
> >> sometimes (often) be done without going through WGS84. The requirement
is
> > to have EPSG or other
> >> authority codes and to use PROJ 6.
> > this warning is just from a simple v.in.ogr of a EPSG:2932-based
shapefile
> > into a EPSG:2932-created GRASS location.
> >
> > so, there may be some more adaptions needed for actions like v.in.ogr
and
> > co?
> >
> >
> >
> > -
> > best regards
> > Helmut
> > --
> > Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
>
> --
>
> =
> Zoltan Szecsei GPrGISc 0031
> Geograph (Pty) Ltd.
> GIS and Photogrammetric Services
>
> P.O. Box 7, Muizenberg 7950, South Africa.
>
> Mobile: +27-83-6004028 (WhatsApp only)
> Qatar:  +974 5083 2722 www.geograph.co.za
> =
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] v.in.ogr: important bug fix when importing from PostgreSQL

[Markus Metz]

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 soon).

Apparently this bug only affects those OGR datasources with a client/server
database system, e.g. PostgreSQL or MySQL.

This bug does not affect common file-based formats like shapefile,
geopackage, etc.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Datum not recognized by Grass

[Markus Metz]

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 reprojection

The problem is that GRASS still assumes datum transformation from X to
WGS84, whereas with PROJ6, WGS84 is no longer required as pivot datum.
Datum transformations from datum X to datum Y can sometimes (often) be done
without going through WGS84. The requirement is to have EPSG or other
authority codes and to use PROJ 6.

Markus M

On Tue, Dec 3, 2019 at 8:52 PM Helmut Kudrnovsky  wrote:

> Markus Neteler wrote
> > Hi,
> >
> > On Mon, Dec 2, 2019 at 9:49 AM Zoltan Szecsei 
>
> > zoltans@.co
>
> >  wrote:
> >>
> >> Hi,
> >> I'm using EPSG 2932 and QGIS etc all are OK with it.
> >>
> >> I have installed everything using OSGeo4W64, so how come Grass does not
> >> use the same projections database (as QGis etc)?
> >> (and please can I have a pointer as to how to introduce EPSG 2932 to
> >> Grass 7.8.1)
> >>
> >> Thanks and regards,
> >> Zoltan
> >>
> >>  Running against:
> >> D:\GDBroad_tiles\shp_road_poly_few\23103770_road_poly.shp
> >> WARNING: Datum
> > 
> >  not recognised by GRASS and
> >> no parameters found
> >
> > Is it possible that you have a PROJ software version mixup?
> >
> > I tried on my Linux box:
> >
> > grass78 -c epsg:2932 ~/grassdata/test_2932
> > Starting GRASS GIS...
> > Creating new GRASS GIS location
> > 
> > ...
> > Cleaning up temporary files...
> >
> >   __  ___   _____
> >  / / __ \/   | / ___/ ___/   / /  _/ ___/
> > / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
> >/ /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
> >\/_/ |_/_/  |_///   \/___///
> >
> > Welcome to GRASS GIS 7.8.2dev (ad4836c73)
> > ...
> >
> > GRASS 7.8.2dev (test_2932):~ > g.proj -w
> > PROJCS["QND95 / Qatar National Grid",
> > GEOGCS["QND95",
> > DATUM["Qatar_National_Datum_1995",
> > SPHEROID["International 1924",6378388,297,
> > AUTHORITY["EPSG","7022"]],
> >
> >
> TOWGS84[-119.4248,-303.65872,-11.00061,1.164298,0.174458,1.096259,3.657065],
> > AUTHORITY["EPSG","6614"]],
> > PRIMEM["Greenwich",0,
> > AUTHORITY["EPSG","8901"]],
> > UNIT["degree",0.0174532925199433,
> > AUTHORITY["EPSG","9122"]],
> > AUTHORITY["EPSG","4614"]],
> > PROJECTION["Transverse_Mercator"],
> > PARAMETER["latitude_of_origin",24.45],
> > PARAMETER["central_meridian",51.216667],
> > PARAMETER["scale_factor",0.9],
> > PARAMETER["false_easting",20],
> > PARAMETER["false_northing",30],
> > UNIT["metre",1,
> > AUTHORITY["EPSG","9001"]],
> > AXIS["Easting",EAST],
> > AXIS["Northing",NORTH],
> > AUTHORITY["EPSG","2932"]]
>
> when importing a shapefile with the same epsg projection, I get:
>
> v.in.ogr --verbose input=D:\wd\test_epsg2932.shp
>
> Using OGR driver 'ESRI Shapefile/ESRI Shapefile'
> WARNING: Datum  von GRASS nicht erkannt und
> keine
> Parameter gefunden.
> Die Projektionsinformationen des Eingabedatensatzes und der aktuellen
> Location scheinen übereinzustimmen.
>
> D:\wd>ogrinfo --version
> GDAL 3.0.2, released 2019/10/28
>
> D:\wd>ogrinfo test_epsg2932.shp -al -so
> INFO: Open of `test_epsg2932.shp'
>   using driver `ESRI Shapefile' successful.
>
> Layer name: test_epsg2932
> Metadata:
>   DBF_DATE_LAST_UPDATE=2019-12-03
> Geometry: Point
> Feature Count: 1
> Extent: (823205.438352, 25769.568359) - (823205.438352, 25769.568359)
> Layer SRS WKT:
> PROJCS["QND95 / Qatar National Grid",
> GEOGCS["QND95",
> DATUM["Qatar_National_Datum_1995",
> SPHEROID["International 1924",6378388,297,
> AUTHORITY["EPSG","7022"]],
> AUTHORITY["EPSG","6614"]],
> PRIMEM["Greenwich",0,
> AUTHORITY["EPSG","8901"]],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AUTHORITY["EPSG","4614"]],
> PROJECTION["Transverse_Mercator"],
> PARAMETER["latitude_of_origin",24.45],
> PARAMETER["central_meridian",51.21667],
> PARAMETER["scale_factor",0.9],
> PARAMETER["false_easting",20],
> PARAMETER["false_northing",30],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> AXIS["Easting",EAST],
> AXIS["Northing",NORTH],
> AUTHORITY["EPSG","2932"]]
> Data axis to CRS axis mapping: 1,2
> id: Integer64 (10.0)
> test: Integer (9.0)
>
> D:\wd>testepsg test_epsg2932.prj
> Validate Succeeds.
> WKT[test_epsg2932.prj] =
> PROJCS["QND95 / Qatar National Grid",
> GEOGCS["QND95",
> DATUM["Qatar_National_Datum_1995",
> SPHEROID["International 1924",6378388,297,
> AUTHORITY["EPSG","7022"]],

Re: [GRASS-user] v.net.distance - from feature was not reachable

[Markus Metz]

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 need to add a new vector
> line (stream) to the river network, which we have done using v.patch as
> follows:
>
> v.patch input=river_network,stream output=river_network_with_stream
>
> We then clean the output as follows:
>
> v.clean input=river_network_with_stream
> output=river_network_with_stream_clean tool=rmdupl,break,snap

I suspect that the two river networks are just not connected (connecting
vertices do not match). This could be fixed by using a larger threshold
value for the snap tool in v.clean. You can also check with
v.net.components if the resultant river networks are correct.

Markus M
>
> We then run the following steps to calculate the shortest path (based on
> the documentation [1]), where the vector dataset (start_point) is
> located on the above-mentioned stream and the end_point is located on
> the river network:
>
> v.net input=river_network_with_stream_clean points=start_point
> output=river_net operation=connect thresh=100 arc_layer=1 node_layer=2
> --overwrite
>
> v.net input=river_net points=end_point output=river_net2
> operation=connect thresh=100 arc_layer=1 node_layer=3 --overwrite
>
> The resulting output of v.category is:
>
>   v.category input=river_net2 option=report
> Layer: 1
> type   countminmax
> point  0  0  0
> line  102092  1 102072
> boundary   0  0  0
> centroid   0  0  0
> area   0  0  0
> face   0  0  0
> kernel 0  0  0
> all   102092  1 102072
> Layer: 2
> type   countminmax
> point  1  1  1
> line   0  0  0
> boundary   0  0  0
> centroid   0  0  0
> area   0  0  0
> face   0  0  0
> kernel 0  0  0
> all1  1  1
> Layer: 3
> type   countminmax
> point  1  1  1
> line   0  0  0
> boundary   0  0  0
> centroid   0  0  0
> area   0  0  0
> face   0  0  0
> kernel 0  0  0
> all1  1  1
>
> At this point, I visually confirm that both points are connected to the
> network and then run:
>
> v.net.distance in=river_net2 out=river_path from_layer=2 to_layer=3
> --overwrite
>
> However, I (keep) get a warning ( WARNING: 1 'from' feature was not
> reachable) and the output is empty. I have read a few posts online
> reporting the same issue, but none of the proposed solutions have
> helped. Is there a step that I am overlooking as I would have assumed
> that once the network topology is built and the points are connected to
> the network that it would have run correctly. I confirm that I can
> calculate the shortest path when I use a start point that is the river
> network (excluding the stream), so I am assuming that the issue is
> related to the output of the v.patch?
>
>
> Thanks in advance for any help or suggestions.
>
> best regards,
>
> Daniel.
>
> [1]: https://grass.osgeo.org/grass76/manuals/v.net.distance.html
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr: which is the meaning of range parameter?

[Markus Metz]

Hi Vero,

On Thu, Nov 14, 2019 at 1:37 PM Veronica Andreo 
wrote:
>
> Hi MarkusN
>
> I accidentaly only answered to MarkusM, sorry... Below, I forward the
emails for further reference. All in all, I understood that the range
parameter is then the theoretical radiance range given that the input is
expected to be radiance.
>
> So, the example for S2 should say S2 level 1C that comes as scaled TOA
and hence it is fine to use 1,1 as range. But in the example for
Landsat if that's a L1 product (L2 wouldn't need atmospheric correction at
all), IIUC, the default range 0,255 is wrong, because those are DN. So, one
should apply Gain and Bias coefficients to the DN range in order to get the
radiance theoretical range required by i.atcorr.

For i.atcorr, it does not really matter if you apply gain and bias. For
example wit S2, if you apply gain and bias with gain = 1/1 and bias =
0, you get values in the range 0, 1 and for i.atcorr you would use
range=0,1. If you do not apply gain and bias, you can let i.atcorr applay
gain and bias by using range=1,1 (0 is nodata in S2).

HTH,

Markus M
>
> @MarkusM please correct me if I got it wrong
>
> 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>) escribió:
> >>
> >> 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.
> >
> > Yes, that's clear. Metadata says 0 is for nodata and 4095 for bad
values, so range would be 1,4094. But these are DN, not radiance and the
manual of i.atcorr says that the module accepts radiance, this is what I
don't understand... Shall I convert to radiance before i.atcorr or use raw
data and the DN range?
>
> Yes, I guess it's better to convert to radiance. So if you have gain and
bias, you can apply them to 1 and 4094 to get the theoretical range of
radiance, no?
>
> Best,
> Markus
> >> > Reading the manual of i.atcorr, I get that I must provide radiance
data. Hence I converted each band to radiance using gain and bias from the
metadata. Now, for the range parameter in i.atcorr, I assume I must pass
the min/max output of r.info for each band. There's no extra info in the
metadata about theoretical range for each band.
> >>
> >> No, the range parameter in i.atcorr needs the theoretical range. For
example for Landsat, values can be in the range 1, 255 (0 is reserved for
nodata IIRC), but actual band values usually cover only a part of that
range. Therefore min/max of a band is not correct.
> >
> > Theoretical range of radiance or the bits of DN?
> >>
> >> Regarding Pleiades or other imagery, you need to get from
documentation or metadata the valid range and use this as range for
i.atcorr.
> >
> > I went through metadata file and user guide, but theoretical range for
radiance I didn't find... only the gain and bias and radiometric resolution.
> >
> > Thanks again,
> > Vero
> >
> >>
> >> HTH,
> >>
> >> Markus M
> >>
> >> >
> >> > In the i.atcorr manual and in some older emails, I read for example,
that the range for Sentinel 2 is 1 to 1. However here [1] it says:
"Per-pixel radiometric measurements are provided in Top Of Atmosphere (TOA)
reflectances along with the parameters to transform them into radiances".
AFAIU, 1,1 is TOA range.
> >> >
> >> > So, I'm a bit lost... What is really this range parameter
representing?
> >> >
> >> > Thanks much in advance
> >> >
> >> > Vero
> >> >
> >> > [1]
https://earth.esa.int/web/sentinel/user-guides/sentinel-2-msi/product-types/level-1c
>
>
> El mié., 13 nov. 2019 a las 22:43, Markus Neteler ()
escribió:
>>
>> Hi,
>>
>> On Wed, Nov 13, 2019 at 2:18 PM Markus Metz
>>  wrote:
>> > 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 manual of i.atcorr, I get that I must provid

Re: [GRASS-user] i.atcorr: which is the meaning of range parameter?

[Markus Metz]

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 manual of i.atcorr, I get that I must provide radiance data.
Hence I converted each band to radiance using gain and bias from the
metadata. Now, for the range parameter in i.atcorr, I assume I must pass
the min/max output of r.info for each band. There's no extra info in the
metadata about theoretical range for each band.

No, the range parameter in i.atcorr needs the theoretical range. For
example for Landsat, values can be in the range 1, 255 (0 is reserved for
nodata IIRC), but actual band values usually cover only a part of that
range. Therefore min/max of a band is not correct.

Regarding Pleiades or other imagery, you need to get from documentation or
metadata the valid range and use this as range for i.atcorr.

HTH,

Markus M

>
> In the i.atcorr manual and in some older emails, I read for example, that
the range for Sentinel 2 is 1 to 1. However here [1] it says:
"Per-pixel radiometric measurements are provided in Top Of Atmosphere (TOA)
reflectances along with the parameters to transform them into radiances".
AFAIU, 1,1 is TOA range.
>
> So, I'm a bit lost... What is really this range parameter representing?
>
> Thanks much in advance
>
> Vero
>
> [1]
https://earth.esa.int/web/sentinel/user-guides/sentinel-2-msi/product-types/level-1c
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Markus Metz]

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 new stable release GRASS GIS 7.8.1. Besides improving the Python 3
> compatibility efforts have concentrated on implementing PROJ 6 and GDAL 3
> support.
>
> An overview of the new features in the 7.8 release series is available at new
> features in GRASS GIS 7.8
> .
> Binaries/Installer download:
>
>- winGRASS 7.8.1: 32bit standalone installer
>
> 
>| 64bit standalone installer
>
> 
>- winGRASS 7.8.1 OSGeo4W: 32bit OSGeo4W installer
> | 64bit
>OSGeo4W installer
>
>- Debian 
>- Fedora and EPEL7
> (CentOS7,
>RHEL7, ... - included in Fedora 31+)
>- Linux Mint: see Ubuntu
>- Ubuntu
>
>(ubuntugis-unstable)
>-
> *... further binary packages for other Linux distributions will follow
>shortly, please check at software downloads
>. *
>
> Source code download:
>
>- https://grass.osgeo.org/grass78/source/
>- https://grass.osgeo.org/grass78/source/grass-7.8.1.tar.gz
>- To get the GRASS GIS 7.8.1 source code directly from GitHub, see here
>.
>
> More details:
>
> See also our detailed announcement:
> https://trac.osgeo.org/grass/wiki/Release/7.8.1-News
> https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures78 (overview of new
> 7.8 stable release series)
> https://grass.osgeo.org/grass7/manuals/addons/ (list of available addons)
>
> Thanks to all contributors!
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] WinGRASS build up (WIP)

[Markus Metz]

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.

Markus M
>
> Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.out.ogr and Date fields

[Markus Metz]

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,
> > >
> > > As part of a workflow, we are importing ESRI Shapefiles into GRASS so
> > > that we can manage the vector topology, before re-exporting the
vectors
> > > back to an ESRI Shapefile. However, we noticed that the date fields
are
> > > being converted from a field of type Date to type String.
>
> Indeed, this happens in v.out.ogr, should be easy to fix. Can you create
a ticket just as a reminder?

Please try https://github.com/OSGeo/grass/pull/184

Markus M
> >
> > AFAIK this is how SQLite handles it internally but the GRASS DBMI
> > driver should take care of it to keep it in date format.
>
> This has nothing to do with the sqlite driver.
>
> Markus M
>
> >
> >
> > > Hopefully the
> > > following steps will demonstrate the issue:
> > >
> > > The input Shapefile is scdb_date, with a date field called 'BA_DATE':
> > >
> > >  >ogrinfo -so -al scdb_date.shp | grep BA_DATE
> > > BA_DATE: Date (10.0)
> > >
> > > After importing into GRASS using v.in.ogr, the field is still of type
> > > DATE (although the length has increased to 20):
> > >
> > >  >db.describe scdb_date | grep -A 5 BA_DATE
> > > column:BA_DATE
> > > description:
> > > type:DATE
> > > len:20
> > > scale:0
> > > precision:0
> > >
> > > However, when I export the vector (scdb_date) back to an ESRI
Shapefile
> > > using v.out.ogr, the BA_DATE is converted to a String:
> > >
> > > v.out.ogr input=scdb_date output=scdb_date_export.shp
> > > format='ESRI_Shapefile'
> > >
> > >  >ogrinfo -so -al scdb_date_export.shp | grep 'BA_DATE'
> > > BA_DATE: String (20.0)
> >
> > Probably the date detection failed in the grass-sqlite driver?
> > Could it be an encoding problem?
> >
> > > I tried exporting to a GeoPackage, but the issue persists. While, we
can
> > > still overcome this issue using ogr and SQL, I am wondering if is
there
> > > a flag or option in v.out.ogr that I am overlooking that would
maintain
> > > the fields of type Date or is there something else that I should
consider?
> >
> > As this is unexpected could you make a small data sample available to
> > easier reproduction?
> >
> > thanks
> > Markus
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] WinGRASS build up (WIP)

[Markus Metz]

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://wingrass.fsv.cvut.cz/grass78/x86_64/logs/log-r9c8923eb9-9/package.log
> >
> > ##
> >
> > [...]
> > checking for location of External PROJ includes... /c/OSGeo4W64/include
> > checking for proj.h... yes
> > checking External PROJ major version... 6
> > checking External PROJ minor version... 2
> > checking External PROJ patch version... 1
> > found PROJ version 6.2.1
> > using new PROJ version 5+ API
> > checking for location of External PROJ library...
/usr/src/grass78/mswindows/osgeo4w/lib
> > checking for proj_pj_info in -lproj... yes
> > checking for location of External PROJ data files...
/c/OSGeo4W64/share/proj
> > checking for /c/OSGeo4W64/share/proj/epsg... no
> > configure: warning: *** Unable to locate PROJ data files.
> > [...]
> > GDAL support:   yes
> >
> > ##
> >
> > daily build 79:
> >
> >
https://wingrass.fsv.cvut.cz/grass79/x86_64/logs/log-r39af5f541-9/package.log
> >
> > ##
> >
> > [...]
> > checking for location of External PROJ data files...
/c/OSGeo4W64/share/proj
> > checking for /c/OSGeo4W64/share/proj/epsg... no
> > configure: warning: *** Unable to locate PROJ data files.
>
> Harmless, but not nice. From PROJ 6 onwards, there is no epsg file any
more in share/proj/, I will fix the test in master.

Fixed in master 43fae79

Markus M

>
> > [...]
> > GDAL support:   yes
> >
> > ##
> >
> > daily builds with proj6/gdal3 in OSGeo4W looks good so far.
> >
> > regards
> > Helmut
> >
> >
> >
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] WinGRASS build up (WIP)

[Markus Metz]

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 External PROJ includes... /c/OSGeo4W64/include
> checking for proj.h... yes
> checking External PROJ major version... 6
> checking External PROJ minor version... 2
> checking External PROJ patch version... 1
> found PROJ version 6.2.1
> using new PROJ version 5+ API
> checking for location of External PROJ library...
/usr/src/grass78/mswindows/osgeo4w/lib
> checking for proj_pj_info in -lproj... yes
> checking for location of External PROJ data files...
/c/OSGeo4W64/share/proj
> checking for /c/OSGeo4W64/share/proj/epsg... no
> configure: warning: *** Unable to locate PROJ data files.
> [...]
> GDAL support:   yes
>
> ##
>
> daily build 79:
>
>
https://wingrass.fsv.cvut.cz/grass79/x86_64/logs/log-r39af5f541-9/package.log
>
> ##
>
> [...]
> checking for location of External PROJ data files...
/c/OSGeo4W64/share/proj
> checking for /c/OSGeo4W64/share/proj/epsg... no
> configure: warning: *** Unable to locate PROJ data files.

Harmless, but not nice. From PROJ 6 onwards, there is no epsg file any more
in share/proj/, I will fix the test in master.

Markus M

> [...]
> GDAL support:   yes
>
> ##
>
> daily builds with proj6/gdal3 in OSGeo4W looks good so far.
>
> regards
> Helmut
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.out.ogr and Date fields

[Markus Metz]

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 vectors
> > back to an ESRI Shapefile. However, we noticed that the date fields are
> > being converted from a field of type Date to type String.

Indeed, this happens in v.out.ogr, should be easy to fix. Can you create a
ticket just as a reminder?
>
> AFAIK this is how SQLite handles it internally but the GRASS DBMI
> driver should take care of it to keep it in date format.

This has nothing to do with the sqlite driver.

Markus M

>
>
> > Hopefully the
> > following steps will demonstrate the issue:
> >
> > The input Shapefile is scdb_date, with a date field called 'BA_DATE':
> >
> >  >ogrinfo -so -al scdb_date.shp | grep BA_DATE
> > BA_DATE: Date (10.0)
> >
> > After importing into GRASS using v.in.ogr, the field is still of type
> > DATE (although the length has increased to 20):
> >
> >  >db.describe scdb_date | grep -A 5 BA_DATE
> > column:BA_DATE
> > description:
> > type:DATE
> > len:20
> > scale:0
> > precision:0
> >
> > However, when I export the vector (scdb_date) back to an ESRI Shapefile
> > using v.out.ogr, the BA_DATE is converted to a String:
> >
> > v.out.ogr input=scdb_date output=scdb_date_export.shp
> > format='ESRI_Shapefile'
> >
> >  >ogrinfo -so -al scdb_date_export.shp | grep 'BA_DATE'
> > BA_DATE: String (20.0)
>
> Probably the date detection failed in the grass-sqlite driver?
> Could it be an encoding problem?
>
> > I tried exporting to a GeoPackage, but the issue persists. While, we can
> > still overcome this issue using ogr and SQL, I am wondering if is there
> > a flag or option in v.out.ogr that I am overlooking that would maintain
> > the fields of type Date or is there something else that I should
consider?
>
> As this is unexpected could you make a small data sample available to
> easier reproduction?
>
> thanks
> Markus
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Null values in attribute table get converted to 0 (zero) during v.to.rast

[Markus Metz]

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 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
>> https://github.com/OSGeo/grass/pull/173
>> if an attribute value is null, the corresponding vector features will
not be rasterized
>>
>> Markus M
>>
>> I'm not sure I agree with the approach that a polygon with missing
attribute should become NULL. In my view, NULL should be used only for
pixels not covered at all by any polygon.
>
> but in the resulting raster (in rasters in general), there's no
difference, it's rather NULL or it has a value... it does not matter if the
null comes from areas originally covered by a polygon or not...

I think it depends on the particular use case if it matters where a NULL
raster value comes from: a polygon with empty attribute or no polygon at
all for that cell.

>>
>> Perhaps an additional input parameter "missing_attribute" so the user
can choose a value to enter into the raster if the attribute is missing. If
no parameter is supplied, and the chosen attribute column has missing
values, I'd prefer that the script exit gracefully, with a message that a
"missing_attribute" value is required.

This can easily be done with existing tools:
- convert only those polygons with a valid attribute value: v.to.rast
where="attribute is not null"
- replace missing attribute values with a valid value: v.db.update
where="attribute is null", then v.to.rast

I'm changing my PR to issue a warning if empty attribute values are found
and replaced with zero.

Markus M

>
> yes, this could be a solution to keep track of where you had polygons,
but then you would need to use r.null anyway, no? I try to think of use
cases in which one uses a vector attribute to convert to raster, but then
still needs to know where the polygons were... because, for example, to
query a raster map with another raster map representing zones one would
convert the vector of polygons using cat and not an attribute, no?
>
> cheers,
> Vero
>>
>>
>> > El jue., 24 oct. 2019 a las 14:40, Daniel Victoria (<
daniel.victo...@gmail.com>) escribió:
>> >>
>> >> Hi list,
>> >>
>> >> I have a vector polygon map that I'm converting to raster. The
attribute column that I process has some empty rows (no data / null). When
I run v.to.rast, these empty rows become 0 (zero) on my resulting raster
map.
>> >>
>> >> Shouldn't v.to.rast respect the empty attribute table and create null
values for those polygons?
>> >>
>> >> For now I'll use r.null to fix this problem. But what if 0 is a valid
value?
>> >>
>> >> Cheers
>> >> Daniel
>> >>
>> >> PS - Running Grass 7.6.1 on Ubuntu
>> >> ___
>> >> grass-user mailing list
>> >> grass-user@lists.osgeo.org
>> >> https://lists.osgeo.org/mailman/listinfo/grass-user
>> >
>> > ___
>> > grass-user mailing list
>> > grass-user@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>> --
>> Micha Silver
>> Ben Gurion Univ.
>> Sde Boker, Remote Sensing Lab
>> cell: +972-523-665918
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Null values in attribute table get converted to 0 (zero) during v.to.rast

[Markus Metz]

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
https://github.com/OSGeo/grass/pull/173
if an attribute value is null, the corresponding vector features will not
be rasterized

Markus M

>
> Cheers,
> Vero
>
> El jue., 24 oct. 2019 a las 14:40, Daniel Victoria (<
daniel.victo...@gmail.com>) escribió:
>>
>> Hi list,
>>
>> I have a vector polygon map that I'm converting to raster. The attribute
column that I process has some empty rows (no data / null). When I run
v.to.rast, these empty rows become 0 (zero) on my resulting raster map.
>>
>> Shouldn't v.to.rast respect the empty attribute table and create null
values for those polygons?
>>
>> For now I'll use r.null to fix this problem. But what if 0 is a valid
value?
>>
>> Cheers
>> Daniel
>>
>> PS - Running Grass 7.6.1 on Ubuntu
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Null values in attribute table get converted to 0 (zero) during v.to.rast

[Markus Metz]

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 here
https://github.com/OSGeo/grass/blob/master/lib/db/dbmi_client/select.c#L368
and here
https://github.com/OSGeo/grass/blob/master/lib/db/dbmi_client/select.c#L375

I can't estimate the side effects of any changes, this is a widely used
function, thus no easy fix. Please open a ticket.

Markus M

>
> Cheers,
> Vero
>
> El jue., 24 oct. 2019 a las 14:40, Daniel Victoria (<
daniel.victo...@gmail.com>) escribió:
>>
>> Hi list,
>>
>> I have a vector polygon map that I'm converting to raster. The attribute
column that I process has some empty rows (no data / null). When I run
v.to.rast, these empty rows become 0 (zero) on my resulting raster map.
>>
>> Shouldn't v.to.rast respect the empty attribute table and create null
values for those polygons?
>>
>> For now I'll use r.null to fix this problem. But what if 0 is a valid
value?
>>
>> Cheers
>> Daniel
>>
>> PS - Running Grass 7.6.1 on Ubuntu
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Debugging a r.gdal import error

[Markus Metz]

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 issues: r.in.gdal/r.import unable to read
> hdr.adf and maps that are supposed to fit tightly to the border of a topo
> quad rectangle don't. I'll deal with the latter issue first.
>
> I separated the orginal bare-earth dataset for one portion of the topo
quad
> and uploaded it to fileconvory.com
> <
http://www.fileconvoy.com/dfl.php?id=g180d8982ad7f3f731000197000c9cb9624a57ea50a
>.
> Even xz compressed it's 550MB large. It will be available at that URL for
5
> days.

I used r.in.gdal in=be_45123h5 out=be_45123h5, i.e. the coverage directory
as input (GDAL recognizes this as an AIG/Arc/Info Binary Grid).

The output appears slightly tilted (rotated clockwise), but this is
apparently correct: the data match other elevation data. The topo quad
rectangle is probably a guide whereabouts the DEM should be located. If in
doubt you need to supply the corresponding topo rectangle for testing,
without any modification of course.

The DEM as it is imported into GRASS seems correct. Any rotation will
introduce errors.

Markus M

>
> The output of gdalinfo -proj4 on the w* file is the same as that in the
> prj.adf file.
>
> My workflow started with creating a new location using the prj.adf file to
> set the projection. Then I applied r.in.gdal to the hdr.adf. Displaying
the
> imported file shows it is slightly rotated clockwise (see attached file
> h5clatsop.png). The other two maps in this topo quad import and display
> correctly (the three can be seen in the attached file,
45123a5_clatsop.png.
>
> I'm at a loss to understand why the imported map is not square with the
topo
> boundary. The gdalinfo -proj4 results (attached) show different
coordinates
> for the northwest and southwest but the OLC data coordinator tells me the
> map displays correctly for him and one of his colleagues.
>
> Regards,
>
> Rich___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] make fails to find Platform.make

[Markus Metz]

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:
> >
> > rm /home/mneteler/tmp//grass76/include/Make/Platform.make
> > make /home/mneteler/tmp//grass76/include/Make/Platform.make
> >
> > How can it work? Is the file recreated somehow after the rm command?
What happens if you run only make include/Make/Platform.make?
>
> in this case "/home/mneteler/tmp//grass76" is the installation target,
"make install" cleans up leftovers from a previous installation. The real
Platform.make is in this example here:
>
/home/mneteler/software/grass76_git/dist.x86_64-pc-linux-gnu/include/Make/Platform.make
> to be installed to
> /home/mneteler/tmp//grass76/include/Make/Platform.make
>
> What is you install target, defined with configure --prefix= ?

Ah, I see. You configured with

/configure \
-prefix=/home/WUR/duque004/grass/


which will install GRASS to
/home/WUR/duque004/grass/grass-7.6.0
but that is also your source and build directory. You need to move the
grass source to somewhere else or use a different prefix

Markus M

>> Markus M
>
> >
> > Regarding the volume: I think it is NFS, providing the user areas in
the HPC cluster.
> >
> > Thanks you.
> >
> > --
> > Luís
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] make fails to find Platform.make

[Markus Metz]

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 /home/mneteler/tmp//grass76/include/Make/Platform.make
>
> How can it work? Is the file recreated somehow after the rm command? What
happens if you run only make include/Make/Platform.make?

in this case "/home/mneteler/tmp//grass76" is the installation target,
"make install" cleans up leftovers from a previous installation. The real
Platform.make is in this example here:
/home/mneteler/software/grass76_git/dist.x86_64-pc-linux-gnu/include/Make/Platform.make
to be installed to
/home/mneteler/tmp//grass76/include/Make/Platform.make

What is you install target, defined with configure --prefix= ?

Markus M

>
> Regarding the volume: I think it is NFS, providing the user areas in the
HPC cluster.
>
> Thanks you.
>
> --
> Luís
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.proj: meaning of displayed cell numbers

[Markus Metz]

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: 610354.50 (610354.50)
> East: 643708.50 (643708.50)
> EW-res: 3.00
> NS-res: 3.00
>
> Output:
> Cols: 10172 (647333)
> Rows: 14209 (477579)
> North: 249034.059746 (291528.074025)
> South: 234825.054971 (-186051.086454)
> West: 2286071.280048 (2167423.204862)
> East: 2296243.286494 (2814756.615068)
> EW-res: 1.01
> NS-res: 1.00
>
> I assume the first numbers are the actual values. What do the
parenthetical
> values represent?

The first numbers correspond to the current region in the target location,
the numbers in parentheses correspond to the actual map to be reprojected.

Markus M

>
> Regards,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Script fails; manual entry works

[Markus Metz]

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 launch the script, or
> > - follow
> >  https://grasswiki.osgeo.org/wiki/GRASS_and_Shell#GRASS_Batch_jobs,
> >  i.e. let the GRASS_BATCH_JOB variable point to your script
>
> Moritz,
>
> Through a lot of trial-and-error I've learned that all I can batch are the
> commands run in a single location. For each row in the Ohio-system (A-H
from
> south to north) there are 8 columns and I was trying -- and failing -- to
> process each row (G1-G8) in a single batch file.
>
> I've learned that I can create a shell script file that creates eight new
> locations, one for each column in the row.
>
> But I cannot import then reproject (twice) in a single batch file because
> each action is done in a different location.
>
> What I need to do is create 24 batch files and run each manually by
setting
> and unsetting the GRASS_BATCH_JOB environmental variable. This is actually
> longer than copying and pasting lines from the inclusive (but ineffective)
> batch file to the command line, invoking and exiting grass after all
> operations in a single location.
>
> I'll add a feature request for 8.x in trac to expand batch file processing
> so that commands such as r.in.gdal/r.import in one location can be
followed
> by r.proj in other locations.

within a running GRASS session, you can switch the mapset (and location)
with g.mapset

HTH,

Markus M
>
> Thanks for the pointers,
>
> Rich
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Snap distance to clean imported map?

[Markus Metz]

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: > v.in.ogr in=OR_geodatabase_wetlands.gdb out=more_wetlands
loc=geo_wetlands
>
> WARNING: Number of incorrect boundaries: 88544
> -
> WARNING: The output contains topological errors:
>   Unable to calculate a centroid for 329691 areas
>   Number of incorrect boundaries: 88544
> The input could be cleaned by snapping vertices to each other.
> Estimated range of snapping threshold: [1e-09, 1]
> Try to import again, snapping with 1e-05: 'snap=1e-05'
>
> In the past 1e-05 produced similar warnings.
>
> I'd like advice on two issues:
>
> 1) Is 1e-05 the most reasonable starting snap distance? (I assume it is a
> generic value but perhaps not for all maps.) If not, what would be a snap
> distance to use?

The estimated snap distance is estimated from the bounding box of the
imported data and thus specific for each import. In this particular case
the suggested snap distance is snap=1e-5. If results are not as expected,
increase or decrease by powers of 10, i.e. up to 1e-4 or down to 1e-6.
>
> 2) What would be a reasonable snap distance to stop re-importing when
> warnings continue to be displayed?

The upper limit of the estimated range, in this case of [1e-09, 1], i.e 1.

Markus M
>
> TIA,
>
> Rich
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.proj issue

[Markus Metz]

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 the -p or -g flag. I suggest to first check you current
> > region in the target location/mapset and compare with r.proj -p or -g
>
> Markus M, et al.:
>
> I've worked on this for 2+ days and cannot get the DEM from the source
> location to the target location when both have the same projection and
> units.
>
> Following the above still fails and I've no idea what to do now.
>
> Source location:
> > r.proj -p loc=Oregon map=topography in=n45w121
> Input map  in location :
> Source cols: 80297
> Source rows: 111356
> Local north: 148340.8192959
> Local south: 36984.78211177
> Local west: 2459852.09770149
> Local east: 2540149.13365527
>
> Current (target) region:
> > g.region -p
> projection: 99 (NAD83(HARN) / Oregon North)
> zone:   0
> datum:  nad83harn
> ellipsoid:  grs80
> north:  307220.87234928
> south:  -199204.29675669
> west:   2161358.9640483
> east:   2822158.25992759
> nsres:  1.0033
> ewres:  1.0045
> rows:   506425
> cols:   660799
> cells:  334645133575
>
> Reset current region to the source:
> > g.region n=148340.8192959 s=36984.78211177 w=2459852.09770149
e=2540149.13365527 cols=80297 rows=111356

You should now use
r.proj loc=Oregon map=topography in=n45w121

and not r.unpack, that is a completely different workflow that has nothing
to do with reprojection.

Markus M

>> Unpack the DEM in the current location/mapset;
> > r.unpack n45w121.pack
> WARNING: Difference between PROJ_INFO file of packed map and of current
>   location:
>   name: NAD83(HARN) / Oregon North
>   datum: nad83harn
>   ellps: grs80
>   proj: lcc
>   lat_1: 46
>   lat_2: 44.34
>   lat_0: 43.66
>   lon_0: -120.5
>   x_0: 250
>   y_0: 0
>   no_defs: defined
>   - towgs84: 0.000,0.000,0.000
> ERROR: Projection of dataset does not appear to match current location. In
> case of no significant differences in the projection definitions,
> use the -o flag to ignore them and use current location
definition.
>
> If I correctly understand gdalwarp it functions like r.proj in
reprojecting
> a raster map from one location to another location. Here, both the source
> and target locations have the same projection. Will gdalwarp work in this
> case? Isn't r.pack/r.unpack the correct module pair?
>
> Please advise me of what I should do now or what other information I can
> provide.
>
> Regards,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.proj issue

[Markus Metz]

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 the output is wrong.
> >
> > Command:
> > r.proj loc=Oregon map=topography in=n46w123 met=lanczos_f mem=16000 --o
> >
> > Input location:
> > name: unnamed
> > ellps: grs80
> > proj: lcc
> > lat_1: 46
> > lat_2: 44.34
> > lat_0: 43.66
> > lon_0: -120.5
> > x_0: 250
> > y_0: 0
> > no_defs: defined
> > unit: Meter
> > units: Meters
> > meters: 1
> >
> > Cols: 502 (80961)
> > Rows: 39234 (113148)
> > North: 262349.035904 (262349.035904)
> > South: 223115.062541 (149201.112724)
> > West: 2302891.866970 (2302891.866970)
> > East: 2303393.867032 (2383852.876897)
> > EW-res: 1.00
> > NS-res: 0.99
> >
> > Output location:
> > name: NAD83(HARN) / Oregon North
> > datum: nad83harn
> > ellps: grs80
> > proj: lcc
> > lat_1: 46
> > lat_2: 44.34
> > lat_0: 43.66
> > lon_0: -120.5
> > x_0: 250
> > y_0: 0
> > no_defs: defined
> > unit: meter
> > units: meters
> > meters: 1
> >
> > Cols: 500 (71702)
> > Rows: 39232 (50757)
> > North: 262348.951018 (273873.984569)
> > South: 223116.836808 (223116.836808)
> > West: 2302892.017711 (2231689.553588)
> > East: 2303392.020970 (2303392.020970)
> > EW-res: 1.07
> > NS-res: 1.03Cols: 500 (71702)
> > Rows: 39232 (50757)
> > North: 262348.951018 (273873.984569)
> > South: 223116.836808 (223116.836808)
> > West: 2302892.017711 (2231689.553588)
> > East: 2303392.020970 (2303392.020970)
> > EW-res: 1.07
> > NS-res: 1.03
> >
> > Rich
> > ___
> > grass-user mailing list
>
> > grass-user@.osgeo
>
> > https://lists.osgeo.org/mailman/listinfo/grass-user
> >
> > input-dem.png (296K)
> > 
http://osgeo-org.1560.x6.nabble.com/attachment/5416106/0/input-dem.png;
> > output-dem.png (28K)
> > 
http://osgeo-org.1560.x6.nabble.com/attachment/5416106/1/output-dem.png;
>
> a good thing to see if reprojection of raster data works correctly, is
> comparing before/after r.proj with gdalwarp (1) results.

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 the -p or -g flag. I suggest to first check you current region
in the target location/mapset and compare with r.proj -p or -g

Markus M
>
> (1) https://gdal.org/programs/gdalwarp.html#gdalwarp
>
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Markus Metz]

On Wed, Aug 28, 2019 at 12:54 PM Gabriel Cotlier 
wrote:
>
> Dear Markus,
> Thanks a lot for your replay,
> I have tried the command to change default region with g.region -p
n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30 -s
> and did not allow me because according to the error message bellow my
data is in a mapset that is not  . I have two mapsets one called
"gabriel" where all the data is and another 
> How can I solve this problem?

start GRASS in the PERMANENT mapset, then run
g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00: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, 2019 at 2:25 PM Gabriel Cotlier 
wrote:
>> >
>> > Dear Markus,
>> >
>> > here is my log of the command, "g.region -d -u -p":
>> >
>> >
>> > (Tue Aug 27 09:23:26 2019)

>> > g.region -d -u -p

>> > 360 degree EW extent is exceeded by 1.99983 cells
>> > 360 degree EW extent is exceeded by 1.99983 cells
>> > projection: 3 (Latitude-Longitude)
>> > zone:   0
>> > datum:  wgs84
>> > ellipsoid:  wgs84
>> > north:  75:00:29.99892N
>> > south:  65:00:29.999064S
>> > west:   180:00:29.997408W
>> > east:   180:00:29.997408E
>> > nsres:  0:00:30
>> > ewres:  0:00:30
>> > rows:   16802
>> > cols:   43202
>> > cells:  725880004
>> > (Tue Aug 27 09:23:26 2019) Command finished (0 sec)

>>
>> if you want to avoid this message, change our default region with
>>
>> g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E
res=00:00:30 -s
>>
>> 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 <
markus.metz.gisw...@gmail.com> 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 20:01:47 2019)

>> >> > g.region -p

>> >> > 360 degree EW extent is exceeded by 1.99983 cells
>> >> > projection: 3 (Latitude-Longitude)
>> >> > zone:   0
>> >> > datum:  wgs84
>> >> > ellipsoid:  wgs84
>> >> > north:  75:00:15N
>> >> > south:  65:00:15S
>> >> > west:   179:59:45W
>> >> > east:   180:00:15E
>> >> > nsres:  0:00:30
>> >> > ewres:  0:00:30
>> >> > rows:   16801
>> >> > cols:   43200
>> >> > cells:  725803200
>> >> > (Sun Aug 25 20:01:47 2019) Command finished (0 sec)

>> >> > (Sun Aug 25 20:02:10 2019)
>> >> >
>> >> > g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E
res=00:00:30
>> >> > 360 degree EW extent is exceeded by 1.99983 cells
>> >>
>> >> Strange, the region defined with "n=75:00:15N s=65:00:15S
w=179:59:45W e=180:00:15E res=00:00:30" should not cause a message like
>> >> "360 degree EW extent is exceeded by 1.99983 cells"
>> >>
>> >> Maybe the default region has strange settings. What is the output of
"g.region -d -u -p" ?
>> >>
>> >> Markus M
>> >>
>> >> > projection: 3 (Latitude-Longitude)
>> >> > zone:   0
>> >> > datum:  wgs84
>> >> > ellipsoid:  wgs84
>> >> > north:  75:00:15N
>> >> > south:  65:00:15S
>> >> > west:   179:59:45W
>> >> > east:   180:00:15E
>> >> > nsres:  0:00:30
>> >> > ewres:  0:00:30
>> >> > rows:   16801
>> >> > cols:   43200
>> >> > cells:  725803200
>> >> > (Sun Aug 25 20:02:10 2019) Command finished (0 sec)
>> >> >
>> >> > Are the resulting intercallibrated layers ready for further use
outside grass exported as GeoTIFF or I need to get inside grass without any
messages that 360 degree EW extent is exceeded for the layer to be OK?
>> >> >
>> >> > further more I would like to ask if maybe the max and min for
intercallibtated layer are somewhere already available to check whether the
max and min I got are correct?
>> >> > Thanks a lot for your help.
>> >> > Regards,
>> >> > Gabriel
>> >> >
>> >> >
>> >> >
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Creating location using EPSG code

[Markus Metz]

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
> started grass within that directory: grass79 -c epsg:2838 --gui PERMANENT
>
> The EPSG code is defined as:
>
> EPSG 2838  NAD83(HARN) 
> proj4: +proj=lcc +lat_1=46 +lat_2=44.34
+lat_0=43.66 +lon_0=-120.5 +x_0=250 +y_0=0 +ellps=GRS80
+units=m +no_defs
>
> but those are not the values seen by g.region:
>
> GRASS 7.9.dev (mohler):/data/grassdata > g.region -p
> projection: 99 (NAD83(HARN) / Oregon North)
> zone:   0
> datum:  nad83harn
> ellipsoid:  grs80
> north:  1
> south:  0
> west:   0
> east:   1
> nsres:  1
> ewres:  1
> rows:   1
> cols:   1
> cells:  1
>
> What have I done incorrectly?

The purpose of g.region is to show/change the current computational region.

If you want to verify the CRS of the current location, use g.proj.

Markus M

>
> TIA,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Markus Metz]

On Tue, Aug 27, 2019 at 2:25 PM Gabriel Cotlier  wrote:
>
> Dear Markus,
>
> here is my log of the command, "g.region -d -u -p":
>
>
> (Tue Aug 27 09:23:26 2019)

> g.region -d -u -p

> 360 degree EW extent is exceeded by 1.99983 cells
> 360 degree EW extent is exceeded by 1.99983 cells
> projection: 3 (Latitude-Longitude)
> zone:   0
> datum:  wgs84
> ellipsoid:  wgs84
> north:  75:00:29.99892N
> south:  65:00:29.999064S
> west:   180:00:29.997408W
> east:   180:00:29.997408E
> nsres:  0:00:30
> ewres:  0:00:30
> rows:   16802
> cols:   43202
> cells:  725880004
> (Tue Aug 27 09:23:26 2019) Command finished (0 sec)


if you want to avoid this message, change our default region with

g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30
-s

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 20:01:47 2019)

>> > g.region -p

>> > 360 degree EW extent is exceeded by 1.99983 cells
>> > projection: 3 (Latitude-Longitude)
>> > zone:   0
>> > datum:  wgs84
>> > ellipsoid:  wgs84
>> > north:  75:00:15N
>> > south:  65:00:15S
>> > west:   179:59:45W
>> > east:   180:00:15E
>> > nsres:  0:00:30
>> > ewres:  0:00:30
>> > rows:   16801
>> > cols:   43200
>> > cells:  725803200
>> > (Sun Aug 25 20:01:47 2019) Command finished (0 sec)

>> > (Sun Aug 25 20:02:10 2019)
>> >
>> > g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E
res=00:00:30
>> > 360 degree EW extent is exceeded by 1.99983 cells
>>
>> Strange, the region defined with "n=75:00:15N s=65:00:15S w=179:59:45W
e=180:00:15E res=00:00:30" should not cause a message like
>> "360 degree EW extent is exceeded by 1.99983 cells"
>>
>> Maybe the default region has strange settings. What is the output of
"g.region -d -u -p" ?
>>
>> Markus M
>>
>> > projection: 3 (Latitude-Longitude)
>> > zone:   0
>> > datum:  wgs84
>> > ellipsoid:  wgs84
>> > north:  75:00:15N
>> > south:  65:00:15S
>> > west:   179:59:45W
>> > east:   180:00:15E
>> > nsres:  0:00:30
>> > ewres:  0:00:30
>> > rows:   16801
>> > cols:   43200
>> > cells:  725803200
>> > (Sun Aug 25 20:02:10 2019) Command finished (0 sec)
>> >
>> > Are the resulting intercallibrated layers ready for further use
outside grass exported as GeoTIFF or I need to get inside grass without any
messages that 360 degree EW extent is exceeded for the layer to be OK?
>> >
>> > further more I would like to ask if maybe the max and min for
intercallibtated layer are somewhere already available to check whether the
max and min I got are correct?
>> > Thanks a lot for your help.
>> > Regards,
>> > Gabriel
>> >
>> >
>> >
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[Markus Metz]

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 20:01:47 2019)

> g.region -p

> 360 degree EW extent is exceeded by 1.99983 cells
> projection: 3 (Latitude-Longitude)
> zone:   0
> datum:  wgs84
> ellipsoid:  wgs84
> north:  75:00:15N
> south:  65:00:15S
> west:   179:59:45W
> east:   180:00:15E
> nsres:  0:00:30
> ewres:  0:00:30
> rows:   16801
> cols:   43200
> cells:  725803200
> (Sun Aug 25 20:01:47 2019) Command finished (0 sec)

> (Sun Aug 25 20:02:10 2019)
>
> g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E
res=00:00:30
> 360 degree EW extent is exceeded by 1.99983 cells

Strange, the region defined with "n=75:00:15N s=65:00:15S w=179:59:45W
e=180:00:15E res=00:00:30" should not cause a message like
"360 degree EW extent is exceeded by 1.99983 cells"

Maybe the default region has strange settings. What is the output of
"g.region -d -u -p" ?

Markus M

> projection: 3 (Latitude-Longitude)
> zone:   0
> datum:  wgs84
> ellipsoid:  wgs84
> north:  75:00:15N
> south:  65:00:15S
> west:   179:59:45W
> east:   180:00:15E
> nsres:  0:00:30
> ewres:  0:00:30
> rows:   16801
> cols:   43200
> cells:  725803200
> (Sun Aug 25 20:02:10 2019) Command finished (0 sec)
>
> Are the resulting intercallibrated layers ready for further use outside
grass exported as GeoTIFF or I need to get inside grass without any
messages that 360 degree EW extent is exceeded for the layer to be OK?
>
> further more I would like to ask if maybe the max and min for
intercallibtated layer are somewhere already available to check whether the
max and min I got are correct?
> Thanks a lot for your help.
> Regards,
> Gabriel
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question on Stray light Landsat 8 data

[Markus Metz]

Dear Gabriel,

On Tue, Aug 20, 2019 at 9:50 PM Gabriel Cotlier  wrote:
>
> Dear Markus,
> So I run the command g.region w=179:59:45W e=180:00:15E
>
> Now my log now before and after the command g.region w=179:59:45W
e=180:00:15E is as follows:
>
> 360 degree EW extent is exceeded by 1 cells
> 360 degree EW extent is exceeded by 1 cells
> (Tue Aug 20 16:41:45 2019) Command finished (0 sec)

> (Tue Aug 20 16:43:47 2019)

> g.region w=179:59:45W e=180:00:15E

> 360 degree EW extent is exceeded by 1.99983 cells
> 360 degree EW extent is exceeded by 1 cells
> (Tue Aug 20 16:43:48 2019) Command finished (0 sec)

> (Tue Aug 20 16:44:18 2019)

> g.region -p

> projection: 3 (Latitude-Longitude)
> zone:   0
> datum:  wgs84
> ellipsoid:  wgs84
> north:  75:00:15N
> south:  65:00:15S
> west:   179:59:45W
> east:   180:00:15E
> nsres:  0:00:30
> ewres:  0:00:30
> rows:   16801
> cols:   43200
> cells:  725803200
> 360 degree EW extent is exceeded by 1.99983 cells
> (Tue Aug 20 16:44:18 2019) Command finished (0 sec)

With GRASS 7.6, I can not reproduce this message.
g.region -p n=75:00:15N s=65:00:15S w=179:59:45W e=180:00:15E res=00:00:30

gives me
projection: 3 (Latitude-Longitude)
zone:   0
datum:  wgs84
ellipsoid:  wgs84
north:  75:00:15N
south:  65:00:15S
west:   179:59:45W
east:   180:00:15E
nsres:  0:00:30
ewres:  0:00:30
rows:   16801
cols:   43200
cells:  725803200

without any messages that 360 degree EW extent is exceeded. Which GASS
version are you using? I tested with GRASS 7.6 and GRASS 7.9.

Markus M

>
> Now appears to say that is exceeded by 1.99983 cells why could this
be happening?
> Thanks a lot
>
> Regards
> Gabriel
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Aug 20, 2019 at 4:33 PM Gabriel Cotlier 
wrote:
>>
>> Dear Markus,
>> Thanks a lot for your response and explanation.
>> Changing the region 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...@gmail.com> wrote:
>>>
>>> Dear Gabriel,
>>>
>>> On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier 
wrote:
>>> >
>>> > Dear Markus,
>>> >
>>> > Thanks a lot for the clarification and explanation, your response was
indeed helpful.
>>> >
>>> > I got for all maps in the mapset I used, for both the DMSP original
raster layers and the intercallibrated rasrer layers the following:
>>> >
>>> > r.info map= name_of_raster_map
>>> >
>>> > 360 degree EW extent is exceeded by 1 cells
>>> > 360 degree EW extent is exceeded by 1 cells
>>> >
>>> > Which, following what you said before in your response I understand
makes it correct region, right?
>>>
>>> this region is correct considering the resolution with is now exactly
30 arc seconds.
>>>
>>> this region is not correct considering that 360 degree EW extent is
exceeded by 1 cell. The first column from 180:00:15W to 179:59:45W and the
last column from 179:59:45E to 180:00:15E spatially overlap, the first and
last column of DMSP are duplicates with regard to their location. If you
want to avoid this warning, you can set the region to w=179:59:45W
e=180:00:15E.
>>>
>>> Markus M
>>>
>>> >
>>> > Another question I wanted to ask is: how to know whether the
operation of intercallibration was correctly done, for tha I thought maybe
thare is the a place from where I can corroborate whether the min and max
values of each intercallibrated raster layer is correct?
>>> >
>>> >
>>> > I'm attaching the log of all the files I got from 'r.info' command in
it there appears always for the region '360 degree EW extent is exceeded by
1 cells' and  also the min and max value of each intercallibrated raster
 layer.
>>> >
>>> > So as to know if I got all the raster correctly intercallibrated
maybe checking if the min and max value for each intercallibrated
corresponds correctly is there a place where I can check that?
>>> >
>>> > 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
>>> >
>>> 

Re: [GRASS-user] question on Stray light Landsat 8 data

[Markus Metz]

Dear Gabriel,

On Tue, Aug 20, 2019 at 12:19 AM Gabriel Cotlier 
wrote:
>
> Dear Markus,
>
> Thanks a lot for the clarification and explanation, your response was
indeed helpful.
>
> I got for all maps in the mapset I used, for both the DMSP original
raster layers and the intercallibrated rasrer layers the following:
>
> r.info map= name_of_raster_map
>
> 360 degree EW extent is exceeded by 1 cells
> 360 degree EW extent is exceeded by 1 cells
>
> Which, following what you said before in your response I understand makes
it correct region, right?

this region is correct considering the resolution with is now exactly 30
arc seconds.

this region is not correct considering that 360 degree EW extent is
exceeded by 1 cell. The first column from 180:00:15W to 179:59:45W and the
last column from 179:59:45E to 180:00:15E spatially overlap, the first and
last column of DMSP are duplicates with regard to their location. If you
want to avoid this warning, you can set the region to w=179:59:45W
e=180:00:15E.

Markus M

>
> Another question I wanted to ask is: how to know whether the operation of
intercallibration was correctly done, for tha I thought maybe thare is the
a place from where I can corroborate whether the min and max values of each
intercallibrated raster layer is correct?
>
>
> I'm attaching the log of all the files I got from 'r.info' command in it
there appears always for the region '360 degree EW extent is exceeded by 1
cells' and  also the min and max value of each intercallibrated raster
 layer.
>
> So as to know if I got all the raster correctly intercallibrated maybe
checking if the min and max value for each intercallibrated corresponds
correctly is there a place where I can check that?
>
> 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 4:41 PM Markus Metz 
wrote:
>>
>>
>>
>> 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 message  is
>>
>> > 360 degree EW extent is exceeded by 1 cells
>>
>> considering the EW extents of 180:00:15W to 180:00:15E, that means that
the first column from 180:00:15W to 179:59:45W and the last column from
179:59:45E to 180:00:15E spatially overlap, the first and last column of
DMSP are duplicates with regard to their location. If you want to avoid
this warning, you can set the region to w=179:59:45W e=180:00:15E.
>>
>> Note that the recommended way to set a computational region to a raster
map is g.region rast=name_of_raster_map. After that, as for DMSP, you might
want to adjust the computational region to your needs, e.g. a smaller
region of interest, or restrict it to 360 degrees EW extent in case the
raster map is exceeding 360 degrees EW extent.
>>
>> HTH,
>>
>> Markus M
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> > while when I loaded a first file I defined a region as
>> >
>> >
>> > which is exactly I suppose the correct region for the DMSP data
then after loading the  other layers it appears:
>> >
>> > 360 degree EW extent is exceeded by 0.999827 cells
>> > 360 degree EW extent is exceeded by 1 cells
>> >
>> > Thanks a lot
>> > Gabriel
>> >
>> >
>> >
>> >
>> > On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier 
wrote:
>> >>
>> >> Hello, another question, regarding  i.nightlights.intercalibration,
can I run this code as python package/lbrary loading it from Spyder or
Jupiter Notebook instead of using GRASS interface, if so how is a
convenient  way to install   i.nightlights.intercalibration in python using
Spyder?
>> >> Thanks a lot.
>> >> Gabriel
>> >>
>> >> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier 
wrote:
>> >>>
>> >>> Dear Nikos.
>> >>> After a long time I'm trying to reproduce a routine I have for doing
intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to
me. I think is because the problem between the region of the layers 30 arc
sec should resolution be from 0.0083330 to 0.008, i.e.
exactly 30 arc-seconds? and the computational region be the same ? I got
st

Re: [GRASS-user] question on Stray light Landsat 8 data

[Markus Metz]

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 message  is

> 360 degree EW extent is exceeded by 1 cells

considering the EW extents of 180:00:15W to 180:00:15E, that means that the
first column from 180:00:15W to 179:59:45W and the last column from
179:59:45E to 180:00:15E spatially overlap, the first and last column of
DMSP are duplicates with regard to their location. If you want to avoid
this warning, you can set the region to w=179:59:45W e=180:00:15E.

Note that the recommended way to set a computational region to a raster map
is g.region rast=name_of_raster_map. After that, as for DMSP, you might
want to adjust the computational region to your needs, e.g. a smaller
region of interest, or restrict it to 360 degrees EW extent in case the
raster map is exceeding 360 degrees EW extent.

HTH,

Markus M

>
>
>
>
>
>
> while when I loaded a first file I defined a region as
>
>
> which is exactly I suppose the correct region for the DMSP data then
after loading the  other layers it appears:
>
> 360 degree EW extent is exceeded by 0.999827 cells
> 360 degree EW extent is exceeded by 1 cells
>
> Thanks a lot
> Gabriel
>
>
>
>
> On Sun, Aug 18, 2019 at 6:54 PM Gabriel Cotlier 
wrote:
>>
>> Hello, another question, regarding  i.nightlights.intercalibration, can
I run this code as python package/lbrary loading it from Spyder or Jupiter
Notebook instead of using GRASS interface, if so how is a convenient  way
to install   i.nightlights.intercalibration in python using Spyder?
>> Thanks a lot.
>> Gabriel
>>
>> On Sat, Aug 17, 2019 at 4:54 PM Gabriel Cotlier 
wrote:
>>>
>>> Dear Nikos.
>>> After a long time I'm trying to reproduce a routine I have for doing
intercallibratrion of DMSP 1992-2012 but for some reason It doesn't work to
me. I think is because the problem between the region of the layers 30 arc
sec should resolution be from 0.0083330 to 0.008, i.e.
exactly 30 arc-seconds? and the computational region be the same ? I got
stuck on how to set it to work... from the side of the region setting.
>>> However in addition my routing also has a for loop which does not work
ok as well.
>>> I would appreciate a lot of you can give it a look and tell me how to
make it work...
>>> Thanks  a lot in advance
>>> Kind regards,
>>> Gabriel
>>>
#-
>>> # complete routine for intercalliration of DSMP/OLS light stable product
>>>
>>> import grass.script as gscript
>>> import os
>>> import os,glob
>>>
>>> # get working directory
>>> print os.getcwd()
>>>
>>> # change working directory where raster files are
>>> os.chdir('C:\\Users\\Gabriel\\Documents\\grassdata\\lights')
>>>
>>> # see files in directory
>>> ls
>>>
>>> # import all raster files to grass --- here is a kind of problem...???
>>> for tif_file in glob.glob("*.tif"):
>>> new_rast = os.path.splitext(tif_file)[0]
>>> grass.run_command("r.in.gdal", flags="a", input=tif_file,
output=new_rast)
>>>
>>> # get info of one of the imported raster
>>> r.info map=F121996
>>>
>>> # run intercalliration algorithm
>>> i.nightlights.intercalibration
image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013
suffix=c model=elvidge2014 -t
>>>
>>> # correct general region adjust to raster file --- here the region is
exactly 30 arc for the raster as I could see
>>> g.region raster=F121996
>>>
>>> # cerate a list of rasters in the mapset
>>> # rastlist=grass.read_command("g.list",type="rast").split()
>>>  rasters = grass.read_command('g.list', type='raster').splitlines()
>>>
>>> # change working directory
>>> os.chdir('C:\\Users\\Gabriel\\Desktop\\out')
>>>
>>> # save rasters in mapset to file
>>> for raster in rasters:
>>> grass.run_command('r.out.gdal', input=raster, output=raster +
'.tiff', format='GTiff')
>>>
>>> On Wed, Aug 22, 2018 at 10:06 AM Gabriel Cotlier 
wrote:

 Dear Nikos,

 Thanks a lot for your answer and the orientation.
 The information and the link are very useful.
 Kind regards,
 Gabriel


 On Wed, Aug 22, 2018 at 5:19 AM Nikos Alexandris <
n...@nikosalexandris.net> wrote:
>
> * Gabriel Cotlier  [2018-08-21 12:00:24 -0300]:
>
> >Dear Nikos and GRASS users,
> >
> >I would like to ask if nonetheless the effect due to "stray light"
the
> >*i.landsat8.swlst* code for split window is still applicable to
Landsat 8
> >data and whether these error is specially visible on water bodies?
and
> >whether band 10 is 

Re: [GRASS-user] grass-7.9 does not find numpy

[Markus Metz]

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 still exits because
> it cannot find the GUI. wxPython-4.0.4 is installed.
>
> What might I still be missing? I need to resolve this as soon as possible
> and appeciate tests I can run to isolate the source of the problem.

Please post the full error message.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass-7.9 does not find numpy

[Markus Metz]

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, configure,
make
>
> Markus M,
>
> Now, wxPython-4.0.4 is installed and visible in
> /usr/lib64/python3.7/site-packages/ but a rebuilt/reinstalled grass79
still
> cannot find it:

the grass startup script was not updated to enforce python3, fixed in
master 83ba584e

git pull && make
should help

Markus M

>
> $ grass79
> Starting GRASS GIS...
> ERROR: wxGUI requires wxPython. No module named wx
> You can still use GRASS GIS modules in the command line or in Python.
> ERROR: Error in GUI startup. See messages above (if any) and if
necessary, please report this error to the GRASS developers.
> On systems with package manager, make sure you have the right GUI
package, probably named grass-gui, installed.
> To run GRASS GIS in text mode use the --text flag.
> Use '--help' for further options
>   grass79 --help
> See also: https://grass.osgeo.org/grass79/manuals/helptext.html
> Exiting...
>
> 'wx' is found in several places:
>
> # find / -name wx
> /usr/include/wx-3.0/wx
> /usr/include/wx-2.8/wx
> /usr/lib64/python3.7/site-packages/wx
> /usr/lib64/wx
> /usr/lib64/wx/include/gtk2-unicode-release-2.8/wx
> /usr/lib64/wx/include/gtk2-unicode-3.0/wx
> /home/rshepard/.grass7/wx
>
> Could grass be looking for wxPython rather than wxPython4?
>
> Regards,
>
> Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass-7.9 does not find numpy

[Markus Metz]

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 Python site (http://numpy.scipy.org)
for information on downloading source or binaries.
> Traceback (most recent call last):
>File "/usr/local/grass79/gui/wxpython/wxgui.py", line 172, in 
>  sys.exit(main())
>File "/usr/local/grass79/gui/wxpython/wxgui.py", line 159, in main
>  app = GMApp(workspaceFile)
>File "/usr/local/grass79/gui/wxpython/wxgui.py", line 53, in __init__
>  wx.App.__init__(self, False)
>File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py",
line 8628, in __init__
>  self._BootstrapApp()
>File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py",
line 8196, in _BootstrapApp
>  return _core_.PyApp__BootstrapApp(*args, **kwargs)
>File "/usr/local/grass79/gui/wxpython/wxgui.py", line 104, in OnInit
>  from lmgr.frame import GMFrame
>File "/usr/local/grass79/gui/wxpython/lmgr/frame.py", line 51, in

>  from lmgr.layertree import LayerTree, LMIcons
>File "/usr/local/grass79/gui/wxpython/lmgr/layertree.py", line 40, in

>  from wxplot.histogram import HistogramPlotFrame
>File "/usr/local/grass79/gui/wxpython/wxplot/histogram.py", line 23,
in 
>  import gui_core.wxlibplot as plot
>File "/usr/local/grass79/gui/wxpython/gui_core/wxlibplot.py", line
121, in 
>  import numpy as np
> ImportError: No module named numpy
>
> Numpy is installed (by pip) in /usr/lib64/python3.7/site-packages/.

but the gui is looking in /usr/lib64/python2.7/site-packages/

-> wrong python version

make sure wxpython for python3 is installed, make distclean, configure, make

HTH,

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error in r.bioclim

[Markus Metz]

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 use:
> >
> > r.bioclim \
> >   tmin=`g.list type=raster pattern="lst_minimum_??" separator=,` \
> >   tmax=`g.list type=raster pattern="lst_maximum_??" separator=,` \
> >   tavg=`g.list type=raster pattern="lst_average_??" separator=,` \
> >   output=lst_ \
> >   toutscale=1
> >
> > However, I get the following error, when the process reaches bio11 and
bio11:
> >
> > Mean temperature for each quarter year ...
> > BIO10 = Mean Temperature of Warmest Quarter,
> > BIO11 = Mean Temperature of Coldest Quarter ...
> > ERROR: Raster map not found
> > Traceback (most recent call last):
> >   File "/home/veroandreo/.grass7/addons/scripts/r.bioclim", line 618,
in 
> > main()
> >   File "/home/veroandreo/.grass7/addons/scripts/r.bioclim", line 316,
in main
> > method = 'maximum,minimum')
> >   File
"/home/veroandreo/software/grass77-dev/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 441, in run_command
> > return handle_errors(returncode, returncode, args, kwargs)
> >   File
"/home/veroandreo/software/grass77-dev/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 343, in handle_errors
> > returncode=returncode)
> > grass.exceptions.CalledModuleError: Module run None r.series input=
output=lst_bio10.18931,lst_bio11.18931 method=maximum,minimum ended with
error
> > Process ended with non-zero return code 1. See errors in the (error)
output.
> >
> > The input maps are there (12 Tmin, 12 Tmax and 12 Tavg), which is the
map it does not find then? Where do I find this (error) output??
>
> this error was introduced by Markus N with
>
https://github.com/OSGeo/grass-addons/commit/7eb1fc10fcc7e56e93444a37287602ff41ec6a15#diff-53570b3d7e95af6c262896a8d57e367e
>
> fixed in 7433d29b

another bug introduced with the same previous commit 7eb1fc1 fixed in
8858cf2b

Markus M
> >
> > Thanks in advance for any help
> > Vero
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error in r.bioclim

[Markus Metz]

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 type=raster pattern="lst_maximum_??" separator=,` \
>   tavg=`g.list type=raster pattern="lst_average_??" separator=,` \
>   output=lst_ \
>   toutscale=1
>
> However, I get the following error, when the process reaches bio11 and
bio11:
>
> Mean temperature for each quarter year ...
> BIO10 = Mean Temperature of Warmest Quarter,
> BIO11 = Mean Temperature of Coldest Quarter ...
> ERROR: Raster map not found
> Traceback (most recent call last):
>   File "/home/veroandreo/.grass7/addons/scripts/r.bioclim", line 618, in

> main()
>   File "/home/veroandreo/.grass7/addons/scripts/r.bioclim", line 316, in
main
> method = 'maximum,minimum')
>   File
"/home/veroandreo/software/grass77-dev/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 441, in run_command
> return handle_errors(returncode, returncode, args, kwargs)
>   File
"/home/veroandreo/software/grass77-dev/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 343, in handle_errors
> returncode=returncode)
> grass.exceptions.CalledModuleError: Module run None r.series input=
output=lst_bio10.18931,lst_bio11.18931 method=maximum,minimum ended with
error
> Process ended with non-zero return code 1. See errors in the (error)
output.
>
> The input maps are there (12 Tmin, 12 Tmax and 12 Tavg), which is the map
it does not find then? Where do I find this (error) output??

this error was introduced by Markus N with
https://github.com/OSGeo/grass-addons/commit/7eb1fc10fcc7e56e93444a37287602ff41ec6a15#diff-53570b3d7e95af6c262896a8d57e367e

fixed in 7433d29b

Markus M

>
> Thanks in advance for any help
> Vero
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Wrangling CityGML with GRASS ?

[Markus Metz]

Hi Peter,

On Thu, Aug 8, 2019 at 3:56 PM "Peter Löwe"  wrote:
>
> Hi Markus, all,
[...]
>
> For me, GDAL2.3.1 in GRASS refuses to accept the "GMLAS:"
from https://gdal.org/drivers/vector/gmlas.html: The driver requires
Xerces-C >= 3.1

You need to rebuild GDAL accordingly, but

> override for the import-driver:
>
> ogr2ogr -f GeoJSON SMALL.json GMLAS:SMALL.gml -oo
REMOVE_UNUSED_LAYERS=YES -oo REMOVE_UNUSED_FIELDS=YES -sql "SELECT * FROM
groundsurface"

apparently GMLAS is supported. What is the exact error message for "
GDAL2.3.1 in GRASS refuses to accept the "GMLAS:""?

Markus M
>
> --> if GDAL-4-GRASS is currently built without GMLAS-support, it would be
wortwhile to include it soonish (-> benefits:
https://inspire.ec.europa.eu/sites/default/files/presentations/gml_application_schema_made_easy_in_gdal_ogr_and_qgis_-_gmlas_driver_0.pdf)

>
> Otherwise, the standard GML-driver doesn't feature the REMOVE_xxx options:
> ogr2ogr -f GeoJSON SMALL.json SMALL.gml -oo REMOVE_UNUSED_LAYERS=YES -oo
REMOVE_UNUSED_FIELDS=YES -sql "SELECT * FROM groundsurface"
>
> Warning 6: driver 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
>
>
>
> 
>
>
> Gesendet: Donnerstag, 08. August 2019 um 15:15 Uhr
> Von: "Markus Metz" 
> An: "Peter Löwe" 
> Cc: grass-user 
> Betreff: Re: [GRASS-user] Wrangling CityGML with GRASS ?
>
>
> On Thu, Aug 8, 2019 at 2:59 PM "Peter Löwe"  wrote:
> >
> > Hello Markus, Stefan, all,
> >
> > thanks for all your advice. New challenges have emerged, as the dataset
is defined as a polyhedral surface:
> >
> > I upgraded to GRASS 7.6.1 which comes with GDAL 2.3.1.
> >
> > The data sources are official CityGML files provided by the German
Federal Agency for Cartographyand Geodesy (Bundesamt für Kartographie),
which have an ".xml"-extension.
> >
> > v.in.ogr -2 -o --o input=TEST.xml output=TEST01
> > throws several warnings and creates an empty vector without an
points/lines in it:
> >
> >  Warning 1: Unrecognized geometry type : 1015
 [<=== note this!]
> > No projection information available for layer 
> > Übersteuere die Überprüfung der Projektion.
> > Check if OGR layer  contains polygons...
> >  100%
> > WARNUNG: Vektorkarte  existiert bereits und wird überschrieben.
> > Creating attribute table for layer ...
> > Importing 1 features (OGR layer )...
> > WARNUNG: Skipping unsupported geometry type 'POLYHEDRALSURFACE'
  [<=== note this!]
>
> v.in.ogr could force-convert these polyhedral surfaces to multipolygons,
at the risk of getting garbage.
>
> The required change to v.in.ogr would be small, but it would be safer to
skip these unsupported feature types in order to avoid garbage output.
>
> Markus M
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Wrangling CityGML with GRASS ?

[Markus Metz]

On Thu, Aug 8, 2019 at 2:59 PM "Peter Löwe"  wrote:
>
> Hello Markus, Stefan, all,
>
> thanks for all your advice. New challenges have emerged, as the dataset
is defined as a polyhedral surface:
>
> I upgraded to GRASS 7.6.1 which comes with GDAL 2.3.1.
>
> The data sources are official CityGML files provided by the German
Federal Agency for Cartographyand Geodesy (Bundesamt für Kartographie),
which have an ".xml"-extension.
>
> v.in.ogr -2 -o --o input=TEST.xml output=TEST01
> throws several warnings and creates an empty vector without an
points/lines in it:
>
>  Warning 1: Unrecognized geometry type : 1015
 [<=== note this!]
> No projection information available for layer 
> Übersteuere die Überprüfung der Projektion.
> Check if OGR layer  contains polygons...
>  100%
> WARNUNG: Vektorkarte  existiert bereits und wird überschrieben.
> Creating attribute table for layer ...
> Importing 1 features (OGR layer )...
> WARNUNG: Skipping unsupported geometry type 'POLYHEDRALSURFACE'
[<=== note this!]

v.in.ogr could force-convert these polyhedral surfaces to multipolygons, at
the risk of getting garbage.

The required change to v.in.ogr would be small, but it would be safer to
skip these unsupported feature types in order to avoid garbage output.

Markus M

>  100%
> -
> Erstelle Topologie für die Vektorkarte ...
> Registriere Primitive...
> WARNUNG: Input data contains 3D features. Created vector is 2D only,
>  disable -2 flag to import 3D vector.
>
>
> This problem seems to be ogr/gdal related:
>
> ogrinfo -al TEST.xml
> describes the geometry as a POLYHEDRALSURFACE Z (((412033.466 5812969.869
...))).
>
> ogr2ogr -f "GML" TEST.gml TEST.xml  fails (some effect when trying other
target formats like CSV or ESRI shape:
> Warning 1: Unrecognized geometry type : 1015
> ERROR 6: Unsupported geometry type 3D PolyhedralSurface
> ERROR 1: Export of geometry to GML failed
> ERROR 1: Terminating translation prematurely after failed
> translation of layer Building (use -skipfailures to skip errors)
>
> There is GDAL documentation about surfaces (
https://gdal.org/development/rfc/rfc64_triangle_polyhedralsurface_tin.html),
but I couldn't find anything about transformations/pruning from 3D to 2D.
>
> The CGAL library appears to be capable to handle such surfaces, but
GIS-integration seems to be limited (https://www.cgal.org/).
>
> Ideas on how to proceed, anyone ?
>
> best,
> Peter
>
>
>
>
>
> 
>
>
> > Gesendet: Dienstag, 06. August 2019 um 14:46 Uhr
> > Von: grass-user-requ...@lists.osgeo.org
> > An: grass-user@lists.osgeo.org
> > Betreff: grass-user Digest, Vol 160, Issue 5
> >
> > Send grass-user mailing list submissions to
> >   grass-user@lists.osgeo.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >   https://lists.osgeo.org/mailman/listinfo/grass-user
> > or, via email, send a message with subject or body 'help' to
> >   grass-user-requ...@lists.osgeo.org
> >
> > You can 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..."
> >
> >
> > Today's Topics:
> >
> >1. Re: Problems starting grass 7.4.1 in ubuntu (Markus Metz)
> >2. Re: wms google (Micha Silver)
> >3. Re: Wrangling CityGML with GRASS ? (Stefan Blumentrath)
> >4. Re: Wrangling CityGML with GRASS ? (Peter Löwe)
> >5. Re: Wrangling CityGML with GRASS ? (Markus Metz)
> >
> >
> > --
> >
> > Message: 1
> > Date: Mon, 5 Aug 2019 22:32:12 +0200
> > From: Markus Metz 
> > To: Sebastián Dietrich 
> > Cc: grass-user 
> > Subject: Re: [GRASS-user] Problems starting grass 7.4.1 in ubuntu
> > Message-ID:
> >   
> > Content-Type: text/plain; charset="utf-8"
> >
> > On Mon, Aug 5, 2019 at 5:35 PM Sebastián Dietrich <
sebadietr...@gmail.com>
> > 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 "/usr/lib/grass74/gui/wxpython/wxgui.py", line 25, in 
> > > from core import globalvar
> > >   File "/usr/lib/grass74/gui/wxpython/core/globalvar.py",

Re: [GRASS-user] v.segment performance

[Markus Metz]

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
v.category option=add. So far so good, this leaves me with about 670,000
vector line segments.
>
> I want to find the midpoint of each of these line segments and create a
new Delaunay tessellation using the line segment midpoints as the vertices
in the new tessellation.

The addon v.centerpoint [1] should be much faster than v.segment to get
line midpoints.

Markus M

[1]
https://github.com/OSGeo/grass-addons/tree/master/grass7/vector/v.centerpoint

> I have prepared a rules file to feed into v.segment to do this, using the
50% distance offset.
>
> I ran v.segment with the verbose flag and the only output I received
after 90 minutes is ‘Using native format’ ;  I’m not sure if the process is
going to run forever, or if I just need to be more patient, or if I am
trying to process too many points for this tool -  this is my first time
ever using this module, so I don’t know what to expect. Does anyone have
any experience using large vectors with v.segment?
>
> I thought the program might give some more output as to what’s happening.
htop shows The program is using one core out of eight at 100% so I suppose
it’s working normally.
>
> Thanks for any hints,
>
> ~ Eric.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Wrangling CityGML with GRASS ?

[Markus Metz]

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 supported by GDAL 2.2+. However, in order to import GMLAS
properly, some tricks are needed (interleaved reading for non-sequential
layers, see
https://gdal.org/drivers/vector/gmlas.html#performance-issues-with-large-multi-layer-gml-files)
which are built into GRASS 7.6+.

> My colleagues have ingested CityGML datasets into R, which caused issues
with the vector-topology for individual buildings.

That's not related to the data format, but to the content: 3D polygons.
These are not supported in GRASS, when importing you need to convert the
data to 2D with v.in.ogr -2, otherwise you get corrupt topology. Maybe this
is also needed for R.

Markus M

> Also, we have to cope with significant amounts of CityGML datasets, which
would require very large amounts of RAM, if the processing is done in R.
Since GRASS locations are storage-effective AND GRASS handles vector
topologies well, I had hoped that someone already explored this approach
further :-)
>
> If this should be not the case (yet) we'll gladly report at one of next
years FOSS4G events.
>
> Best,
> peter
>
> 
>
>
> > Gesendet: Dienstag, 06. August 2019 um 11:13 Uhr
> > Von: "Stefan Blumentrath" 
> > An: "Peter Löwe" , "grass-user@lists.osgeo.org" <
grass-user@lists.osgeo.org>
> > Betreff: RE: [GRASS-user] Wrangling CityGML with GRASS ?
> >
> > Hi Peter,
> >
> > Not personally...
> > I would guess you would import CityGML through GDAL:
> >
https://3d.bk.tudelft.nl/svitalis/citygml/gdal/2017/07/24/messing-around-with-citygml-on-gdal-2.2.html
> > There you can create subsets and the like...
> >
> > What are you planning to do with it, roughly?
> >
> > Cheers
> > Stefan
> >
> >
> > -Original Message-
> > From: grass-user  On Behalf Of
"Peter Löwe"
> > Sent: torsdag 1. august 2019 11:10
> > To: grass-user@lists.osgeo.org
> > Subject: [GRASS-user] Wrangling CityGML with GRASS ?
> >
> > Hi list,
> >
> > I'm looking for information/howtos/etc. about how to deal with large
CityGML data sets using GRASS.
> >
> > Has anybody already explored this ?
> >
> > Best,
> > Peter
> >
> > 
> >
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
> >
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Problems starting grass 7.4.1 in ubuntu

[Markus Metz]

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 "/usr/lib/grass74/gui/wxpython/wxgui.py", line 25, in 
> from core import globalvar
>   File "/usr/lib/grass74/gui/wxpython/core/globalvar.py", line 39, in

> 'locale')).ugettext
> AttributeError: 'GNUTranslations' object has no attribute 'ugettext'
> [MÁSCARA ráster presente]
> GRASS 7.4.1 (EPSG5344):~/Documentos/grassdata >
>
> Can someone help with this issue?

GNUTranslations has an attribute ugettext only in Python2, not in Python3.
Make sure that the link "python" points to "python2", test with "python
--version"

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Points to area workflow

[Markus Metz]

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 1" in the boundary definition
>
> analysis_points.dat:
>
> VERTI:
> B 5 # There are 5 coordinates and no categories
>   -123.94 45.150100
>   -123.94 45.145400
>   -123.96 45.150100
>   -123.96 45.145400
>   -123.94 45.150100

--> remove
>   1 1
<--

--> change
> C 1
C 1 1
<--
>   -123.95 45.147500
>   1 1

you get then

B 5 # 5 coordinates and no categories
  -123.94 45.150100
  -123.94 45.145400
  -123.96 45.150100
  -123.96 45.145400
  -123.94 45.150100
C 1 1# 1 coordinate and one category
  -123.95 45.147500
  1 1

this conforms now to the GRASS ASCII vector format specification, in
particular

TYPE NUMBER_OF_COORDINATES [NUMBER_OF_CATEGORIES]

and should import successfully

Markus M

>
> GRASS now fails to import the data file:
>
> v.in.ascii in=analysis_points.dat out=analysis_corners for=standard --o
> WARNING: Error reading ASCII file: (unknown type) [ 1 1]
> ERROR: Import failed
>
> Grass seems to not like the layer and category number for the centroid as
> removing those for the boundary produces the same error.
>
> What am I still missing?
>
> Regards,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.proj: lat or lon limits exceeded

[Markus Metz]

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

>
> lon_lat/PERMANENT/PROJ_INFO has no geographic coordinates. The vector file
> has these corners:
> 45.150100, -123.94
> 45.145400, -123.94
> 45.145400, -123.96
> 45.150100, -123.96
> 45.150100, -123.94

the latitudes of -123.9x are smaller than -90, exceeding limits. Did you
swap easting and northing?

Markus M

>
> The project location's PROJ_INFO is:
>
> name: NAD_1983_HARN_Oregon_Statewide_Lambert_Feet_Intl
> datum: nad83harn
> ellps: grs80
> proj: lcc
> lat_1: 43
> lat_2: 45.5
> lat_0: 41.75
> lon_0: -120.5
> x_0: 39.99
> y_0: 0
> no_defs: defined
>
> The warning does not inform which location's limits are exceeded, and I
need
> to learn how to resolve this situation (and avoid future ones.)
>
> Regards,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.proj: lat or lon limits exceeded

[Markus Metz]

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 that proj 6 is not yet supported,
neither by gdal 2.x nor by grass 7.x.

Markus M


> ERROR: Unable to re-project vector map  from

>
> lon_lat/PERMANENT/PROJ_INFO has no geographic coordinates. The vector file
> has these corners:
> 45.150100, -123.94
> 45.145400, -123.94
> 45.145400, -123.96
> 45.150100, -123.96
> 45.150100, -123.94
>
> The project location's PROJ_INFO is:
>
> name: NAD_1983_HARN_Oregon_Statewide_Lambert_Feet_Intl
> datum: nad83harn
> ellps: grs80
> proj: lcc
> lat_1: 43
> lat_2: 45.5
> lat_0: 41.75
> lon_0: -120.5
> x_0: 39.99
> y_0: 0
> no_defs: defined
>
> The warning does not inform which location's limits are exceeded, and I
need
> to learn how to resolve this situation (and avoid future ones.)
>
> Regards,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Build error: git repo master

[Markus Metz]

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 hosts.
>
> $ locate libgeos
> /usr/lib/libgeos_c.so.1.11.2
> /usr/lib/libgeos.so
> /usr/lib/libgeos_c.la
> /usr/lib/libgeos-3.7.2.so
> /usr/lib/libgeos_c.so.1
> /usr/lib/libgeos.la
> /usr/lib/libgeos_c.so

how does this match with "gdalinfo looks for libgeos-3.7.1." ?

Markus M
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Build error: git repo master

[Markus Metz]

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 "gdalinfo --formats" working?
>
> Nope. gdalinfo looks for libgeos-3.7.1.

???
You wrote
"On my systems there's libgeos-3.7.2.so."

Is there also libgeos-3.7.1.so?

Markus M

>
> I thought I rebuilt proj, geos, and gdal on all hosts. I'll do so again
and
> see if this fixes gdalinfo and grass.
>
> Thanks,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Build error: git repo master

[Markus Metz]

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 there are two different GEOS installations, then remove
one
> > of them. Also check where libgeos.so is and where it points to.
>
> Markus M,
>
> After each build (or attempt) I run 'make distclean.'
>
> There's only geos-3.7.2 installed.
>
> On the 64-bit systems the libraries are in /usr/lib64/.
>
> libgeos.so points to libgeos-3.7.2.so
>
> so, I'll make a new softlink pointing libgeos-3.7.0.so to libgeos.so

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 "gdalinfo --formats" working?

Markus M

>
> Thanks,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Build error: git repo master

[Markus Metz]

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 help
figure out if there are two different GEOS installations, then remove one
of them. Also check where libgeos.so is and where it points to.

Markus M


>
> Should I make a symlink to -3.7.0 or fix it elsewhere?
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Build error: git repo master

[Markus Metz]

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.
>
> > It is defined in include/Make/... (I'm traveling and have no computer
> > available to check).
> > I think it is simply "error.log".
>
> Actually, there are errors in almost every source file. I tee'd the build
> process (82K xz compressed tarball) and copied the end to the attached
file
> which shows all the errors. Haven't see this before, only the occasional
> single file that bombed.

can you go into any of the subdirs listed, run make and paste the full
output?

I had the same error some hours ago, it was a library in a non-standard
place that caused the problem.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.overlay snapping

[Markus Metz]

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

Markus M

>
> I am using GRASS 7.4 trough the QGIS Processing Toolbox, in Arch Linux
and Grass 7.6 trough the QGIS Processing Toolbox in a Windows VM (since
getting this unexpected results I downgraded my Grass installation back to
7.4 in Linux)
>
> One common step in my workflow is to vectorize a raster (using v.to.rast)
and then overlay the result with an hexagonal grid.
>
> Since version 7.6, it seems that the result does snapping vertices of the
two overlapping features when they are too close to each other. Even if I
specify snapping = -1.
>
> I'm not sure if I am missing something or if I should file a bug report.
I put together some files that can be used to reproduce the error:
>
> - hexagons_ext.gpkg: an extract of the hexagonal grid
> - raster_ext.gpkg: an extract of the raster
> - overlay_ext_7.4.gpkg: overlay of both with the "and" operator, using
Grass 7.4, with the desired result
> - overlay_ext_7.6.gpkg: overlay result using Grass 7.6 containing
undesired snapping
> - errors.gpkg: points where snapping is occurring
>
> Any help is appreciated.
> Thanks,
> Stephane
>
> Download link:
> https://send.firefox.com/download/0a9efe8d5669941b/#mmdtLo-ZYMgSoORqeNMwkQ
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.li.mps

[Markus Metz]

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. Some areas in my raster have nodata, since i'm
not planning to consider those in my work. I created the configuration
file, reported below:
> SAMPLINGFRAME 0|0|1|1
> SAMPLEAREA 0.0|0.0|1.0|0.541221268982
>
> then i run the module over my raster, and here is the output:
> RESULT 1|-7.1291406991691
> I was not expecting this output, i can't figure out what's wrong.

A negative number for mean patch size does not make sense indeed. Can you
provide sample data to reproduce?

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Import gpkg point map

[Markus Metz]

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/ashalim_train_pts.gpkg
> > INFO: Open of `../GIS/Ashalim/ashalim_train_pts.gpkg'
> >   using driver `GPKG' successful.
> > 1: ashalim_train_pts (Point)
> > 2: layer_styles (None)
> >
> >
> > The style ??!!
> >
> >
> > I removed that "layer_styles" table from the gpkg db, and deleted the
entry from gpkg_contents, and now the import works.
> >
> > Who would have guessed ?
> >
> > I suppose that I should have specified the layer in v.import to avoid
this problem.
>
> Yes, specifying the layer should work.
>
> I have seen this layer_styles layer before in other GPKG files but don't
know what this is good for. GDAL documentation at
> https://gdal.org/drivers/vector/gpkg.html
> does not mention any style information.
>
>
> It comes from QGIS, where you can save a default layer styling directly
into the gpkg. Very convenient, but I never thought it would appear to
GRASS as a second layer without geometry or CRS.

This is not GRASS, it is OGR that recognizes it as a separate layer without
geometry or CRS. I guess ogr2ogr skips this layer because there are no
geometries in it.

In theory, v.in.ogr could skip empty OGR layers, but in practice it is not
always easy to get the feature count of a layer, it depends on the data
format. Sometimes, e.g. for OSM pbf, you need to read the whole OGR
datasource to figure out the number of features per layer.

In v.in.ogr, there are already a number of special cases for specific
OGR-supported formats, and I would like to keep these format-specific
treatments to a minimum, avoiding yet another special case for GPKG + empty
layer. Ideally, the GPKG driver of OGR would not expose such empty or
special layers.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Import gpkg point map

[Markus Metz]

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 vector. The polygons import fine, but the point vector fails
with:
> >
> > ERROR: Detected different projections of input layers. Input layers
must be
> >imported separately.
> >
> >
> > Then if I convert the gpkg to a shapefile, it works fine.
> >
> >
> > Any ideas what could be wrong? Here's the procedure, showing the
problem.
> >
> [...]
> >
> > # Now The point gpkg vector:
> >
> > ##
> >
> > micha@TP480:Ashalim$ ogrinfo ashalim_train_pts.gpkg ashalim_train_pts
>
> are there any other layers in ashalim_train_pts.gpkg?
> You can check with
> ogrinfo -so ashalim_train_pts.gpkg
>
>
> micha@TP480:code$ ogrinfo -so ../GIS/Ashalim/ashalim_train_pts.gpkg
> INFO: Open of `../GIS/Ashalim/ashalim_train_pts.gpkg'
>   using driver `GPKG' successful.
> 1: ashalim_train_pts (Point)
> 2: layer_styles (None)
>
>
> The style ??!!
>
>
> I removed that "layer_styles" table from the gpkg db, and deleted the
entry from gpkg_contents, and now the import works.
>
> Who would have guessed ?
>
> I suppose that I should have specified the layer in v.import to avoid
this problem.

Yes, specifying the layer should work.

I have seen this layer_styles layer before in other GPKG files but don't
know what this is good for. GDAL documentation at
https://gdal.org/drivers/vector/gpkg.html
does not mention any style information.

AFAICT, layers in a GPKG should contain vector geometries.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Import gpkg point map

[Markus Metz]

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
>imported separately.
>
>
> Then if I convert the gpkg to a shapefile, it works fine.
>
>
> Any ideas what could be wrong? Here's the procedure, showing the problem.
>
[...]
>
> # Now The point gpkg vector:
>
> ##
>
> micha@TP480:Ashalim$ ogrinfo ashalim_train_pts.gpkg ashalim_train_pts

are there any other layers in ashalim_train_pts.gpkg?
You can check with
ogrinfo -so ashalim_train_pts.gpkg

>
> # Try import
>
> micha@TP480:Ashalim$ v.import ashalim_train_pts.gpkg output=ashalim_pts
--o
> ERROR: Detected different projections of input layers. Input layers must
be
>imported separately.
> ERROR: Detected different projections of input layers. Input layers must
be
>imported separately.
> ERROR: Unable to create location from OGR datasource
>

There must be more than one layer in ashalim_train_pts.gpkg, maybe an empty
layer?

>
> If anyone wants the point and polygon gpkg files to test, I can share it.

For testing, I would only need the point gpkg file.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Fwd: Re: remove small islands from vector areas

[Markus Metz]

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, v.clean tool=rmarea also removes holes inside areas, at least it
should. It would be a bug if holes smaller than threshold are not removed.

Markus M
>
> Cheers
> Stefan
>
> -Original Message-
> From: grass-user  On Behalf Of Robert
Nuske
> Sent: fredag 21. juni 2019 13:49
> To: grass-user 
> Subject: [GRASS-user] Fwd: Re: remove small islands from vector areas
>
>
>
>
>  Weitergeleitete Nachricht 
> Betreff: Re: [GRASS-user] remove small islands from vector areas
> Datum: Fri, 21 Jun 2019 13:47:52 +0200
> Von: Robert Nuske 
> An: Stefan Blumentrath 
>
> Hi Stefan,
>
> as far as I understood does rmarea that remove small areas but not
islands (holes) within areas. At least i didn't find a way to remove
islands with v.clean.
>
> thanks
>robert
>
> Am 21.06.19 um 13:06 schrieb Stefan Blumentrath:
> > Hi Robert,
> >
> > Did you have a look at v.clean:
> > https://grass.osgeo.org/grass77/manuals/v.clean.html
> > with
> > tool=rmarea >
> >
> > Cheers
> > Stefan
> >
> > -Original Message-
> > From: grass-user  On Behalf Of
> > Robert Nuske
> > Sent: fredag 21. juni 2019 12:33
> > To: grass-user 
> > Subject: [GRASS-user] remove small islands from vector areas
> >
> > Dear Listers,
> >
> > sorry, it's me again.
> >
> > I want to remove islands smaller than a certain threshold from my
vector map or if that is not possible all islands.
> >
> > I found some trick on an old manual page of v.extract. But this does
not work anymore. Is there a new trick?
> >
> >
> > thnaks
> >robert
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
> >
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Grass 7.6 i.segment minsize working?

[Markus Metz]

Hi Jamille,

On Tue, Jun 18, 2019 at 10:40 PM Jamille Haarloo 
wrote:
>
> Thank you Markus,
>
> I used this data:
https://drive.google.com/file/d/1xrLJY5aZLKE-ja51wKRX_CKKcUtIiy16/view?usp=sharing
(excluding band 6. I used band 1-5 as group)
>
> The parameters:
> i.segment.hierarchical group=S2bands_VV@LUPS thresholds=0.1, 0.2
output=hier_segmS2 minsizes=20 memory=4000 iterations=30
>
> i.segment --overwrite group="S2bands_VV" output="SegmS2_02_20"
band_suffix="Modified" threshold=0.2 radius=1.5 method="region_growing"
similarity="euclidean" minsize=20 memory=4000 iterations=50 goodness=
"goodn_of_fit_SegmS2_02_20"
>
> g.region -p

> projection: 1 (UTM)
> zone:   21
> datum:  wgs84
> ellipsoid:  wgs84
> north:  620222.920747
> south:  617573.079721
> west:   782605.544297
> east:   785903.817009
> nsres:  0.49997
> ewres:  0.49996555
> rows:   5300
> cols:   6597
> cells:  34964100

the region settings don't make sense because the resolution if the input
data is 10 meter, not 0.49997 or 0.49996555. That means one original cell
is converted to appr. 400 cells in the current region. If you really want
to work with a resolution of appr. 0.5, you need to find a reasonable way
to resample the 10 meter input data to 0.5 meter. I don't know a method to
resample these input data to 0.5 meter resolution 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 you. Where do you see segments of just one pixel?

Markus M
>
>
> On Tue, Jun 18, 2019 at 5:04 PM Markus Metz 
wrote:
>>
>>
>>
>> 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
were indicated. The final run with minsize 20 created 8247 segments.
>> > There were no errors nor warnings, and I couldn't find the i.segment
script to review it.
>>
>> It is here:
>> https://github.com/OSGeo/grass/tree/releasebranch_7_6/imagery/i.segment
>>
>> > I also tried with a minsize of one (1). The result looks similar with
even less segments created - a total of  8160.
>> > I tried with Grass Gis 7.6.0 and 7.6.1(download of yesterday).
>>
>> I tested in the North Carolina sample dataset with
>> g.region -p rast=lsat7_2002_10
>>
>> using default minsize 1
>> i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40
thresh=0.05 out=lsat7_2002_min1
>> --> i.segment complete. Number of segments created: 29399
>>
>> r.info -r lsat7_2002_min1
>> min=1
>> max=29399<-- as expected
>>
>> using minsize=20
>> i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40
thresh=0.05 out=lsat7_2002_min20 minsize=20
>> --> i.segment complete. Number of segments created: 2114
>>
>> r.info -r lsat7_2002_min20
>> min=1
>> max=2114<-- as expected
>>
>> r.stats -c lsat7_2002_min20 | sort -k 2n | head
>> 1025 20
>> 1081 20
>> 109 20
>> 1117 20
>> 1220 20
>> 1305 20
>>
>> The given minimum segment size is in this test respected.
>>
>> Can you provide test data, region settings and parameters for i.segment
to reproduce?
>>
>> Markus M
>>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] import 3-dimension band from Hdf file (MODIS)

[Markus Metz]

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 bands:
gdalinfo  MCD19A2.A2018302.h19v05.006.2018311184807.hdf
...
Subdatasets:

SUBDATASET_1_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid1km:Optical_Depth_047
  SUBDATASET_1_DESC=[4x1200x1200] Optical_Depth_047 grid1km (16-bit integer)

SUBDATASET_2_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid1km:Optical_Depth_055
  SUBDATASET_2_DESC=[4x1200x1200] Optical_Depth_055 grid1km (16-bit integer)

SUBDATASET_3_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid1km:AOD_Uncertainty
  SUBDATASET_3_DESC=[4x1200x1200] AOD_Uncertainty grid1km (16-bit integer)

SUBDATASET_4_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid1km:FineModeFraction
  SUBDATASET_4_DESC=[4x1200x1200] FineModeFraction grid1km (16-bit integer)

SUBDATASET_5_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid1km:Column_WV
  SUBDATASET_5_DESC=[4x1200x1200] Column_WV grid1km (16-bit integer)

SUBDATASET_6_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid1km:AOD_QA
  SUBDATASET_6_DESC=[4x1200x1200] AOD_QA grid1km (16-bit unsigned integer)

SUBDATASET_7_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid1km:AOD_MODEL
  SUBDATASET_7_DESC=[4x1200x1200] AOD_MODEL grid1km (8-bit unsigned integer)

SUBDATASET_8_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid1km:Injection_Height
  SUBDATASET_8_DESC=[4x1200x1200] Injection_Height grid1km (32-bit
floating-point)

SUBDATASET_9_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid5km:cosSZA
  SUBDATASET_9_DESC=[4x240x240] cosSZA grid5km (16-bit integer)

SUBDATASET_10_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid5km:cosVZA
  SUBDATASET_10_DESC=[4x240x240] cosVZA grid5km (16-bit integer)

SUBDATASET_11_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid5km:RelAZ
  SUBDATASET_11_DESC=[4x240x240] RelAZ grid5km (16-bit integer)

SUBDATASET_12_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid5km:Scattering_Angle
  SUBDATASET_12_DESC=[4x240x240] Scattering_Angle grid5km (16-bit integer)

SUBDATASET_13_NAME=HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid5km:Glint_Angle
  SUBDATASET_13_DESC=[4x240x240] Glint_Angle grid5km (16-bit integer)

> My problem is that each band has 3 dimensions (x-y-z : 1200x1200x4)
> The z dimension corresponds to the orbit (Aqua or Terra, 2 daily overpass
each). I would like to work with them separately.

each subdataset has 4 bands (Aqua or Terra, 2 daily overpass each), e.g.
for the first subdataset
gdalinfo
HDF4_EOS:EOS_GRID:"MCD19A2.A2018302.h19v05.006.2018311184807.hdf":grid1km:Optical_Depth_047
...
Band 1 Block=1200x833 Type=Int16, ColorInterp=Gray
  Description = AOD at 0.47 micron
  NoData Value=-28672
  Offset: 0,   Scale:0.001
Band 2 Block=1200x833 Type=Int16, ColorInterp=Gray
  Description = AOD at 0.47 micron
  NoData Value=-28672
  Offset: 0,   Scale:0.001
Band 3 Block=1200x833 Type=Int16, ColorInterp=Gray
  Description = AOD at 0.47 micron
  NoData Value=-28672
  Offset: 0,   Scale:0.001
Band 4 Block=1200x833 Type=Int16, ColorInterp=Gray
  Description = AOD at 0.47 micron
  NoData Value=-28672
  Offset: 0,   Scale:0.001

> When I try to open the file using r.in.gdal I get an error 'The band does
not exist' (I guess the problem is the 3rd dimension...)

for r.in.gdal, you need to use the subdataset as input

HTH,

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Densify vertices in polygon

[Markus Metz]

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 ground: neither entirely circumscribing
> (larger than original polygon) nor inscribing (smaller than original
> polygon) the polygon. I love that behavior. But snakes only works with
> the available vertices and does not generate new vertices => quite rough
> outlines.
>
> So i thought it would be a good idea to densify the vertices of the
> polygon before the generalization. Create new vertices with distance x
> on the boundary of the polygon. But couldn't find a function in GRASS
> doing that.

v.split -n should do exactly this: add new vertices with distance x:
length=x
The -n flag causes new vertices to be added with splitting the
lines/boundaries.

>
> I would love any hints on generalization in general and on how to
> densify my vertices.

Apart from the manual of v.generalize, there is a tutorial at
https://grasswiki.osgeo.org/wiki/V.generalize_tutorial
(maybe not completely up to date)

HTH,

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Grass 7.6 i.segment minsize working?

[Markus Metz]

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
were indicated. The final run with minsize 20 created 8247 segments.
> There were no errors nor warnings, and I couldn't find the i.segment
script to review it.

It is here:
https://github.com/OSGeo/grass/tree/releasebranch_7_6/imagery/i.segment

> I also tried with a minsize of one (1). The result looks similar with
even less segments created - a total of  8160.
> I tried with Grass Gis 7.6.0 and 7.6.1(download of yesterday).

I tested in the North Carolina sample dataset with
g.region -p rast=lsat7_2002_10

using default minsize 1
i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40
thresh=0.05 out=lsat7_2002_min1
--> i.segment complete. Number of segments created: 29399

r.info -r lsat7_2002_min1
min=1
max=29399<-- as expected

using minsize=20
i.segment group=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40
thresh=0.05 out=lsat7_2002_min20 minsize=20
--> i.segment complete. Number of segments created: 2114

r.info -r lsat7_2002_min20
min=1
max=2114<-- as expected

r.stats -c lsat7_2002_min20 | sort -k 2n | head
1025 20
1081 20
109 20
1117 20
1220 20
1305 20

The given minimum segment size is in this test respected.

Can you provide test data, region settings and parameters for i.segment to
reproduce?

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] too many categories: buffer overflow

[Markus Metz]

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 buffer overflow. This is a hard one to search
for with GRASS GIS because the word "buffer" and "overflow" appear
throughout as in r.buffer and overflowing weirs, etc. but I'm referring to
the C-code error type of buffer oveflow:
>
> r.to.vect -v input=basins output=basins type=area
>
> DBMI-SQLite driver error:
> Error in sqlite3_step():
> UNIQUE constraint failed: basins.cat
>
> ERROR: Unable to insert into table: insert into basins values (
>-2137121269, '(Category -2137121269)')

This is close to the 32 bit signed integer limit, but not yet there, the
lower limit for raster maps of type CELL is at  −2,147,483,648

The error "UNIQUE constraint failed: basins.cat" indicates that the given
category already exists. Another issue is that negative categories are not
allowed for vectors. Yet another issue is that basin numbers should be all
positive, indicating that integer overflow occurred when creating the
raster map basins, which is probably the root of this problem. What is the
range of values in the raster map basins (r.info -r basins) and how was it
created?

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.hazard.flood extension

[Markus Metz]

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 worked only in projected coordinate system.
>> >
>> > 1) should be mentioned in manual at least
>>
>> +1 - TODO
>
>
> Done
>>
>>
>> > >> Traceback (most recent call last):
>> > >> File "/home/lara/.grass7/addons/scripts/r.hazard.flood", line 145,
in 
>> > >> sys.exit(main())
>> > >> File "/home/lara/.grass7/addons/scripts/r.hazard.flood", line 78,
in main
>> > >> resolution = (float(dict_region['nsres']) +
float(dict_region['ewres']))/2
>> > >> ValueError: invalid literal for float(): 0:00:00.17656
>> >
>> > 2) should faill more gracefully. LL location is not supported.
>>
>> https://github.com/OSGeo/grass-addons/pull/4
>
A simple solution would be
dict_region = grass.region()
instead of
info_region = grass.read_command('g.region', flags = 'p')
dict_region = grass.parse_key_val(info_region, ':')

but that does not solve the problem of resolution being in degrees. For ll,
you would need to get the resolution for each raster row separately, or
estimate with
r.mapcalc "ll_resolution = sqrt(area())"
which probably doesn't make sense for higher latitudes.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Question about isnull() in map algebra

[Markus Metz]

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 output=ndvi_cloud \
> expression="if(isnull(cloud), null(), float(b8 - b4) / ( b8 + b4 ))" \
> basename=ndvi_cloud nproc=3
>
> what happens if there is no cloud mask at all for a certain map? In this
case NDVI should be taken as is. Instead, to my understanding, what happens:
>
> if(isnull(cloud), null()
>
> If cloud map is not found (meaning there is no cloud detected),
isnull(cloud)=True, so the NDVI resulting map is null too. Please correct
me if I'm wrong.

the cloud masks are apparently created with "sentinel-cloud-mask.py" which
requires an AOI vector as input, and a cloud mask is always generated: if
there are no clouds or no cloud mask, only the AOI is used as mask.

from a quick glance at "sentinel-cloud-mask.py"

Markus M

>> Thanks
>
> --
> Margherita Di Leo
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

[Markus Metz]

On Wed, May 22, 2019 at 3:11 PM Veronica Andreo 
wrote:
>
> Dear all,
>
> thanks again for your answers. I found an easier way, use -c flag in
v.in.ogr seems to not build topology of overlapping areas and then
v.rast.stats does not complain.
>
> However, if one builds buffer 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 bit of an overkill for such a common
task in GIS. Couldn't v.buffer have a -c flag as v.in.ogr so when
overlapping of buffer areas is fine the topology is not built and one would
get just one area per input point? Would that be possible?

In short, no.

The reason is that with a topological vector model, areas are constructed
from boundaries and centroids. If you use the -c flag of v.in.ogr and there
are polygons that overlap to a large degree or completely, it is not
possible to find a centroid for each topological area, i.e. the overlapping
input polygons can not be properly represented with a topological model
when using the -c flag. As soon as you get incorrect boundaries and/or
duplicate centroids when building topology, results are wrong.

Markus M

>
> cheers,
> Vero
>
>
>
> El jue., 16 may. 2019 a las 11:27, Moritz Lennert (<
mlenn...@club.worldonline.be>) escribió:
>>
>> On 16/05/19 03:11, 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 overlap, and it is just fine that they overlap. I just want one
>> > centroid per area to be able to get one value per original area.
>> >
>> > I tested your solution, @Micha (thanks much for your time!), but it
>> > gives me 4 values, and I need 3. Moreover, I can no longer recognize
>> > which polygon is which since v.db.select for layer 3 reports cats from
1
>> > to 4, but d.vect shows something different (I'd assume 2/3 has become
>> > 4?). See screenshot below.
>>
>> To see the cat values of layer 3 you have to indicate that layer in the
>> label_layer parameter (Labels tab).
>>
>> You can also see the correspondance between the two layers with
>>
>> v.category polys_3layers op=print layer=1,3
>>
>> >
>> > So, is it possible somehow to keep my 3 original polygons? And how can
I
>> > get raster values for my original 3 polygons in GRASS? Or is it that
>> > this is not allowed by topology?
>>
>> This depends on how you want to get raster values. If v.what.rast at the
>> location of the centroid is all you need than Micha's solution should
work.
>>
>> If you need v.rast.stats then you either have to use Markus' suggestion,
>> or you use Micha's approach running v.rast.stats on layer three and then
>> use some magic to transform the output of the above v.category call to a
>> correspondance table between layer. Something like this
>>
>> import grass.script as g
>> for feature in g.read_command('v.category',
>>   input_='polys_3layers',
>>   op='print',
>>layer=[3,1]).splitlines():
>>   cat1 = feature.split('|')[0]
>>   cats2 = feature.split('|')[1].split('/')
>>   for cat2 in cats2:
>>   print cat1, cat2
>>
>> This correspondance table could then be used to aggregate the raster
>> stats per (original) polygon in SQL. This could be the easily put into
>> an addon module.
>>
>> Moritz
>>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Markus Metz]

Hi Eric,

On Wed, May 22, 2019 at 6:01 PM Patton, Eric (NRCan/RNCan) <
eric.pat...@canada.ca> wrote:
>
> Thanks for that info. So would a suitable strategy be to try re-synching
 Grass from git,

yes, with "git pull"

then compiling and building with proj 6.1, and if that fails, 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 22, 2019 12:57
> To: Patton, Eric (NRCan/RNCan) 
> Cc: grass-user@lists.osgeo.org
> Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
>
>
>
>
>
> On Wed, May 22, 2019 at 5:33 PM Patton, Eric (NRCan/RNCan) <
eric.pat...@canada.ca> wrote:
> >
> > Markus -
> >
> > Yes, I am using proj 6.0.0 – built with no errors.
>
>
>
> be aware that GRASS might compile with PROJ 6, but it is not working, too
much has changed from PROJ 5 and all those changes are not yet considered
in GRASS. Most importantly, coordinate transformations might produce wrong
results.
>
>
>
> Furthermore, GRASS will most likely not support PROJ 6.0, only PROJ 6.1+,
because of bug fixes and important new functionality.
>
> >
> > I believe I checked out master with ‘git clone
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 Neteler 
> > Cc: Patton, Eric (NRCan/RNCan) ;
grass-user@lists.osgeo.org
> > Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
> >
> >
> >
> >
> >
> > 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 /usr/local/grass/lib/proj:
> > > >
> > > > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> > > > do_proj.c: In function ‘GPJ_init_transform’:
> > > > do_proj.c:136:6: error: expected ‘}’ before ‘else’
> > > >   else {
> > > >   ^~~~
> > > > do_proj.c: At top level:
> > > > do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
> > > >  if (info_trans->pj == NULL)
> > > >  ^~
> > > > do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
> > > >  if (info_trans->pj == NULL) {
> > > >  ^~
> > > > do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘->’ token
> > > >  info_trans->m

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Markus Metz]

On Wed, May 22, 2019 at 5:33 PM Patton, Eric (NRCan/RNCan) <
eric.pat...@canada.ca> wrote:
>
> Markus -
>
> Yes, I am using proj 6.0.0 – built with no errors.

be aware that GRASS might compile with PROJ 6, but it is not working, too
much has changed from PROJ 5 and all those changes are not yet considered
in GRASS. Most importantly, coordinate transformations might produce wrong
results.

Furthermore, GRASS will most likely not support PROJ 6.0, only PROJ 6.1+,
because of bug fixes and important new functionality.
>
> I believe I checked out master with ‘git clone
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 Neteler 
> Cc: Patton, Eric (NRCan/RNCan) ;
grass-user@lists.osgeo.org
> Subject: Re: [GRASS-user] Multiple errors building Grass 7.7svn
>
>
>
>
>
> 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 /usr/local/grass/lib/proj:
> > >
> > > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > > gcc  -g -O2  -fPIC
 -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> > > do_proj.c: In function ‘GPJ_init_transform’:
> > > do_proj.c:136:6: error: expected ‘}’ before ‘else’
> > >   else {
> > >   ^~~~
> > > do_proj.c: At top level:
> > > do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
> > >  if (info_trans->pj == NULL)
> > >  ^~
> > > do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
> > >  if (info_trans->pj == NULL) {
> > >  ^~
> > > do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘->’ token
> > >  info_trans->meters = 1.;
> > >^~
> > > do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘->’ token
> > >  info_trans->zone = 0;
> > >^~
> > > do_proj.c:169:23: error: expected ‘)’ before ‘->’ token
> > >  sprintf(info_trans->proj, "pipeline");
> > >^~
> > > do_proj.c:180:5: error: expected identifier or ‘(’ before ‘return’
> > >  return 1;
> > >  ^~
> > > do_proj.c:181:1: error: expected identifier or ‘(’ before ‘}’ token
> > >  }
> > >  ^
> > > ../../include/Make/Compile.make:32: recipe for target
'OBJ.x86_64-pc-linux-gnu/do_proj.o' failed
> > > make: *** [OBJ.x86_64-pc-linux-gnu/do_proj.o] Error 1
> > > make: *** Waiting for unfinished jobs
> >
> > ok, there seems to be a problem with the PROJ installation.
>
>
>
> No, it's a problem with the #ifdef's in do_proj.c accounting for
different versions of PROJ
>
> >
>
> > Which proj version do you use? Please post the names of the related
> > packages here which you have installed (so that we see the precise
> > version names).
>
>
>
> This must be PROJ 6.
>
>
>
> do_proj.c should be fixed in master 7c3e8de:
>
>
https://github.com/OSGeo/grass/commit/7c3e8de11b877f7c6240b5f94868ec27464d6c9f
>
>
>
> Markus M
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Multiple errors building Grass 7.7svn

[Markus Metz]

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 /usr/local/grass/lib/proj:
> >
> > test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-gnu
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/convert.o -c convert.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/datum.o -c datum.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/do_proj.o -c do_proj.c
> > gcc  -g -O2  -fPIC  -I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include-I/usr/local/include
-DPACKAGE=\""grasslibs"\"
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include
-I/usr/local/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/proj\"
-o OBJ.x86_64-pc-linux-gnu/ellipse.o -c ellipse.c
> > do_proj.c: In function ‘GPJ_init_transform’:
> > do_proj.c:136:6: error: expected ‘}’ before ‘else’
> >   else {
> >   ^~~~
> > do_proj.c: At top level:
> > do_proj.c:160:5: error: expected identifier or ‘(’ before ‘if’
> >  if (info_trans->pj == NULL)
> >  ^~
> > do_proj.c:162:5: error: expected identifier or ‘(’ before ‘if’
> >  if (info_trans->pj == NULL) {
> >  ^~
> > do_proj.c:167:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘->’ token
> >  info_trans->meters = 1.;
> >^~
> > do_proj.c:168:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘->’ token
> >  info_trans->zone = 0;
> >^~
> > do_proj.c:169:23: error: expected ‘)’ before ‘->’ token
> >  sprintf(info_trans->proj, "pipeline");
> >^~
> > do_proj.c:180:5: error: expected identifier or ‘(’ before ‘return’
> >  return 1;
> >  ^~
> > do_proj.c:181:1: error: expected identifier or ‘(’ before ‘}’ token
> >  }
> >  ^
> > ../../include/Make/Compile.make:32: recipe for target
'OBJ.x86_64-pc-linux-gnu/do_proj.o' failed
> > make: *** [OBJ.x86_64-pc-linux-gnu/do_proj.o] Error 1
> > make: *** Waiting for unfinished jobs
>
> ok, there seems to be a problem with the PROJ installation.

No, it's a problem with the #ifdef's in do_proj.c accounting for different
versions of PROJ
>
> Which proj version do you use? Please post the names of the related
> packages here which you have installed (so that we see the precise
> version names).

This must be PROJ 6.

do_proj.c should be fixed in master 7c3e8de:
https://github.com/OSGeo/grass/commit/7c3e8de11b877f7c6240b5f94868ec27464d6c9f

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] fixing overlapping areas with snap and min_area

[Markus Metz]

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
>
> ...
>
> -
> 139375 input polygons
> Total area: 1.87116E+11 (713211 areas)
> Overlapping area: 465.913 (142064 areas)
> Area without category: 1.0631E+09 (137984 areas)
> -
> Copying features...
>
> Building topology for vector map ...
> Registering primitives...
> Building areas...
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
> ```
>
> After several hours testing different values of snap and min_area, I have
come up with the following:
>
> ```
> v.in.ogr input=~/path/to/data/ output=soils_omafra snap=4.52e-07
min_area=10.0
>
> ...
>
> -
> 138109 input polygons
> Total area: 1.87116E+11 (138565 areas)
> Overlapping area: 34.3593 (4 areas)
> Area without category: 1.0631E+09 (421 areas)
> -
>
> [no warnings reported]
> ```
>
> If I increase snap any more I start creating additional areas, so I don't
think I can automatically get rid of the remaining 4 areas.
>
> However, when I plot those areas and look at them, they are below the
min_area threshold I've set:
>
> ```
> d.what.vect map=soils_omafra
>
> ...
> soils_omafra@PERMANENT:
> Type: Area
> Sq_Meters: 6.307
> Hectares: 0.001
> Acres: 0.002
> Sq_Miles: 0.0
> Layer: 2
> Category: 2
> ...
> ```
>
> My map is in a lat-long projection, and the map unit is meters. I thought
setting min_area=10.0 would drop all areas smaller than 10 sq meters, but
my problem areas here are only 6.3 sq meters?

Maybe the documentation needs some clarification: the min_area applies to
input polygons, not to output areas, i.e. input polygons smaller than
min_area are dropped. If you want to get rid off output areas smaller than
min_area=10, you need to use v.clean tool=rmarea threshold=10.
>
> Have I misunderstood what min_area does, or am I setting it incorrectly?
I notice that the default is 0.0001, which seems really small if the units
is actually meters.

The purpose of min_area is to filter out noise in the input.
>
> More generally, I'm not sure how critical these overlapping areas are, or
when I can safely ignore them. For my current project, I'm going to use the
imported polygons to create rasters for analysis in R.

There is no general answer if these overlapping areas are critical or not,
it depends mostly on whether overlapping areas are allowed at all.

Markus M
>
> Thank you for your time,
>
> Tyler
>
> --
> plantarum.ca
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

[Markus Metz]

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 overlap, and it is just fine that they overlap. I just want one
centroid per area to be able to get one value per original area.
>
> I tested your solution, @Micha (thanks much for your time!), but it gives
me 4 values, and I need 3. Moreover, I can no longer recognize which
polygon is which since v.db.select for layer 3 reports cats from 1 to 4,
but d.vect shows something different (I'd assume 2/3 has become 4?). See
screenshot below.
>
> So, is it possible somehow to keep my 3 original polygons? And how can I
get raster values for my original 3 polygons in GRASS? Or is it that this
is not allowed by topology?

in this example, you get 4 areas and 3 different categories. The
overlapping part is represented as a small area with 2 categories. You can
restore the original polygons with e.g. v.extract type=area cat=1,
iterating over categotry values. If you want to get raster values for the
original polygons, you need to v.extract each category, rasterize it to
create a MASK, run r.univar and upload that value to the original vector.
v.rast.stats does not work here because it assumes that each area has only
one category value.

For point queries using centroids, I think Micha's solution is quite
elegant.

HTH,

Markus M
>
> best,
> Vero
>
>
>
> El mié., 15 may. 2019 a las 12:04, Micha Silver ()
escribió:
>>
>>
>> On 15/05/2019 0:46, Veronica Andreo wrote:
>>
>> Hi all,
>>
>> I was working today with a very simple vector map which corresponds to
clusters (circular polygons) that overlap and it is just fine that they
overlap. So, i received a shapefile with 3 of these clusters. Two of them
overlaped. When I import them into GRASS with v.import I get an extra
centroid and area where 2 of the polygons overlap.
>>
>> Problem arises when I want to query a raster map with those polygons
since originally the attribute table contained only 3 polygons (which is
just fine). However, v.what.rast will only upload values for 2 of those
three polygons because it finds 2 centroids with the same category, AFAIU.
>>
>>
>> Here's how to get the raster values for all polygons (including those
which are overlaps). It involves the somewhat non-intuitive process of
creating another layer. I imported a simple polygon shapefile with three
overlapping areas. Here are the categories:
>>
>>
>> micha@TP480:~$ v.category polys opt=report
>> Layer/table: 1/polys
>> type   countminmax
>> point  0  0  0
>> line   0  0  0
>> boundary   0  0  0
>> centroid  12  1  3
>> area   0  0  0
>> face   0  0  0
>> kernel 0  0  0
>> all   12  1  3
>> Layer: 2
>> type   countminmax
>> point  0  0  0
>> line   0  0  0
>> boundary   0  0  0
>> centroid   4  2  3
>> area   0  0  0
>> face   0  0  0
>> kernel 0  0  0
>> all4  2  3
>>
>>
>> So, as you found, you get two layers, with all original areas split up
at overlaps in layer 1, and just the overlap areas in layer 2.  Now add a
third layer, with new category values (option=add):
>>
>>
>> micha@TP480:~$ v.category polys option=add layer=3 out=polys_3layers
>>
>> Layer/table: 1/polys_3layers
>> type   countminmax
>> point  0  0  0
>> line   0  0  0
>> boundary   0  0  0
>> centroid  12  1  3
>> area   0  0  0
>> face   0  0  0
>> kernel 0  0  0
>> all   12  1  3
>> Layer: 2
>> type   countminmax
>> point  0  0  0
>> line   0  0  0
>> boundary   0  0  0
>> centroid   4  2  3
>> area   0  0  0
>> face   0  0  0
>> kernel 0  0  0
>> all4  2  3
>> Layer: 3
>> type   countminmax
>> point  0  0  0
>> line   0  0  0
>> boundary   0  0  0
>> centroid   7  1  7
>> area   0  0  0
>> face   0  0  0
>> kernel 0  0  0
>> all7  1  7
>>
>>
>> This gives me three layers, and the new layer 3 has individual cat
values