Re: [GRASS-dev] [GRASS GIS] #2499: GRASS70: v.in.ogr in does not handle "nan" in attribute tables properly

[GRASS GIS]

#2499: GRASS70: v.in.ogr in does not handle "nan" in attribute tables properly
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.2
 Component:  Vector   |Version:  unspecified
Resolution:   |   Keywords:  v.in.ogr, DBMI, SQLite, nan
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 Is this still relevant?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.2

[Markus Neteler]

Hi,

On Thu, Nov 14, 2019 at 6:39 PM Markus Neteler  wrote:
>
> Hi devs,
>
> some important issues have been discovered:
>
> - gdal300.dll/libgdal.so.26. were not registered in lib/raster/gdal.c
> - missing backport of https://github.com/OSGeo/grass/pull/155 (now done)

In addition
- [OSGeo/grass] libproj (#252) - important PROJ/datum fixes
- many wxGUI fixes

In there are no objections, I'll prepare 7.8.2 final tomorrow.

Markus

> Just started:
> https://trac.osgeo.org/grass/wiki/Release/7.8.2-News
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [OSGeo/grass] libproj (#252)

[Markus Metz]

On Tue, Dec 10, 2019 at 9:27 AM Markus Neteler  wrote:
>
> Hi,
>
> On Mon, Dec 9, 2019 at 11:32 PM Helmut Kudrnovsky <
notificati...@github.com> wrote:
>>
>> After backporting, another RC for 7.8.2 needed?
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub, or unsubscribe.
>
>
> ... I would suggest to leave it for 7.8.3 and get out 7.8.2 now.

this fixes a bug that has been known for a long time, and the fix is quite
important for correct datum transformations with all versions of PROJ.
Therefore I have backported the fix to both relbr78 and relbr76. Please
include this fix in 7.8.2.

Markus M

>
> my 0.02 cents
>
> markusN
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #4009: 'where' option in v.to.rast can select wrong feature for raster attribute, in areas where features overlap

[GRASS GIS]

#4009: 'where' option in v.to.rast can select wrong feature for raster 
attribute,
in areas where features overlap
-+-
 Reporter:  florisvdh|  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Vector   |Version:  svn-releasebranch76
 Keywords:  v.to.rast sql where  |CPU:  x86-64
 Platform:  Linux|
-+-
 I use GRASS 7.6.1 on Linux Mint 18.1, i.e. Ubuntu Xenial (16.04) based.
 ''(Note, this is my first post here, I'm a beginning GRASS user, mostly
 working with R)''

 I applied something like:

 {{{
 v.to.rast input=polygon_layer output=output_x1 where="field1 LIKE 'x1'" \
  use=attr attribute_column=field2 memory=800 --overwrite
 }}}

 Importantly, {{{field1}}} in {{{polygon_layer}}} has several possible
 values such as {{{x1}}}, {{{x2}}}, {{{x3}}} and so on (81 different values
 in my usecase).

 Moreover, in my usecase several features (polygons) have identical
 geometry, i.e. many sets of 2 or more polygons exist with 100% overlap
 among their own polygons (i.e. identical polygons), while each of these
 polygons has its own specific attributes: different values of {{{field1}}}
 and so on. The problem that I met occurs for those features; possibly the
 same problem will occur for overlapping areas between polygons in general.

 While the {{{where}}} option in {{{v.to.rast}}} is effective in
 ''localizing the correct areas'', i.e. where {{{field1}}} is {{{x1}}}, the
 **problem** is that the **attribute value** ({{{field2}}}) may come from
 one of the other (overlapping) features at that place, e.g. where
 {{{field1}}} is {{{x2}}}. Which feature of an overlapping set is used for
 the attribute probably depends on the order of those overlapping features.

 From what I've seen, it appears that {{{v.to.rast}}} will select the
 {{{field2}}} value **from the same feature regardless** of the value for
 {{{field1}}} in the above {{{where}}} option, as long as ''one'' of those
 overlapping features meets the {{{where}}} condition.

 If this effectively ''is'' a bug in the program, maybe it happens in other
 modules as well, where the {{{where}}} option is available.

 ''Note: I should also mention that I used this in a simple parallelization
 approach in a loop (setting {{{field1}}} to different values), by starting
 the commands as background processes until a certain number of them is
 running (following an example I
 [https://grasswiki.osgeo.org/wiki/Parallelizing_Scripts found] in the
 GRASS wiki). That's why the memory option was used explicitly.''

 Currently I worked around this problem by splitting {{{polygon_layer}}}
 according to the value of {{{field1}}}, using {{{v.extract}}} (using just
 a simple loop here as the simple parallelization doesn't work with this
 one).

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #4008: r.category.trim addon: update to Python 3 needed

[GRASS GIS]

#4008: r.category.trim addon: update to Python 3 needed
-+-
 Reporter:  neteler  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.8.2
Component:  Addons   |Version:  git-releasebranch78
 Keywords:  r.category.trim  |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 The current version of r.category.trim does not yet work with Python 3
 (i.e., G78+).

 Using the 2to3 Python tool does a set of changes but I am unsure if they
 are acceptable:

 https://github.com/OSGeo/grass-addons/pull/74

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] any special reason why choice of raster compression method is done via environmental variable ?

[Huidae Cho]

One workaround may be GRASS_COMPRESSOR=method r.compress, but it won't
directly work on MS-Windows without a batch file, I think.

Huidae

On Tue, Dec 10, 2019 at 12:47 AM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 9/12/19 22:50, Markus Metz wrote:
> >   Hi Moritz,
> >
> > On Wed, Dec 4, 2019 at 10:28 AM Moritz Lennert
> > mailto:mlenn...@club.worldonline.be>>
> wrote:
> >  >
> >  > Hi Markus,
> >  >
> >  > In recent days, I've been confronted several times with the issue of
> >  > people trying to share data among themselves, but using different
> >  > versions of GRASS, and so raster data compressed in a more recent
> >  > version of GRASS was not usable in an older version of GRASS.
> >  >
> >  > Now, I agree that generally the solution is to tell people to use the
> >  > latest and greatest, but this is not always possible / it is not
> >  > necessarily highest on the list of priorities of people to see how
> they
> >  > can install the latest version of GRASS within their particular
> > environment.
> >  >
> >  > Obviously, those with the latest version of GRASS can simple
> recompress
> >  > using ZLIB. However, compression method is defined as an environment
> >  > variable. This is somewhat daunting to many MS Windows users out
> there.
> >  > Is there any specific reason that lead to the choice of not using a
> >  > parameter to allow the choice of compression method (possibly to
> >  > override a default that is still defined by an environment variable) ?
> >
> > Such a parameter would need to be added to every module creating raster
> > output.
>
> My request is more linked to use cases where one would like to share
> data (e.g. with r.pack) with other GRASS GIS users who do not
> necessarily have access to the same compression method, not necessarily
> to changing the default compression method. I was just wondering whether
> it might be easily possible to just implement r.compress method= as a
> quick way to recompress a specific map with a chosen method, overriding
> the default method. Currently, to do that, you have to change the
> default method by changing the env variable, run r.compress, then change
> the variable back to the value one wishes generally to use as default.
>
> Obviously, you can always just export as tiff and share that, but that
> just feels less elegant. Anyway, this is probably somewhat of a luxury
> problem :-)
>
> Moritz
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE
Open Source GIS Developer, GRASS GIS Development Team
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3994: Put page name first in s

[GRASS GIS]

#3994: Put page name first in s
--+-
  Reporter:  jidanni  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  trivial  |  Milestone:  7.8.3
 Component:  Docs |Version:  git-releasebranch78
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * milestone:   => 7.8.3


Comment:

 Replying to [comment:4 jidanni]:
 > OK I hope that fixes all hundred pages.

 Yes!

 For example:

  * https://grass.osgeo.org/grass79/manuals/t.vect.list.html
  * https://grass.osgeo.org/grass79/manuals/d.rast.html

 I'll backport it as soon as G 7.8.2 is out, hence keeping this ticket
 open.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3967: Add batch job example without path

[GRASS GIS]

#3967: Add batch job example without path
--+
  Reporter:  jidanni  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  trivial  |  Milestone:
 Component:  Docs |Version:  unspecified
Resolution:   |   Keywords:  grass.py exec CLI init
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by wenzeslaus):

 Replying to [comment jidanni]:
 > ...user may think he is actually able to "test in a pristine vanilla
 environment" ...
 > All this is getting too complex for me.

 You are actually right. The documentation assumes that you start with
 `--exec` etc. after you have some knowledge of GRASS GIS already. That's
 wrong assumption and unnecessary requirement. I can see now that it is
 actually misleading.

 I don't have a clear plan now for improving it, so any suggestions or PRs
 are as always welcome.

 > Maybe document a way to use a /dev/null mapset so the user can run some
 e.g., g.gisenv or whatever queries if he wants, without worrying that they
 access or store to any particular mapset.

 There is `--tmp-location` (created in a temporary database/directory)
 which allows you to run commands without creating any location (and thus
 mapset) permanently (again the documentation assumes you know why it is it
 useful). One use of specifically `--tmp-location XY` is running modules
 such as g.manual or g.extension which don't work with any data. General
 use is running scripts and using GRASS GIS as a processing backend.

 A temporary mapset (`--tmp-mapset`) would make sense too for same cases
 (see [wiki:GSoC/2019#Neweasy-to-useCLIandAPIforGRASSGIS GSoC 2019 New Easy
 CLI Idea] for the suggestion).

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Error with parallel i.sentinel.import usage (temp_region error?)

