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

[Helmut Kudrnovsky]

>I did some research on google. Given all the errors come from >python, I am
thinking probably there are conflicts come from multi->python installations
of my computer (I have anaconda and ArcGIS >installed on my computer, both
have python 2.7)

could you do following steps to test if there is some interference with
other python installation?

- rename the ArcGIS python installation folder temporarily (e.g. Python27 ->
Yyypython27)

- do the same with the anaconda python installation folder

- try to start start again your self compiled winGRASS 7.1svn 

- report back here if your self compiled winGRASS 7.1svn starts or not 

- rename back the both folders



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Seeking-advices-for-image-segmentation-algorithms-and-windows-compile-question-tp5264642p5265681.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
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.0.5
 Component:  wxGUI |Version:  svn-trunk
Resolution:|   Keywords:
   CPU:  x86-64|   Platform:  MSWindows 7
---+-

Comment (by hellik):

 Replying to [comment:1 hellik]:
 > Replying to [ticket:3011 hellik]:
 > > error message:
 > >
 > > {{{
 > > Cleaning up temporary files...
 > > Starting GRASS GIS...
 > > Traceback (most recent call last):
 > >   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
 line 1200
 > > , in 
 > > GRASSStartUp = StartUp(0)
 > >   File "C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-
 unicode\wx\_core.
 > > py", line 7981, in __init__
 > > self._BootstrapApp()
 > >   File "C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-
 unicode\wx\_core.
 > > py", line 7555, in _BootstrapApp
 > > return _core_.PyApp__BootstrapApp(*args, **kwargs)
 > >   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
 line 1175
 > > , in OnInit
 > > StartUp = GRASSStartup()
 > >   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
 line 230,
 > >  in __init__
 > > self._set_properties(grassVersion, grassRevisionStr)
 > >   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
 line 282,
 > >  in _set_properties
 > > self.OnSetDatabase(None)
 > >   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
 line 929,
 > >  in OnSetDatabase
 > > self.UpdateLocations(self.gisdbase)
 > >   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
 line 796,
 > >  in UpdateLocations
 > > self.lblocations.InsertItems(self.listOfLocations, 0)
 > >   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
 line 1152
 > > , in InsertItems
 > > self._LoadData(choices, disabled)
 > >   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
 line 1141
 > > , in _LoadData
 > > index = self.InsertStringItem(sys.maxsize, item)
 > >   File "C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-
 unicode\wx\_contr
 > > ols.py", line 4761, in InsertStringItem
 > > return _controls_.ListCtrl_InsertStringItem(*args, **kwargs)
 > > wx._core.PyAssertionError: C++ assertion "m_count ==
 ListView_GetItemCount(GetHw
 > > nd())" failed at ..\..\src\msw\listctrl.cpp(1629) in
 wxListCtrl::InsertItem(): m
 > > _count should match ListView_GetItemCount
 > > ERROR: Error in GUI startup. See messages above (if any) and if
 necessary, pleas
 > > e report this error to the GRASS developers.
 > > On systems with package manager, make sure you have the right GUI
 package, proba
 > > bly named grass-gui, installed.
 > > To run GRASS GIS in text mode use the -text flag.
 > > Exiting...
 > > Drücken Sie eine beliebige Taste . . .
 > > }}}
 > >
 >
 > Tested with osgeo4w winGRASS 7.1svn from today, still an issue
 >

 Another user reported the same issue, see

 https://lists.osgeo.org/pipermail/grass-dev/2016-May/080213.html

--
Ticket URL: 
GRASS GIS 

___
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

[Helmut Kudrnovsky]

Yang, Bo (yangb2) wrote
> Hi Helmut and Moritz,
> 
>>error: 
>>libintl-8.dell missing 
>>libsystre-0.dll missing
> [...]
> 
>>ERROR: wxGUI requires wxPython. No module named wxversion
> 
>>It looks like the running/buildenvironment is inkompetent.
> 
>>all these dll's and wxpython should be available by the OSGeo4W
environment. 
> 
>>try the OSGeo4W advanced install to install all these missing libs and
wxpython
> 
>>Regarding missing dll's and wxpython, try to install e.g. OSGeo4W-winGRASS
7.0.4, then all dependencies should be installed.
> 
> I installed wxpython and OSGeo4W-winGRASS 7.0.4 via OSGeo4W, then build
> GRASS again (20min, no error reported). Now on my desktop there are both
> shortcuts of "GRASS GIS 7.1.svn" and "GRASS GIS 7.0.4".
> Currently the GRASS GIS 7.0.4 can be normally started without any issue.
> However, when start GRASS GIS 7.1.svn. the error below showed. 
> I did some research on google. Given all the errors come from python, I am
> thinking probably there are conflicts come from multi-python installations
> of my computer (I have anaconda and ArcGIS installed on my computer, both
> have python 2.7). If you think so too I will find another computer to
> clean install a new win7/10 and try to start over the compile follow that
> tutorial. 
> 
> Best,
> Bo
> 
> Appendix I: Error screenshot:
> ---
> Cleaning up temporary files...
> Starting GRASS GIS...
> Traceback (most recent call last):
>   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
> line 1200, in 
> 
> GRASSStartUp = StartUp(0)
>   File
> "C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py",
> line 7981, in __init__
> self._BootstrapApp()
>   File
> "C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py",
> line 7555, in _BootstrapApp
> return _core_.PyApp__BootstrapApp(*args, **kwargs)
>   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
> line 1175, in OnInit
> StartUp = GRASSStartup()
>   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
> line 230, in __init__
> self._set_properties(grassVersion, grassRevisionStr)
>   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
> line 282, in _set_properties
> self.OnSetDatabase(None)
>   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
> line 929, in OnSetDatabase
> self.UpdateLocations(self.gisdbase)
>   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
> line 796, in UpdateLocations
> self.lblocations.InsertItems(self.listOfLocations, 0)
>   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
> line 1152, in InsertItems
> self._LoadData(choices, disabled)
>   File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py",
> line 1141, in _LoadData
> index = self.InsertStringItem(sys.maxsize, item)
>   File
> "C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_controls.py",
> line 4761, in InsertStringItem
> return _controls_.ListCtrl_InsertStringItem(*args, **kwargs)
> wx._core.PyAssertionError: C++ assertion "m_count ==
> ListView_GetItemCount(GetHwnd())" failed at
> ..\..\src\msw\listctrl.cpp(1629) in wxListCtrl::InsertItem(): m_count
> should match ListView_GetItemCount
> 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.
> Exiting...
> Press any key to continue . . .
> --
> 
> Appendix II: file of error.log (usr/src/grass_trunk):
> 
> GRASS GIS 7.1.svn r68375 compilation log
> --
> Started compilation: Tue, May 10, 2016 10:46:44 PM
> --
> Errors in:
> No errors detected.
> --
> Finished compilation: Tue, May 10, 2016 10:48:16 PM
> --

ok, good to know that it compiles now. 

for the error message, see 

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

I'll add your example to the ticket. 

if you have another windows box without another python installation, try to
compile there until this ticket is solved. 




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Seeking-advices-for-image-segmentation-algorithms-and-windows-compile-question-tp5264642p5265678.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
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 Helmut and Moritz,

>error: 
>libintl-8.dell missing 
>libsystre-0.dll missing
[...]

>ERROR: wxGUI requires wxPython. No module named wxversion

>It looks like the running/buildenvironment is inkompetent.

>all these dll's and wxpython should be available by the OSGeo4W environment. 

>try the OSGeo4W advanced install to install all these missing libs and wxpython

>Regarding missing dll's and wxpython, try to install e.g. OSGeo4W-winGRASS 
>7.0.4, then all dependencies should be installed.

I installed wxpython and OSGeo4W-winGRASS 7.0.4 via OSGeo4W, then build GRASS 
again (20min, no error reported). Now on my desktop there are both shortcuts of 
"GRASS GIS 7.1.svn" and "GRASS GIS 7.0.4".
Currently the GRASS GIS 7.0.4 can be normally started without any issue. 
However, when start GRASS GIS 7.1.svn. the error below showed. 
I did some research on google. Given all the errors come from python, I am 
thinking probably there are conflicts come from multi-python installations of 
my computer (I have anaconda and ArcGIS installed on my computer, both have 
python 2.7). If you think so too I will find another computer to clean install 
a new win7/10 and try to start over the compile follow that tutorial. 

Best,
Bo

Appendix I: Error screenshot:
---
Cleaning up temporary files...
Starting GRASS GIS...
Traceback (most recent call last):
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py", line 
1200, in 
GRASSStartUp = StartUp(0)
  File 
"C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py", 
line 7981, in __init__
self._BootstrapApp()
  File 
"C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py", 
line 7555, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py", line 
1175, in OnInit
StartUp = GRASSStartup()
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py", line 
230, in __init__
self._set_properties(grassVersion, grassRevisionStr)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py", line 
282, in _set_properties
self.OnSetDatabase(None)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py", line 
929, in OnSetDatabase
self.UpdateLocations(self.gisdbase)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py", line 
796, in UpdateLocations
self.lblocations.InsertItems(self.listOfLocations, 0)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py", line 
1152, in InsertItems
self._LoadData(choices, disabled)
  File "C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py", line 
1141, in _LoadData
index = self.InsertStringItem(sys.maxsize, item)
  File 
"C:\OSGEO4~1\apps\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_controls.py",
 line 4761, in InsertStringItem
return _controls_.ListCtrl_InsertStringItem(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "m_count == 
ListView_GetItemCount(GetHwnd())" failed at ..\..\src\msw\listctrl.cpp(1629) in 
wxListCtrl::InsertItem(): m_count should match ListView_GetItemCount
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.
Exiting...
Press any key to continue . . .
--

Appendix II: file of error.log (usr/src/grass_trunk):

GRASS GIS 7.1.svn r68375 compilation log
--
Started compilation: Tue, May 10, 2016 10:46:44 PM
--
Errors in:
No errors detected.
--
Finished compilation: Tue, May 10, 2016 10:48:16 PM
--




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

Re: [GRASS-dev] [GRASS GIS] #3034: Change the layer options in v.in.lidar to flag or flags with predefined categories

[GRASS GIS]

#3034: Change the layer options in v.in.lidar to flag or flags with predefined
categories
-+-
  Reporter:  wenzeslaus  |  Owner:  wenzeslaus
  Type:  task| Status:  new
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  v.in.lidar, categories, returns,
   CPU:  |  classes, interface
  Unspecified|   Platform:  Unspecified
-+-
Changes (by wenzeslaus):

 * owner:  grass-dev@… => wenzeslaus


--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Fwd: new trac anti-spam filter

[Vaclav Petras]

On Sat, May 7, 2016 at 7:19 PM, Markus Neteler  wrote:

> > https://trac.osgeo.org/grass/timeline
> >
>
> Cleaned and Bayes filter better trained now.
>
New spam wiki pages and they seems to contain text from:

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

Re: [GRASS-dev] grass 7.2 planning

[Vaclav Petras]

On Tue, May 10, 2016 at 10:52 AM, Vaclav Petras 
wrote:

> I'll create a ticket, so it is clear what's the plan.


Created ticket #3034 for the layers in v.in.lidar, removed the vector
output from r.in.lidar in r68418.

https://trac.osgeo.org/grass/ticket/3034
https://trac.osgeo.org/grass/changeset/68418


> I'll set it as a blocker, so it shows up together with the other blockers.



Here are the current blockers:

https://trac.osgeo.org/grass/query?priority=blocker=assigned=new=reopened=7.2.0=type=id=summary=priority=status=owner=component=version=priority
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3027: i.atcorr's create_iwave.py broken

[GRASS GIS]

#3027: i.atcorr's create_iwave.py broken
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Imagery  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  i.atcorr
   CPU:  x86-64   |   Platform:  All
--+-

Comment (by martinl):

 The problem is that the list of values which is returned by `np.arange`
 contains values above range defined by `response[:,0]`.

 {{{
 response[0,0] ->
 [ 427.  428.  429.  430.  431.  432.  433.  434.  435.  436.  437.  438.
   439.  440.  441.  442.  443.  444.  445.  446.  447.  448.  449.  450.
   451.  452.  453.  454.  455.  456.  457.  458.  459.]
 response[:,1] ->
 [  7.3000e-05   6.0900e-04   1.6280e-03   3.4210e-03
8.0190e-03   2.4767e-02   8.5688e-02   2.54149000e-01
5.17821000e-01   7.65117000e-01   9.08749000e-01   9.58204000e-01
9.77393000e-01   9.8379e-01   9.89052000e-01   9.86713000e-01
9.93683000e-01   9.93137000e-01   1.e+00   9.96969000e-01
9.8278e-01   9.72692000e-01   9.05808000e-01   7.45606000e-01
4.71329000e-01   2.26412000e-01   9.2860e-02   3.6603e-02
1.4537e-02   5.8290e-03   2.4140e-03   9.8400e-04
2.5500e-04]
 np.arange(response[0,0], response[-1,0] + 2.5, 2.5) ->
 [ 427.   429.5  432.   434.5  437.   439.5  442.   444.5  447.   449.5
   452.   454.5  457.   459.5]
 }}}

 459.5 is outside of range `<427,459>`

--
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] #3034: Change the layer options in v.in.lidar to flag or flags with predefined categories (was: Changing the layer options ib .vin.lidar to flag or flags)

[GRASS GIS]

#3034: Change the layer options in v.in.lidar to flag or flags with predefined
categories
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  task| Status:  new
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  v.in.lidar, categories, returns,
   CPU:  |  classes, interface
  Unspecified|   Platform:  Unspecified
-+-

--
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] #3034: Changing the layer options ib .vin.lidar to flag or flags

[GRASS GIS]

#3034: Changing the layer options ib .vin.lidar to flag or flags
-+-
 Reporter:  wenzeslaus   |  Owner:  grass-dev@…
 Type:  task | Status:  new
 Priority:  blocker  |  Milestone:  7.2.0
Component:  Vector   |Version:  svn-trunk
 Keywords:  v.in.lidar, categories, returns, |CPU:  Unspecified
  classes, interface |
 Platform:  Unspecified  |
-+-
 The current version of G7:v.in.lidar in trunk (7.1) has several parameters
 related to storing return, class and color for lidar points.

 {{{
  id_layer   Layer number to store generated point ID as category
  return_layer   Layer number to store return number as category
   n_returns_layer   Layer number to store number of returns as category
   class_layer   Layer number to store class number as category
 rgb_layer   Layer number where RBG colors is stored as category
 red_layer   Layer number where red color is stored as category
   green_layer   Layer number where red color is stored as category
blue_layer   Layer number where blue color is stored as category
 }}}

 However, this is too many parameters. It seems that it might be more
 advantageous to store all these in predefined layers which would be also
 expected by some other modules. User would use a flag or more flags to
 enable this behavior.

 Interface will be decided here, so it is blocker for the next release
 (preferable its branching).

 More discussion also here:

 * https://lists.osgeo.org/pipermail/grass-dev/2015-September/076552.html

--
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 7.2 planning

[Vaclav Petras]

On Tue, May 10, 2016 at 10:22 AM, Martin Landa 
wrote:

> 2016-04-30 14:09 GMT+02:00 Martin Landa :
> >> I have some things in lidar modules which would be good to do before the
> >> branching, namely changing the layer options to flag(s) and removal of
> >> vector output from r.in.lidar. Ideally, some code should go from
> modules to
> >> the library but that might not be feasible in the given time frame
> (from my
> >> side). The first week of May I can't promise any commits since I'm at
> FOSS4G
> >> NA [1]
> >
> > we can wait one week or so if you wish.
>
> I just wanted to ask what is the current status? Thanks, Martin


I'm slowly starting to work on it now. I'll create a ticket, so it is clear
what's the plan. I'll set it as a blocker, so it shows up together with the
other blockers.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass 7.2 planning

[Martin Landa]

Hi,

2016-04-30 14:09 GMT+02:00 Martin Landa :
>> I have some things in lidar modules which would be good to do before the
>> branching, namely changing the layer options to flag(s) and removal of
>> vector output from r.in.lidar. Ideally, some code should go from modules to
>> the library but that might not be feasible in the given time frame (from my
>> side). The first week of May I can't promise any commits since I'm at FOSS4G
>> NA [1]
>
> we can wait one week or so if you wish.

I just wanted to ask what is the current status? Thanks, Martin

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

Re: [GRASS-dev] grass 7.2 planning

[Markus Neteler]

On Tue, May 10, 2016 at 3:34 PM, Martin Landa  wrote:
> 2016-05-10 15:31 GMT+02:00 Markus Neteler :
>> I added it 15min ago and also update the release procedure document to
>> increment the version in trac to not forget again.
>
> btw, I have also updated web site (main page + windows) which still
> pointed to 7.0.3 version. Martin

Thanks. We need to reduce the numbers of pages in which versions are
explicitly mentioned.

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

Re: [GRASS-dev] grass 7.2 planning

[Martin Landa]

Hi,

2016-05-10 15:31 GMT+02:00 Markus Neteler :
> I added it 15min ago and also update the release procedure document to
> increment the version in trac to not forget again.

btw, I have also updated web site (main page + windows) which still
pointed to 7.0.3 version. Martin

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

Re: [GRASS-dev] grass 7.2 planning

[Markus Neteler]

On Tue, May 10, 2016 at 3:23 PM, Vaclav Petras  wrote:
> On Thu, May 5, 2016 at 10:12 AM, Markus Neteler  wrote:
>>
>> We have a an additional 7.3.0 (will never be released) which we will
>> rename to 7.4.0 in future.
>
> So, do we even need 7.3.0 milestone?

I agree to remove it.


On Tue, May 10, 2016 at 3:29 PM, Martin Landa  wrote:
> 2016-05-10 15:23 GMT+02:00 Vaclav Petras :
>> BTW, we need 7.0.4 version in Trac.
>
> it's already there [1]? Martin
>
> [1] https://trac.osgeo.org/grass/admin/ticket/versions/7.0.4

I added it 15min ago and also update the release procedure document to
increment the version in trac to not forget again.

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

Re: [GRASS-dev] grass 7.2 planning

[Martin Landa]

Hi,

2016-05-10 15:23 GMT+02:00 Vaclav Petras :
> BTW, we need 7.0.4 version in Trac.

it's already there [1]? Martin

[1] https://trac.osgeo.org/grass/admin/ticket/versions/7.0.4

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

Re: [GRASS-dev] grass 7.2 planning

[Vaclav Petras]

On Thu, May 5, 2016 at 10:12 AM, Markus Neteler  wrote:

> We have a an additional 7.3.0 (will never be released) which we will
> rename to 7.4.0 in future.
>

So, do we even need 7.3.0 milestone?

BTW, we need 7.0.4 version in Trac.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3012: g.region -p reporting correct projection, but unknown datum NAD83(2011) /North Carolina (USft)

[GRASS GIS]

#3012: g.region -p reporting correct projection, but unknown datum NAD83(2011)
/North Carolina (USft)
-+---
  Reporter:  dnewcomb|  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.0.5
 Component:  Projections/Datums  |Version:  unspecified
Resolution:  fixed   |   Keywords:  libgis g.proj
   CPU:  Unspecified |   Platform:  Unspecified
-+---
Changes (by neteler):

 * keywords:   => libgis g.proj
 * resolution:   => fixed
 * status:  new => closed
 * component:  Default => Projections/Datums


Old description:

> When creating a location from a georeferenced file for NAD83(2011)/North
> Carolina (USft), http://epsg.io/6543, g.region reports the correct
> projection/datum in the projection line, but reports an unknown datum
>

> GRASS 7.1.svn (bladen_stpft):~ > g.region -p
>
> projection: 99 (NAD83(2011) / North Carolina (ftUS))
>
> zone:   0
>
> datum:  ** unknown (default: WGS84) **
>
> ellipsoid:  grs80

New description:

 When creating a location from a georeferenced file for NAD83(2011)/North
 Carolina (USft), http://epsg.io/6543, g.region reports the correct
 projection/datum in the projection line, but reports an unknown datum

 {{{
 GRASS 7.1.svn (bladen_stpft):~ > g.region -p
 projection: 99 (NAD83(2011) / North Carolina (ftUS))
 zone:   0
 datum:  ** unknown (default: WGS84) **
 ellipsoid:  grs80
 }}}

--

Comment:

 Backported in r68414, closing.

--
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] #3030: v. generalize fails to generalize polygons in a random manner

[GRASS GIS]

#3030: v. generalize fails to generalize polygons in a random manner
-+--
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.5
 Component:  Vector  |Version:  7.0.4
Resolution:  |   Keywords:  v.generalize
   CPU:  x86-64  |   Platform:  MSWindows 7
-+--
Changes (by neteler):

 * version:  7.0.3 => 7.0.4


Comment:

 Replying to [comment:2 dido]:
 > Added attachments with generalized data over the original data, where
 the non-generalized polygons are well-visible.
 >
 > Dataset can be provided upon request. GRASS version is 7.0.4 (missing in
 the list).

 Thanks for the hint, added to the list.

 > How can I modify the description -- looks ugly after I pasted the GRASS
 output :-)

 You need to encapsulate code in triple "{" ... "}" chars as per
 WikiFormatting. Updated as well.

--
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] #3030: v. generalize fails to generalize polygons in a random manner

[GRASS GIS]

#3030: v. generalize fails to generalize polygons in a random manner
-+--
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.5
 Component:  Vector  |Version:  7.0.3
Resolution:  |   Keywords:  v.generalize
   CPU:  x86-64  |   Platform:  MSWindows 7
-+--
Changes (by neteler):

 * keywords:  v.generalize fails 7.0.4 => v.generalize


Old description:

> Trying to generalize Greece shoreline + landmass, polygons fishnet'ed
> with cell size of 5000 m. Random polygons are not being generalized while
> they should be. If fishnet is made bigger (e.g 50 km cell size), then
> more non-generalized polygons are visible.
>
> Input is topologically error-free (no overlaps or gaps in input data).
> v.generalize output is as follows:
>
> v.generalize --overwrite input=c100_sea_dis_fish@Greece_UTM
> output=c100_sea_G120 method=douglas threshold=120
> WARNING: Vector map  already exists and will be
> overwritten
> Copying features...
> Building topology for vector map ...
> Registering primitives...
> 105726 primitives registered
> 832947 vertices registered
> Building areas...
> 36099 areas built
> 2921 isles built
> Attaching islands...
> Attaching centroids...
> Number of nodes: 36449
> Number of primitives: 105726
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 69627
> Number of centroids: 36099
> Number of areas: 36099
> Number of isles: 2921
> -
> Generalization (douglas)...
> Using threshold: 120 meters
> WARNING: 1953 boundaries were not modified because modification would
> damage topology
> WARNING: 1951 lines/boundaries were not modified due to over-
> simplification
> -
> Building topology for vector map ...
> Registering primitives...
> 105726 primitives registered
> 323843 vertices registered
> Building areas...
> 36099 areas built
> 2921 isles built
> Attaching islands...
> Attaching centroids...
> Number of nodes: 36449
> Number of primitives: 105726
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 69627
> Number of centroids: 36099
> Number of areas: 36099
> Number of isles: 2921
> -
> v.generalize complete. Number of vertices for selected features reduced
> from 796848 to 287744 (36% remaining)
> (Mon May 09 22:54:11 2016) Command finished (1 min 42 sec)

New description:

 Trying to generalize Greece shoreline + landmass, polygons fishnet'ed with
 cell size of 5000 m. Random polygons are not being generalized while they
 should be. If fishnet is made bigger (e.g 50 km cell size), then more non-
 generalized polygons are visible.

 Input is topologically error-free (no overlaps or gaps in input data).
 v.generalize output is as follows:


 {{{
 v.generalize --overwrite input=c100_sea_dis_fish@Greece_UTM
 output=c100_sea_G120 method=douglas threshold=120
 WARNING: Vector map  already exists and will be overwritten
 Copying features...
 Building topology for vector map ...
 Registering primitives...
 105726 primitives registered
 832947 vertices registered
 Building areas...
 36099 areas built
 2921 isles built
 Attaching islands...
 Attaching centroids...
 Number of nodes: 36449
 Number of primitives: 105726
 Number of points: 0
 Number of lines: 0
 Number of boundaries: 69627
 Number of centroids: 36099
 Number of areas: 36099
 Number of isles: 2921
 -
 Generalization (douglas)...
 Using threshold: 120 meters
 WARNING: 1953 boundaries were not modified because modification would
 damage topology
 WARNING: 1951 lines/boundaries were not modified due to over-
 simplification
 -
 Building topology for vector map ...
 Registering primitives...
 105726 primitives registered
 323843 vertices registered
 Building areas...
 36099 areas built
 2921 isles built
 Attaching islands...
 Attaching centroids...
 Number of nodes: 36449
 Number of primitives: 105726
 Number of points: 0
 Number of lines: 0
 Number of boundaries: 69627
 Number of centroids: 36099
 Number of areas: 36099
 Number of isles: 2921
 -
 v.generalize complete. Number of vertices for selected features reduced
 from 796848 to 287744 (36% remaining)
 (Mon May 09 22:54:11 2016) Command finished (1 min 42 sec)
 }}}

--

--
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] #3030: v. generalize fails to generalize polygons in a random manner

[GRASS GIS]

#3030: v. generalize fails to generalize polygons in a random manner
-+--
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.5
 Component:  Vector  |Version:  7.0.3
Resolution:  |   Keywords:  v.generalize fails 7.0.4
   CPU:  x86-64  |   Platform:  MSWindows 7
-+--
Changes (by dido):

 * component:  Default => Vector
 * cpu:  Unspecified => x86-64


--
Ticket URL: 
GRASS GIS 

___
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

[Helmut Kudrnovsky]

>Ok, then you have to either solve the compilation errors (maybe you can
>send us the error.log of trying to run make in one of the directories
>which failed), or disable compilation by (I think - but am no expert in
>MS Windows compilation - Helmut, can you confirm ?) erasing the line
>
>--with-liblas=$PWD/mswindows/osgeo4w/liblas-config
>
>from ./mswindows/osgeo4w/package.sh.

it's the same as in linux, just comment out this line.

the las compiling may be related to a las-issue in OSGeo4W 64bit:

https://trac.osgeo.org/grass/ticket/2996
https://trac.osgeo.org/osgeo4w/ticket/493

so commenting out this line should/may help to compile, if the other
dependencies/requirements (wxpython, wxversion, dlls) are complete.




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Seeking-advices-for-image-segmentation-algorithms-and-windows-compile-question-tp5264642p5265534.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
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

[Moritz Lennert]

On 10/05/16 03:40, Yang, Bo (yangb2) wrote:

Hi Helmut and Moritz,

Thanks for the reply and advise, here is my updates:
1)

no error reported in former steps either, and I can see the file "
grass71svn.bat " is located in the right place.

what is the "right place"? what is the path to the "right place"?


According to the tutorial [0], after compile with the default setting, the grass71svn.bat 
should be located in " c:\osgeo4w\bin\grass71svn.bat.". I see it is there, but 
when I run it via cmd (or double click), it always give the error:
'""' is not recognized as an internal or external command,
operable program or batch file.
Press any key to continue . . .

2)

SET OSGEO4W_ROOT=@osgeo4w@

could it be that OSGEO4W_ROOT isn't defined?
was winGRASS also installed or eventually only compiled?


Win GRASS was not installed yet, because in the tutorial the step of "Creating a WinGRASS 
Installer" was located after the step of "Compiling and Installing GRASS GIS". And the 
tutorial mentioned: " Do not move on to step two until you have successfully tested your new version of 
GRASS. "
So I didn't install WinGRASS since my compile part didn't go through yet.


I don't know about the details in Windows, here, so I'll let Helmut help 
you with this.



3)

compare OSGEO4W_ROOT above. OSGEO4W_ROOT has to be defined, otherwise the other 
bat-files, which define all needed variables, and grass71.py can't be found.

I edit the grass71svn.bat file compare with your file.
I change line " SET OSGEO4W_ROOT=@osgeo4w@ " of the bat file to " SET 
OSGEO4W_ROOT=C:\osgeo4w64 " since my path is C:\OSGeo4W64\bin.
I run the grass71svn.bat again and poped up the below error:
libintl-8.dell missing
libsystre-0.dll missing
...
I Googled the missing dll solutions[1] and copy them from C:\OSGeo4W64\bin to 
C:\osgeo4w64 and run again. Then it shoed on the screen:
---
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
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.
Exiting...
Press any key to continue . . .

I think this time is most close to start compiled GRASS so far.


This means that either wxpython is not installed, or that wxversion is 
not in the path. It should be available in the osgeo4w installer. Check 
whether it is installed.





4)

Yes, I agree: don't worry about Lidar at this stage. You should be able
to just ignore these errors and run GRASS anyhow. Have you tried running
it after this compile?


