Re: [GRASS-dev] r.in.gdal: add scale and shift parameters?

[Glynn Clements]

Markus Neteler wrote:

> sometimes it is convenient to scale/shift input maps on the fly during
> the import in order to avoid an extra step with r.mapcalc (think: tons
> of scaled Landsat data etc).

Perhaps a better option (albeit one which requires some amount of
design, rathern than just coding) would be to have this performed
during read, i.e. similarly to how reclass maps are handled.

This would allow it to be used with r.external maps without needing to
make a copy (which largely defeats the point of using r.external).

It would also allow most maps to be stored as CELL, with better
precision than FCELL (32 bits rather than 24) and less space than
DCELL. It's quite rare for physical measurements to be sufficiently
accurate that 32 bits isn't enough.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3033: Cairo and PS drivers display only one raster or vector for SVG and PS

[GRASS GIS]

#3033: Cairo and PS drivers display only one raster or vector for SVG and PS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.2.0
 Component:  Display |Version:  svn-trunk
Resolution:  |   Keywords:  d.mon, cairo, ps, SVG, vector
   CPU:  |  graphics
  Unspecified|   Platform:  Unspecified
-+-

Comment (by glynn):

 Replying to [comment:5 wenzeslaus]:

 > That's why I wanted to avoid that. It seems that having the rendering
 functionality split into commands creates many problems.

 It also provides flexibility that a monolithic approach such as ps.map
 inherently lacks.

 > Makes sense, of course. That's why we need Cairo driver to support it.

 Another option, which isn't entirely trivial but possibly simpler than
 (reliably) merging SVG documents, would be a "capture" driver which
 serialises the driver calls and their parameters to a file for subsequent
 rendering. This way, you could capture the output from multiple d.*
 commands then render the final result via the cairo driver (or any other
 driver, but it's only really useful in conjunction with cairo's vector
 output formats).

 Structurally, this would be quite similar to the PS driver. Actually,
 parsing the output from the PS driver would probably work (mostly), and
 avoid the need for an additional driver.

 Except, we'd need to add the text methods (the cairo driver supports
 "driver" fonts which cause text rendering to be passed to the driver; the
 PS driver currently only supports stroke and freetype fonts which are
 converted to lines or rasters by the driver library then rendered using
 the driver's line/raster methods).

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3039: "Analyze map" not working with GRASS 7.0.4 (OSX - homebrew)

[GRASS GIS]

#3039: "Analyze map" not working with GRASS 7.0.4 (OSX - homebrew)
---+-
 Reporter:  guano  |  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  normal |  Milestone:  7.0.5
Component:  wxGUI  |Version:  7.0.4
 Keywords:  histogram, matplotlib  |CPU:  x86-64
 Platform:  MacOSX |
---+-
 Running GRASS 7.0.4 on OSX (El Capitan) installed via Homebrew.

 The "Analyze map" tools in Map Display are not working. The old ones do
 work (profile, d.histogram), but Scatter Plot, Histogram don't.

 The tools that need python/matplotlib are not working with the following
 error message:

 Traceback (most recent call last):
   File "/usr/local/Cellar/grass-70/7.0.4/grass-7.0.4/gui/wxp
 ython/mapdisp/frame.py", line 1066, in OnHistogramPyPlot

 win = HistogramPlotFrame(parent = self, rasterList = raster)
   File "/usr/local/Cellar/grass-70/7.0.4/grass-7.0.4/gui/wxp
 ython/wxplot/histogram.py", line 39, in __init__

 BasePlotFrame.__init__(self, parent, size = size, **kwargs)
   File "/usr/local/Cellar/grass-70/7.0.4/grass-7.0.4/gui/wxp
 ython/wxplot/base.py", line 88, in __init__

 self.client = plot.PlotCanvas(self)
   File "/usr/local/lib/python2.7/site-
 packages/wx-3.0-osx_cocoa/wx/lib/plot.py", line 598, in
 __init__

 self.HandCursor = wx.Cursor(Hand.GetImage())
   File "/usr/local/lib/python2.7/site-
 packages/wx-3.0-osx_cocoa/wx/_gdi.py", line 1502, in
 __init__

 _gdi_.Cursor_swiginit(self,_gdi_.new_Cursor(*args,
 **kwargs))
 TypeError
 :
 Required argument 'type' (pos 2) not found





 The same happens when calling them form the contextual menu (right-click).

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3011: OSGeo4W-winGRASS71 r68376: starting wxgui fails

[GRASS GIS]

#3011: OSGeo4W-winGRASS71 r68376: starting wxgui fails
---+-
  Reporter:  hellik|  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  critical  |  Milestone:  7.2.0
 Component:  wxGUI |Version:  svn-trunk
Resolution:|   Keywords:
   CPU:  x86-64|   Platform:  MSWindows 7
---+-

Comment (by annakrat):

 In [changeset:"68477" 68477]:
 {{{
 #!CommitTicketReference repository="" revision="68477"
 wxGUI: don't use sys.maxsize with wx.ListCtrl - breaks GUI on 64bit
 Windows, see #3011
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] some detail questions on i.segment

[Markus Metz]

Hi Moritz,

On Wed, May 18, 2016 at 6:36 PM, Moritz Lennert
 wrote:
> Hi Markus,
>
> I'm working on potentially improbing the i.segment.uspo addon and am looking
> at the possibility of including the goodness of fit output map somehow in
> the evaluation of the quality of the segmentation.
>
> For that, I need to exactly understand the goodness of fit measure.
>
> As a starter: why is the threshold parameter (globals->alpha) squared before
> being used in create_isegs.c (and in the calculation of the goodness of fit)
> ? Is it because i.segment works with the squared distance and not the actual
> distance ?

Yes, i.segment works with the squared distance to avoid sqrt() which
is slow. All that matters is if the distance is larger or smaller than
threshold, and this relation is the same with squared values.

>
> IIUC, the worst goodness of fit measure (i.e. 1 - difference) is equal to
> the 1 - threshold parameter value. This thus means that if one would want to
> compare segmentations done with different threshold values by comparing mean
> goodness of fit, for example, this would have to be scaled taking into
> account the respective parameter value. Would something like
>
> ( goodness of fit - (1 - threshold parameter value) )  / threshold parameter
> value
>
> make sense ?

The goodness of fit is currently 1 - similarity by comparing the
current cell values to the object's mean values. Similarity is in the
range [0, 1], 0 means identical, 1 means maximum possible difference.
With the region growing algorithm, that difference can actually be
larger than the given threshold if a cell is included in an object and
subsequent growing of the object shifts the mean away.

>
> BTW, in write_output.c, in the comments starting at line 82, there is
> mention of a globals->threshold, but there is not threshold in the globals
> structure... I guess this should read globals->alpha or threshold->answer,
> or ?

The comments starting at line 82 in write_output.c are an idea for
goodness of fit, the actual goodness of fit is calculated in lines 168
and 182.

HTH,

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

Re: [GRASS-dev] Seeking advices for image segmentation algorithms and windows compile question

[Yang, Bo (yangb2)]

Hi Moritz

> > 4. Then run grass71svn, it reported 3 dll files are missing
> > respectively: "libintl-8.dll/ libsystre-0/ libiconv-2 is missing from
> > your computer";  each time it report one dll missing, I copy this file
> > from "C:\msys64\mingw64\bin" to " C:\OSGeo4W64\bin". I don't know
> why
> > still come dll missing. I installed all the components required in [0]
> >
> > 5. Afterward GRASS can be started in both text mode and g.gui mode.
> 
> And you can run i.segment and other modules ?

Yes, I can run i.segment in text mode and i.segment --ui in GUI mode. I also 
tried i.cluster and i.cluster --ui and they both works. 

> > Do you know will it be anything wrong in the future if commenting this line?
> 
> This line creates the HTML manual page of your module. So, it won't keep
> your module from running, but you won't have the complete manual page.
> 
> Out of curiosity, could you:
> 
> - start grass in text mode, navigate to your i.segment folder and run 'make'

C:\msys64\usr\src\grass_trunk\imagery\i.segment>make
'make' is not recognized as an internal or external command,
operable program or batch file.
Previously I run 'make' in mingw and it works, seems using OSgeo4w cmd can't 
run 'make'

> - in text mode run 'g.gisenv' and send us the output
> 
C:\>g.gisenv
LOCATION_NAME=demolocation
GISDBASE=C:\Users\Bo\Documents\grassdata
MAPSET=PERMANENT
GUI=text
PID=6024

Best,
Bo Yang
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r68435 - grass/trunk/lib/proj

[Markus Neteler]

On Fri, May 20, 2016 at 9:18 AM, Maciej Sieczka  wrote:
> W dniu 15.05.2016 o 23:45, svn_gr...@osgeo.org pisze:
>>
>> +TODO: It is recommended to rely on PROJ4's proj-nad package. For doing so,
>> +  there would be some changes needed to lib/proj/get_proj.c - the call
>> +  to pj_set_finder() should be removed so that PROJ looks in its default
>> +  locations for the files. Also changes needed to lib/proj/Makefile so
>> +  it no longer creates the /etc/proj and /etc/proj/nad directories 
>> within
>> +  a GRASS installation nor installs the files there.
>
>
> Another option might be not to search for the grids in any particular
> directory, but to rely on a user-provided full path to the grid file in
> the PROJ_INFO.
>
> cs2cs, gdalwarp etc. allow the "nadgrids" to be a full path to a grid file.

To me this sounds quite reasonable.

Please add this suggestion to the ticket
https://trac.osgeo.org/grass/ticket/2456

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

Re: [GRASS-dev] Tests failing with "requires string, provided"

[Pietro]

Hi,

On Fri, May 13, 2016 at 5:48 PM, Vaclav Petras  wrote:
> A lot of tests are failing:
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2016-05-02-07-00/report_for_nc_basic_spm_grass7_nc/testfiles.html
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2016-05-03-07-00/report_for_nc_basic_spm_grass7_nc/testfiles.html
>
> Seems like PyGRASS related marameter checking:
>
> The Parameter  require a string,  instead is provided

the commit: r68465, fix the tests:

http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2016-05-20-07-00/report_for_nc_basic_spm_grass7_nc/testfiles.html

All the best

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

Re: [GRASS-dev] Weird v.proj bug: ERROR: Option does not accept multiple answers

[Markus Neteler]

On Fri, May 20, 2016 at 10:39 AM, Moritz Lennert
 wrote:
...
> How is this a bug ?

... right, it is not.

...
> So, when you write:
>
> v.proj -l bla location=nc_spf_grass7 mapset=PERMANENT
>
> this translates to
>
> v.proj -l location=bla location=nc_spf_grass7 mapset=PERMANENT
>
> i.e. you define the location parameter twice, which is obviously an error
> and so the error message is logical.

Yes. I got confused with the order in G6:

https://grass.osgeo.org/grass64/manuals/v.proj.html
v.proj [-lz] [input=name] location=name [mapset=name] ...

https://grass.osgeo.org/grass70/manuals/v.proj.html
v.proj [-lzw] location=name [mapset=name] [input=name] ...

Sorry for the noise! All fine.

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

Re: [GRASS-dev] Weird v.proj bug: ERROR: Option does not accept multiple answers

[Moritz Lennert]

On 20/05/16 07:12, Markus Neteler wrote:


On May 20, 2016 2:35 AM, "Vaclav Petras" > wrote:
 >
 >
 > On Thu, May 19, 2016 at 6:10 PM, Markus Neteler > wrote:
 >>
 >>
 >> today I came across a weird error (both 7.0.svn and trunk):
 >>
 >> # NC datasets
 >> GRASS 7.0.5svn (nc_spm_08_grass7):~ > v.proj -l bla
 >> location=nc_spf_grass7 mapset=PERMANENT
 >>
 >> Description:
 >>  Re-projects a vector map from one location to the current location.
 >> ...
 >> ERROR: Option  does not accept multiple answers
 >
 >
 > This is caused by the parser and it happens with every module:
 >
 > > g.region xxx region=yyy
 > ...
 > ERROR: Option  does not accept multiple answers

Mhh, a super bug!



How is this a bug ?

The general rule in the parser is that the first parameter can be given 
unnamed, i.e.


v.proj location=nc_spf_grass7 mapset=PERMANENT

is equivalent to

v.proj nc_spf_grass7 mapset=PERMANENT

So, when you write:

v.proj -l bla location=nc_spf_grass7 mapset=PERMANENT

this translates to

v.proj -l location=bla location=nc_spf_grass7 mapset=PERMANENT

i.e. you define the location parameter twice, which is obviously an 
error and so the error message is logical.


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

Re: [GRASS-dev] [GRASS GIS] #3038: Decide if validity check in r.in.lidar should be an additional filter or a filter enabled by default

[GRASS GIS]

#3038: Decide if validity check in r.in.lidar should be an additional filter or 
a
filter enabled by default
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  task| Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Raster  |Version:  svn-trunk
Resolution:  |   Keywords:  r.in.lidar, r3.in.lidar,
   CPU:  |  v.in.lidar, libLAS, PDAL
  Unspecified|   Platform:  Unspecified
-+-

Comment (by mlennert):

 Replying to [ticket:3038 wenzeslaus]:
 > Based on discussion on [http://gis.stackexchange.com/a/187559/10759 GIS
 SE] I wonder if we should make the filtering of lidar points based on
 validity in r.in.lidar, r3.in.lidar, and v.in.lidar optional.

 [...]

 > I've prepared a patch which turns the validity check into an additional
 filter which needs to be explicitly enabled if user wants it. It also
 removes validity check from scanning mode because no other filters are
 applied at that point. ''This changes the current behavior, so the
 question is if it is acceptable.''
 >
 > The alternative is to switch the logic in the patch to disable the
 filter if requested by user but have it on by default (i.e. current
 behavior by default).

 I think that in line with the general rule of no API changes within the
 same major number releases, the second option sounds better.

 However, looking at the last comment in the SE exchange, it seems that
 points are also declared invalid if the no scan angle is stored at all,
 i.e. there are two different kinds of invalidity: those which are based on
 a too large angle (and liblas seems to be quite restrictive, limiting this
 to -90 - 90 - whereas more recent [http://www.asprs.org/wp-
 content/uploads/2010/12/LAS_1_4_r13.pdf LAS specifications] allow -180 -
 180).

 So, I think we should:

 * Add a flag to ignore validity checks
 * Understand why scan angle 0 is declared invalid (if what Mihnea says on
 SE is true) and solve that
 * In the long run: determine whether laslib is still a good choice,
 knowing that it seems to have stalled in development ("libLAS is in a
 rather dormant period" as declared in the [http://www.liblas.org/faq.html
 FAQ])

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS-SVN] r68435 - grass/trunk/lib/proj

[Maciej Sieczka]

W dniu 15.05.2016 o 23:45, svn_gr...@osgeo.org pisze:

+TODO: It is recommended to rely on PROJ4's proj-nad package. For doing so,
+  there would be some changes needed to lib/proj/get_proj.c - the call
+  to pj_set_finder() should be removed so that PROJ looks in its default
+  locations for the files. Also changes needed to lib/proj/Makefile so
+  it no longer creates the /etc/proj and /etc/proj/nad directories within
+  a GRASS installation nor installs the files there.


Another option might be not to search for the grids in any particular
directory, but to rely on a user-provided full path to the grid file in
the PROJ_INFO.

cs2cs, gdalwarp etc. allow the "nadgrids" to be a full path to a grid file.

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