[Anika Bettge]

Hello all,

I try to import with GRASS78 in parallel Sentinel-2 data with 
"i.sentinel.import -r" (Multicore VM (32 cores -> 31 parallel processes)).

Sometimes the following error occurs (note the formatting comes from deploying 
in actinia):
  ...
  "99..Reprojecting ...", 
  "96..100", 
  "90..99..96..100", 
  "99..93..100", 
  "99..100", 
  "96..96..99..100", 
  "99..100", 
  "Estimated target resolution for input band 
: 9.998178838141047", 
  "Estimated target resolution for input band 
: 9.998178838141047", 
  "Estimated target resolution for input band 
: 9.998178838136036", 
  "Estimated target resolution for input band 
: 9.998178838141047", 
  "Estimated target resolution for input band 
: 9.26372380446332", 
  "Estimated target resolution for input band 
: 9.26372380446332", 
  "ERROR: Region file mapset_a6335f7028114ee9989530cb55874785//WIND is 
empty",   < here
  "ERROR: Region file mapset_a6335f7028114ee9989530cb55874785//WIND is 
empty", 
  "Using given resolution for input band 
: 10.0", 
  "Using given resolution for input band 
: 10.0", 
  "Using given resolution for input band 
: 10.0", 
  "Reprojecting ...", 
  "Reprojecting ...", 
  "Traceback (most recent call last):", 
  "  File \"/usr/local/grass7/scripts/r.import\", line 403, in 