I found that if the compile result have errors, there are no file of
grass71svn.bat in the path of C:\OSGeo4W64\bin. So I don't know how to
ignore the error and run GRASS anyway because on the tutorial the

> grass71svn.bat is needed for start GRASS.

Ok, then you have to either solve the compilation errors (maybe you can 
send us the error.log of trying to run make in one of the directories 
which failed), or disable compilation by (I think - but am no expert in 
MS Windows compilation - Helmut, can you confirm ?) erasing the line


--with-liblas=$PWD/mswindows/osgeo4w/liblas-config

from ./mswindows/osgeo4w/package.sh.

Moritz





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

Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

[Blumentrath, Stefan]

Hi Nikos,

There are no real benefits from removing the kelvin_to_celsius function except 
for that code is a few lines shorter and the function is no longer used (plus 
that it is unlikely that you will be using it in the module in future). But the 
same applies probably to the "copy" helper function and the other stuff I just 
commented out could be removed too I guess, but I am not educated as a 
programmer. So others are much more qualified to comment on coding styles...

However, now I also had a closer look at the output of i.landsat8.swlst from a 
methodological point of view. Here it seems that - at least in my case of the 
city of Oslo - the difference between land-cover-corrected-LST and not 
land-cover-corrected-LST (I used land cover type 70 as a constant which has an 
average emissivity value) is almost insignificant (~ +- 1 degree celsius). The 
max/min differences were between -20 and +20 degrees Celsius, but these values 
appeared only at the boundary of the LST maps. Within the scenes differences 
were never > +-5 degree and very rarely > +-2.
Given the amount of data and computation required to incorporate land cover 
effects, you might consider to make a land cover map optional and just use a 
constant in the map calculator expression if no landcover map is provided...?

Another issue I came across it that currently, a possibly existing user mask 
will be simply overwritten, while it might be more friendly to backup the user 
mask before and restore it after the module finished... However, in order to 
simplify the module a bit, an option might be to move the masking part out of 
the module, and probably write something like this: 
https://grass.osgeo.org/grass70/manuals/i.modis.qc.html for Landsat, if that 
does not exist yet(?). Seems you thought about it already?
Based on Markus tutorial 
(http://courses.neteler.org/processing-landsat8-data-in-grass-gis-7/#Applying_the_Landsat_8_Quality_Assessment_%28QA%29_Band)
 and the info here http://landsat.usgs.gov/qualityband.php that should be a 
quite doable job. If no landsat bitpattern module exists I might be able to 
volunteer...
The idea would be something like this: extract raster values from QA band, loop 
over those values, compare the bit pattern representation of the integer values 
with acceptable bit patterns defined by the user, add the result of the 
comparison to r.reclass rules, and finally reclassify the QA band...

But all in all the results look pretty good, which you could see here: 
http://urban.nina.no/layers/geonode%3Alc81980182015183lgn00_lst and here: 
http://urban.nina.no/layers/geonode%3Alc81980182015183lgn00_lst_const_lc if our 
GeoNode worked as it should...

Kind regards,
Stefan



-Original Message-
From: Nikos Alexandris [mailto:nikos.alexand...@unige.ch] 
Sent: 9. mai 2016 16:31
To: Vaclav Petras 
Cc: Nikos Alexandris ; Blumentrath, Stefan 
; grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

* Vaclav Petras  [2016-05-08 20:10:46 -0400]:

>On Sat, May 7, 2016 at 5:14 PM, Nikos Alexandris 
>
>wrote:
>
>> -The k-flag (keep current computational region) is invers to GRASS
>>> standards. Maybe better to switch the behavior?
>>>
>>
>> Not sure.  It's kind of related to the #1 mistake everyone does, 
>> forget setting the right region extent.  So, I'd thought of letting 
>> the module operate on the whole scene.
>>
>
>Then really all GRASS modules should be changed.

:-) -- Let's change'm all!

I am joking, of course.  Will alter the behaviour in the module.

>
>>
>> Do we have a reference for this ("GRASS standards") or you mean the 
>> "common" behaviour of most modules?
>
>
>No. Perhaps we need another Submitting page on Trac or perhaps just 
>adding a best practice to the main Submitting page.

Yep!

Cheers, Nikos

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