Re: [GRASS-dev] GRASS-GIS 6.4.3 Error in GUI startup

[Markus Neteler]

On Mon, Apr 17, 2017 at 9:19 PM, Tung Nguyen  wrote:
> Hello GRASS dev,
>
> I'm using GRASS-GIS v6.4.3 (2013) on Linux Mint 17.3 Rosa but couldn't get
> the GUI to start. I have tried all solutions I could find to no avail.

On some machines, we are also using Linux Mint, in the last year the
same version.
Link below:

> What I have done so far
> - Uninstall (purge) and reinstall python-wxversion, python-wxgtk2.8 then
> grass-core, grass-dev & grass-gui
>
> Error message I got
>
> $ grass64
>
> Starting GRASS ...
> ERROR: wxGUI requires wxPython. No module named wxversion

Please check if all wx related packages are installed from the list
mentioned here:

https://grasswiki.osgeo.org/wiki/Compile_and_Install#Linux_Mint

Filtered, that would probably these here:
libwxbase3.0-dbg libwxbase3.0-dev libwxgtk3.0-dbg libwxgtk3.0-dev
python-wxgtk2.8 python-wxtools python-wxversion wx3.0-headers
wx-common

However, I used GRASS GIS 7 and not 6 on my Mint box.

Please consider to use G7 and not 6, due to the zillions of improvements [1].

Markus

[1]
* https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures
* https://trac.osgeo.org/grass/wiki/Release/7.0.0-News
* https://trac.osgeo.org/grass/wiki/Release/7.2.0-News
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS-GIS 6.4.3 Error in GUI startup

[Helmut Kudrnovsky]

Tung Nguyen-2 wrote
> Hello GRASS dev,
> 
> I'm using GRASS-GIS v6.4.3 (2013) on Linux Mint 17.3 Rosa but couldn't get
> the GUI to start. I have tried all solutions I could find to no avail.
> What
> I have done so far
> - Uninstall (purge) and reinstall python-wxversion, python-wxgtk2.8 then
> grass-core, grass-dev & grass-gui
> 
> *Error message I got*
> 
> *$ grass64*
> 
> *Starting GRASS ...*
> *ERROR: wxGUI requires wxPython. No module named wxversion*
> *Error in GUI startup. If necessary, please*
> *report this error to the GRASS developers.*
> *Switching to text mode now.*
> *Hit RETURN to continue...*
> 
> *My machine info*
> 
> *System:Kernel: 4.4.0-28-generic x86_64 (64 bit gcc: 4.8.4)*
> *   Desktop: Cinnamon 2.8.8 (Gtk 3.10.8) Distro: Linux Mint 17.3
> Rosa*
> *Graphics:  Card: NVIDIA GM107GL [Quadro K620] bus-ID: 01:00.0*
> *   Display Server: X.Org 1.17.1 driver: nvidia Resolution:
> 1920x1080@60.0hz, 1920x1080@60.0hz*
> *   GLX Renderer: Quadro K620/PCIe/SSE2 GLX Version: 4.5.0 NVIDIA
> 375.39 Direct Rendering: Yes*
> 
> *$ python --version*
> *Python 2.7.12 :: Anaconda 4.1.1 (64-bit)*
> 
> Any suggestion would be appreciated. Thanks!

any chance to upgrade to GRASS 7.2 (current stable version)?

maybe related to your error, see:

http://osgeo-org.1560.x6.nabble.com/grass7-graphical-interface-failing-td5105788.html






-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/GRASS-GIS-6-4-3-Error-in-GUI-startup-tp5317500p5317503.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.fill.gaps porting

[Vaclav Petras]

On Mon, Apr 17, 2017 at 2:58 PM, Benjamin Ducke 
wrote:

> > I've added a figure which shows the r.slope.aspect products from the
> > surface without and with -p. You can see that the smoothing gives
> > significantly different results and probably better ones. I had the same
> > experience in past when trying to patch result of r.neighbors with the
> > original raster. Perhaps using smaller distance as you say or greater
> > power would help, but I haven't tested that yet.
>
> I find the results for "curvature" most interesting.
> In the unsmoothed LiDAR data, that metric is basically useless.
>
>
It is the same for profile and tangential curvature. At certain zoom level,
you can see, with a lot of imagination, some pattern, but comparing to the
more expected result from the smoothed data, it is just noise.


> If I understand correctly, then slope, aspect
> and curvature are all computed within a small
> neighbourhood of cells.


Right, that's what r.slope.aspect does. You can avoid that by using
r.param.scale, but for another analysis, it would matter (depending on the
implementation/method).


> So if LiDAR data is
> also noisy by nature, then it is not surprising
> that these metrics are all distorted by strongly
> fluctuating local means.
>
>
Yes, there is noise. Usually, you either interpolate from points or you do
binning at much courser res averaging the noise out.


> Please try experimenting with the power parameter,
> if you have the time. In theory, this should allow
> you to interpolate over larger distances with less
> of a low-pass effect (or the other way around,
> depending on what you want to achieve).
>

I have this on my todo list.


>
> >
> > I managed to commit just the figure its caption. If somebody gets to it,
> > please extent the section.
>
> I will update the HTML page, including a more
> prominent mentioning of the default smoothing.
> I also found some small typos that need fixing.


Thanks. I just added a section, high res image and some basic text.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS-GIS 6.4.3 Error in GUI startup

[Tung Nguyen]

Hello GRASS dev,

I'm using GRASS-GIS v6.4.3 (2013) on Linux Mint 17.3 Rosa but couldn't get
the GUI to start. I have tried all solutions I could find to no avail. What
I have done so far
- Uninstall (purge) and reinstall python-wxversion, python-wxgtk2.8 then
grass-core, grass-dev & grass-gui

*Error message I got*

*$ grass64*

*Starting GRASS ...*
*ERROR: wxGUI requires wxPython. No module named wxversion*
*Error in GUI startup. If necessary, please*
*report this error to the GRASS developers.*
*Switching to text mode now.*
*Hit RETURN to continue...*

*My machine info*

*System:Kernel: 4.4.0-28-generic x86_64 (64 bit gcc: 4.8.4)*
*   Desktop: Cinnamon 2.8.8 (Gtk 3.10.8) Distro: Linux Mint 17.3
Rosa*
*Graphics:  Card: NVIDIA GM107GL [Quadro K620] bus-ID: 01:00.0*
*   Display Server: X.Org 1.17.1 driver: nvidia Resolution:
1920x1080@60.0hz, 1920x1080@60.0hz*
*   GLX Renderer: Quadro K620/PCIe/SSE2 GLX Version: 4.5.0 NVIDIA
375.39 Direct Rendering: Yes*

*$ python --version*
*Python 2.7.12 :: Anaconda 4.1.1 (64-bit)*

Any suggestion would be appreciated. Thanks!

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

Re: [GRASS-dev] r.fill.gaps porting

[Benjamin Ducke]

On 16/04/17 03:40, Vaclav Petras wrote:
> 
> On Sat, Apr 15, 2017 at 8:32 AM, Benjamin Ducke  > wrote:
> 
> The thing is: I originally developed this module for
> gradiometer data. That data is very noisy and has
> high local variation. Interpolating that type of
> data while preserving original measurements will
> usually result in unsatisfactory output. Also note
> that the smoothing increases with the interpolation
> radius. For tiny holes in LiDAR data, try "distance=1"
> or "2". Of course, LiDAR data probably has different
> properties and does not need low-pass filtering
> like gradiometer data. So try "-p" to preserve the
> original values.
> 
> An alternative would be to invert the behaviour of
> the module and assume "-p" by default.
> 
> I don't work with LiDAR data myself, but I would very
> interested to know your results!
> 
> 
> 
> I've added a figure which shows the r.slope.aspect products from the
> surface without and with -p. You can see that the smoothing gives
> significantly different results and probably better ones. I had the same
> experience in past when trying to patch result of r.neighbors with the
> original raster. Perhaps using smaller distance as you say or greater
> power would help, but I haven't tested that yet.

I find the results for "curvature" most interesting.
In the unsmoothed LiDAR data, that metric is basically useless.

If I understand correctly, then slope, aspect
and curvature are all computed within a small
neighbourhood of cells. So if LiDAR data is
also noisy by nature, then it is not surprising
that these metrics are all distorted by strongly
fluctuating local means.

Please try experimenting with the power parameter,
if you have the time. In theory, this should allow
you to interpolate over larger distances with less
of a low-pass effect (or the other way around,
depending on what you want to achieve).

> 
> I managed to commit just the figure its caption. If somebody gets to it,
> please extent the section.

I will update the HTML page, including a more
prominent mentioning of the default smoothing.
I also found some small typos that need fixing.

Best,

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

[GRASS-dev] [release] GRASS 7.2.1RC2

[Martin Landa]

Hi all,

based on roadmap published in ML [1] we could go out with RC2. There are no
blockers registered [2], so it is seems that we can slowly start
preparing RC2. Any objections?

Ma

[1] https://lists.osgeo.org/pipermail/grass-dev/2017-February/084328.html
[2] 
https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&priority=blocker&priority=critical&milestone=7.2.1&milestone=7.2.0&group=type&order=priority

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

Re: [GRASS-dev] [GRASS GIS] #3334: d.legend.vect - symbols missing

[GRASS GIS]

#3334: d.legend.vect  - symbols missing
--+-
  Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by pvanbosgeo):

 * Attachment "legendfile" added.

 legend file for Wake_municp

--
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] #3334: d.legend.vect - symbols missing

[GRASS GIS]

#3334: d.legend.vect  - symbols missing
--+-
  Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by pvanbosgeo):

 * Attachment "Wake_Municp.pack" added.

 example vector layer with RGB column

--
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] #3334: d.legend.vect - symbols missing

[GRASS GIS]

#3334: d.legend.vect  - symbols missing
-+-
 Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.2.1
Component:  Default  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 When trying to save a map with legend as png file, the legend symbols are
 missing. E.g., I have a vector map with a column RGBcolor with the RGB
 colors, and a legend file 'legendfile' (see attached):

 {{{
 d.mon start=png width=600 height=450 output=mymap.png
 d.frame -c frame=map1 at="0,100,30,100"
 d.vect map=WakeMunicp rgb_column=RGBcolor
 d.frame -c frame=map2 at="0,100,0,29"
 d.legend.vect -b at="2,95" title=Municipals input=legendfile
 d.mon stop=png
 }}}


 The legend symbols are showing, on the other hand, when sending the map to
 wx monitor.

 {{{
 d.mon start=wx0
 d.frame -c frame=map1 at="0,100,30,100"
 d.vect map=WakeMunicp rgb_column=RGBcolor
 d.frame -c frame=map2 at="0,100,0,29"
 d.legend.vect -b at="2,95" title=Municipals input=tmplegendfile
 d.mon stop=png
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] How to import from a spatialite/sqlite db by v.in.ogr?

[Helmut Kudrnovsky]

Martin Landa wrote
> Hi,
> 
> 2017-04-16 22:40 GMT+02:00 Helmut Kudrnovsky <

> hellik@

> >:
>> v.in.ogr -l input=BiogeoRegions2016.sqlite
>> biogeoregions2016
> 
> [...]
> 
>> Data source 
> 
>  (format 'SQLite') contains 1 layers:
>> v.in.ogr input=BiogeoRegions2016.sqlite layer=biogeoregions2016|geometry
>> output=test where=short_name = 'alpine'
>> ERROR: Layer  not available
> 
> why not
> 
> layer=biogeoregions2016
> 
> ? Ma
> 
> -- 
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> grass-dev mailing list

> grass-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-dev

The more complete bug report is in:

https://trac.osgeo.org/grass/ticket/3308



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/How-to-import-from-a-spatialite-sqlite-db-by-v-in-ogr-tp5317435p5317469.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3333: v.import/v.in.ogr - GUI regression in import from a SQLITE/SPATIALITE db

[GRASS GIS]

#: v.import/v.in.ogr - GUI regression in import from a SQLITE/SPATIALITE db
+
  Reporter:  hellik |  Owner:  grass-dev@…
  Type:  defect | Status:  closed
  Priority:  normal |  Milestone:  7.2.1
 Component:  Vector |Version:  7.2.0
Resolution:  duplicate  |   Keywords:  import, sqlite
   CPU:  All|   Platform:  All
+
Changes (by marisn):

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


Comment:

 Already reported as #3308

--
Ticket URL: 
GRASS GIS 

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