", 
  "sys.exit(main())", 
  "  File \"/usr/local/grass7/scripts/r.import\", line 355, in main", 
  "grass.use_temp_region()", 
  "  File \"/usr/local/grass7/etc/python/grass/script/core.py\", line 
1216, in use_temp_region", 
  "run_command(\"g.region\", save=name, overwrite=True)", 
  "  File \"/usr/local/grass7/etc/python/grass/script/core.py\", line 
441, in run_command", 
  "return handle_errors(returncode, returncode, args, kwargs)", 
  "  File \"/usr/local/grass7/etc/python/grass/script/core.py\", line 
343, in handle_errors", 
  "returncode=returncode)", 
  "grass.exceptions.CalledModuleError: Module run None g.region --o 
save=tmp.r.import.19907 ended with error", 
  "Process ended with non-zero return code 1. See errors in the (error) 
output.", 
  "Traceback (most recent call last):", 
  "  File \"/usr/local/grass7/scripts/r.import\", line 403, in 
", 
  "sys.exit(main())", 
  "  File \"/usr/local/grass7/scripts/r.import\", line 355, in main", 
  "grass.use_temp_region()", 
  "  File \"/usr/local/grass7/etc/python/grass/script/core.py\", line 
1216, in use_temp_region", 
  "run_command(\"g.region\", save=name, overwrite=True)", 
  "  File \"/usr/local/grass7/etc/python/grass/script/core.py\", line 
441, in run_command", 
  "return handle_errors(returncode, returncode, args, kwargs)", 
  "  File \"/usr/local/grass7/etc/python/grass/script/core.py\", line 
343, in handle_errors", 
  "returncode=returncode)", 
  "grass.exceptions.CalledModuleError: Module run None g.region --o 
save=tmp.r.import.20767 ended with error", 
  "Process ended with non-zero return code 1. See errors in the (error) 
output.", 
  "Processing ...", 
  "Using given resolution for input band 
: 10.0", 
  "Processing ...", 
  "Reprojecting ...", 
  "Reprojecting ...", 
  "WARNING: Projection of dataset does not appear to match current 
location.", 
  ...

I found out that r.import uses temp_region and that this sets an environment 
variable WIND_OVERRIDE:

https://github.com/OSGeo/grass/blob/4dc36bb86fa9181259fa7f9b9472f8d3bc4e787e/lib/python/script/core.py#L1281
os.environ['WIND_OVERRIDE'] = name 

And in parallel processing the variable is set by each process and the 
temp_region can be deleted to early.

Does anyone know if this is the reason of my error and how to fix this?

Best,
Anika
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [OSGeo/grass] libproj (#252)

[Markus Neteler]

Hi,

On Mon, Dec 9, 2019 at 11:32 PM Helmut Kudrnovsky 
wrote:

> After backporting, another RC for 7.8.2 needed?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
>

... I would suggest to leave it for 7.8.3 and get out 7.8.2 now.

my 0.02 cents

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev