Re: [GRASS-dev] [GRASS GIS] #3343: v.label.sa broken and duplicated in trunk and addons

[GRASS GIS]

#3343: v.label.sa broken and duplicated in trunk and addons
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  trivial |  Milestone:  7.4.0
 Component:  Addons  |Version:  svn-trunk
Resolution:  fixed   |   Keywords:  v.label.sa, FTLIB, FreeType,
   CPU:  |  compilation
  Unspecified|   Platform:  Unspecified
-+-
Changes (by neteler):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Closing.

--
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] #3446: GRASS python library is not working with python 3

[GRASS GIS]

#3446: GRASS python library is not working with python 3
-+---
  Reporter:  lrntct  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.4.0
 Component:  Python  |Version:  7.2.1
Resolution:  |   Keywords:  python python3 ctypes
   CPU:  x86-64  |   Platform:  Linux
-+---

Comment (by neteler):

 See also #2708

--
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] #2708: Run GRASS with Python3

[GRASS GIS]

#2708: Run GRASS with Python3
--+-
  Reporter:  zarch|  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 See also #3446

--
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] #2461: GRASS 7: i.ortho.photo suite completion

[GRASS GIS]

#2461: GRASS 7: i.ortho.photo suite completion
--+--
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  major|  Milestone:  7.4.0
 Component:  Imagery  |Version:  svn-trunk
Resolution:   |   Keywords:  i.ortho.photo, wxGUI
   CPU:  Unspecified  |   Platform:  All
--+--
Changes (by neteler):

 * version:  unspecified => svn-trunk
 * component:  Default => Imagery


Comment:

 i.ortho.photo manual: new manual page contributed by Zofie Cimburova with
 minor modifications and HTML fixes (trunk, r71765; relbr74, r71767).

 Now further testing is needed...

--
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] #3066: g.gui.gcp not handling vectors

[GRASS GIS]

#3066: g.gui.gcp not handling vectors
-+
  Reporter:  madi|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.4.0
 Component:  wxGUI   |Version:  svn-trunk
Resolution:  |   Keywords:  georeferencing, vector
   CPU:  x86-64  |   Platform:  Linux
-+

Comment (by neteler):

 Can the ticket be closed?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

[Markus Metz]

On Sun, Nov 12, 2017 at 12:21 AM, Markus Metz 
wrote:
>
>
>
> On Sat, Nov 11, 2017 at 8:05 PM, Helena Mitasova  wrote:
> >
> >
> > On Nov 10, 2017, at 7:20 PM, Markus Metz 
wrote:
> >
> >
> >
> > On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova 
wrote:
> > >
> > > Please note, that  in spite of the fact that the datum.table shows
same transformation parameters,
> > > different nad83 datums are different (it is not just a different name
for the same datum) and there are different EPSG codes associated
> > > with the relevant CRS.
> > > You can find more about it here (or just google it)
> > > https://confluence.qps.nl/pages/viewpage.action?pageId=29855153
> > >
> > > Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with
the NGS NADCON program (I have not checked it out)
> > > (http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml).
> >
> > There are 12 (!) different definitions for NAD83. What to do about
this? Regard these 12 definitions as different datums? In this case I would
need to reinstate the datum check and we need to add more entries to
datum.table.
> >
> >
> > Markus, we absolutely need to have a datum check
>
> This datum check has been first added in Oct 2003 and has been quickly
removed again in Jan 2004. As long as we do not have proj-style definitions
reflecting the differences in the various nad83 datums, it does not make
sense to differentiate between say nad83 and nad83harn.

Apparently there is a way to construct different proj-style definitions for
different nad83 datums:

- proj provides the hdatum grids nad83_2002.ct2 and nad83_2010.ct2
- for nad83harn (High Accuracy Reference Networks), see
http://proj4.org/grids.html#harn on instructions to get an appropriate
nadgrid
- for fine grade conversions between various NAD83 epochs and WGS84, see
http://proj4.org/htpd.html#htpd

This looks like users might need to modify proj-style definitions manually,
after the appropriate grids have been manually obtained/created.

Markus M

>
> > - although the differences between different NAD83 datums are less than
a meter, differences between NAD27 and NAD83 are over hundred meters in
some areas. Anything that has a different EPSG should be treated as
different CRS exactly for the reasons you mentioned in your answer to Vasek.
>
> GRASS does not use EPSG to construct proj-style definitions.
>
> Markus M
>
> >
> > Helena
> >
> >
> > Markus M
> >
> > >
> > > Helena
> > >
> > > On Nov 10, 2017, at 5:30 PM, Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
> > >
> > >
> > >
> > > On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras 
wrote:
> > > >
> > > > On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
> > > > >
> > > > > > >
> > > > > > > 7.2 considers this OK while trunk considers this different.
I'm not sure which one is correct.
> > > > > >
> > > > > > In this case, 7.2 is correct, but 7.2 does not compare datums,
i.e. projections would be regarded as matching even with e.g. nad27 and
nad83.
> > > > > > The comparison of datums is new in 7.3 and needs some
refinement.
> > > > > >
> > > > > > I will fix the comparison of swapped lat_1 and lat_2.
> > > > >
> > > > > Fixed in trunk r71656.
> > > > >
> > > > > The test for different datum names has been disabled again in
trunk r71657. There are several different datum names in
lib/gis/datum.table that apparently mean the same: same ellipsoid and same
transformation parameters. Apparently, GRASS does not provide a datum name
when converting projection information from GRASS to proj4 for reprojecting
data.
> > > >
> > > >
> > > > Thank you so much, Markus. This saves me a lot of trouble.
> > >
> > > About avoiding trouble, the motivation of the stricter CRS comparison
is to avoid subsequent geolocation errors. If data have been imported and
differences in the CRS were not detected, it can become very difficult
later on in the processing to figure out the reason for geolocation errors
(different data not matching each other spatially). I'm not sure what to do
about different datum names. The current check relies on the test for
differences in ellipsoids.
> > >
> > > Markus M
> > >
> > > >
> > > > (I'm working on a Jupyter Notebook where I need trunk.)
> > > >
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS
> > > >
> > > > >
> > > > >
> > > > > Markus M
> > > > >
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.mask: odd behavior?

[Veronica Andreo]

Hi Markus,

> The issue is the following: I apply a mask, then I do some processing, I
> remove the mask and when I display the resulting map, all the pixels were
> processed. I would expect that those pixels that I masked were treated as
> NULL and not considered exactly as the message says:
>
>
> > "All subsequent raster operations will be limited to the MASK area.
> Removing
> > or renaming raster map named 'MASK' will restore raster operations to
> > normal."
>
> A MASK affects only reading raster data, not writing raster data.
> Therefore r.mapcalc "test = 1" will always produce a map without NULL cells.
>

Got it! That r.mapcalc expression was not reading any map. If I do for
example

r.mapcalc expression="elev1=elevation + 1"

and then remove the mask, it does work as I would have expected.

IMHO, the message is confusing then... not "all" subsequent raster
operations are limited to the mask, only if you read a map...
What about a mask also for writing raster data in GRASS 8 ? :))

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

[GRASS-dev] vector import bug fix

[Markus Metz]

I just found and fixed a cryptic bug when importing vector data with
polygons. This bug is most often the reason for warnings like

WARNING: Number of incorrect boundaries: X

during vector import. If such warnings appear, the result is corrupt. The
bug was not in the code itself, but was caused by compiler optimization of
the code. The relevant code has been rewritten accordingly in GRASS 7.2,
7.4, and 7.5.

If possible, please update your GRASS version to the latest svn version of
GRASS 7.2, 7.4, or 7.5.

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

Re: [GRASS-dev] r.mask: odd behavior?

[Markus Metz]

On Sun, Nov 19, 2017 at 9:19 PM, Veronica Andreo 
wrote:
>
> Hi devs,
>
> I found that r.mask does not behave as I would expect and I would really
appreciate some clarification.
>
> The issue is the following: I apply a mask, then I do some processing, I
remove the mask and when I display the resulting map, all the pixels were
processed. I would expect that those pixels that I masked were treated as
NULL and not considered exactly as the message says:
>
> "All subsequent raster operations will be limited to the MASK area.
Removing
> or renaming raster map named 'MASK' will restore raster operations to
> normal."

A MASK affects only reading raster data, not writing raster data. Therefore
r.mapcalc "test = 1" will always produce a map without NULL cells.

Markus M

>
> Otherwise, what's the point of applying a mask?
>
> This is an example with NC:
>
> g.region raster=landcover_1m -p
> r.category landcover_1m
> r.mask raster=landcover_1m maskcats="1 thru 6"
> d.mon wx0
> d.rast landcover_1m
> r.mapcalc "applied_mask = 1"
> r.mask -r
> d.erase
> d.rast applied_mask <<-- everything is there, no holes...
>
> The only operation that gave me what I would expect when I apply a mask
was:
> r.mapcalc expression="applied_mask=1-MASK"
>
> Can someone, please, test/clarify this?
>
> thanks much in advance!
> Vero
>
> ___
> 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] r.mask: odd behavior?

[Veronica Andreo]

Hi devs,

I found that r.mask does not behave as I would expect and I would really
appreciate some clarification.

The issue is the following: I apply a mask, then I do some processing, I
remove the mask and when I display the resulting map, all the pixels were
processed. I would expect that those pixels that I masked were treated as
NULL and not considered exactly as the message says:

"All subsequent raster operations will be limited to the MASK area. Removing
or renaming raster map named 'MASK' will restore raster operations to
normal."

Otherwise, what's the point of applying a mask?

This is an example with NC:

g.region raster=landcover_1m -p
r.category landcover_1m
r.mask raster=landcover_1m maskcats="1 thru 6"
d.mon wx0
d.rast landcover_1m
r.mapcalc "applied_mask = 1"
r.mask -r
d.erase
d.rast applied_mask <<-- everything is there, no holes...

The only operation that gave me what I would expect when I apply a mask
was:
r.mapcalc expression="applied_mask=1-MASK"

Can someone, please, test/clarify this?

thanks much in advance!
Vero
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3388: Legacy appstream metadata

[GRASS GIS]

#3388: Legacy appstream metadata
-+-
  Reporter:  Bas Couwenberg  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Default |Version:  7.2.1
Resolution:  |   Keywords:  appstream
   CPU:  Unspecified |   Platform:  Linux
-+-

Comment (by neteler):

 Updated in trunk: r71777; in relbr74: r71776; in relbr72: r71778.

 Validated OK on Fedora with:

 {{{
 appstream-util validate gui/icons/grass.appdata.xml
 }}}

 TODO (if a todo): rename  grass.appdata.xml file to grass.metainfo.xml (?)

--
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] #3443: Weird output of 'i.atcorr' in WorldView2 red channel (band 5)

[GRASS GIS]

#3443: Weird output of 'i.atcorr' in WorldView2 red channel (band 5)
--+-
  Reporter:  ppina|  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  7.2.2
Resolution:   |   Keywords:  i.atcorr, WorldView2 - red band
   CPU:  x86-32   |   Platform:  MSWindows 7
--+-

Comment (by neteler):

 We ave implemented the filter functions provided here:

 https://apollomapping.com/blog/new-documents-atmospheric-correction-
 digitalglobe-satellites-2

 I just converted them once more and the resulting curves are the same. For
 the CSV files implemented, see
 
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_2/imagery/i.atcorr/sensors_csv

 Question: You speak about band 5 = red. However, the filter functions are
 ordered as this:

 {{{
 1   2   3   4   5   6   7   8 9
 Pan BlueGreen   Red NIR1Coastal Yellow  Red Edge  NIR2
 }}}

 i.e. the 5th band is NIR1. May that be the reason (wrong band number)?

--
Ticket URL: 
GRASS GIS 

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