Re: [GRASS-dev] IAU to wkt C code (converted from Trent Hare's Python code)

[Yann Chemin]

Checking with Trent, will report here soon.
On May 5, 2016 7:57 PM, "Markus Neteler"  wrote:

> Hi Yann,
>
> back to this topic:
>
> On Tue, Feb 23, 2016 at 5:26 PM, Yann  wrote:
> ...
> > I have converted the Python script
> > from Trent Hare to generate on the fly PROJCS and GEOCS WKTdescriptions
> for
> > all IAU2000 and IAU2009.
> ...
> > PS: GDAL is also going to insert it.
>
> Did this actually happen?
>
> Because GRASS no longer reads local CSV files and - to my knowledge -
> completely relies on GDAL/PROJ (see
> https://trac.osgeo.org/grass/ticket/2456).
> Hence, your two CSV files iau2000.csv + iau2009.csv and no longer shipped.
>
> Can you confirm that all works fine through GDAL (which version is
> needed to have IAU support?)
> ?
>
> thanks
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3007: pygrass.messages.Messenger.percent() smallest step is 2

[GRASS GIS]

#3007: pygrass.messages.Messenger.percent() smallest step is 2
-+-
  Reporter:  lrntct  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  LibGIS  |Version:  svn-trunk
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  Linux
-+-
Changes (by zarch):

 * component:  PyGRASS => LibGIS


Comment:

 I change the component fom pygrass to LibGis since I see the problem also
 with C code:

 {{{
 #include
 #include 


 int main()
 {
 int row;
 int nrows = 1352;

 G_message("Percent complete...");
 for (row = 0; row < nrows; row++)
 {
 G_percent(row, nrows, 1);
 usleep(1);
 }
 G_percent(1, 1, 1);
 return 0;
 }

 }}}

 Looking at the `G_percent` code I don't understand when is used the
 function `G_set_percent_routine(int (*percent_routine) (int))` within the
 GRASS code and where the default percent_routine is defined.

--
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] #2888: r.external wizzard shows "projection match: no" although location was created by one of the dataset

[GRASS GIS]

#2888: r.external wizzard shows "projection match: no" although location was
created by one of the dataset
-+-
  Reporter:  hellik  |  Owner:  martinl
  Type:  defect  | Status:  assigned
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:  r.external
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by hellik):

 Replying to [comment:6 neteler]:
 > Does it work in 7.0.4?

 as mentioned in the original report:

 >it works in 7.0.3.

 tested in 7.0.4, it seems to work also there.

 report is for GRASS version: 7.1.svn

--
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] #2888: r.external wizzard shows "projection match: no" although location was created by one of the dataset

[GRASS GIS]

#2888: r.external wizzard shows "projection match: no" although location was
created by one of the dataset
-+-
  Reporter:  hellik  |  Owner:  martinl
  Type:  defect  | Status:  assigned
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:  r.external
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by neteler):

 Does it work in 7.0.4?

--
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] #2888: r.external wizzard shows "projection match: no" although location was created by one of the dataset

[GRASS GIS]

#2888: r.external wizzard shows "projection match: no" although location was
created by one of the dataset
-+-
  Reporter:  hellik  |  Owner:  martinl
  Type:  defect  | Status:  assigned
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:  r.external
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by hellik):

 Replying to [comment:4 neteler]:
 > The libproj/GDAL interface received important updates (see #2456).
 >
 > Can you please try again?

 no chance to test yes as wxgui doesn't start (#3011)

--
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] #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
 Keywords:   |CPU:  x86-64
 Platform:  MSWindows 7  |
-+-
 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 . . .
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] start supporting python3 for GRASS

[Glynn Clements]

Pietro wrote:

> I committed some changes to start supporting python3 (r68348 - r68367)

Regarding r68357 ("fix in python3 sys.stdout.write accept only strings not 
bytes"):

 if not lines or lines[0] != b"@ARGS_PARSED@":
-sys.stdout.write(s)
+stdout = os.fdopen(sys.stdout.fileno(), 'wb')
+stdout.write(s)

You can get the underlying byte stream for a text stream using the
.buffer property (i.e. sys.stdout.buffer.write()).

OTOH, this probably doesn't matter much here, as sys.stdout will
almost certainly be a real file (i.e. .fileno() will be valid).

For the script module, it might be better to just replace the standard
streams with their underlying byte streams, i.e.

sys.stdin = sys.stdin.detach()
sys.stdout = sys.stdout.detach()
sys.stderr = sys.stderr.detach()

[The .detach() method returns the underlying byte stream *after*
detaching it from the TextIOWrapper, to avoid any issues arising from
attempting to use both.]

Anything using the script module should be using byte strings
throughout (in spite of how awkward Python 3 tries to make this).

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

Re: [GRASS-dev] [GRASS GIS] #2986: r.mapcalc with same variable on LHS and RHS

[GRASS GIS]

#2986: r.mapcalc with same variable on LHS and RHS
--+-
  Reporter:  mankoff  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  major|  Milestone:  7.0.4
 Component:  Docs |Version:  7.0.3
Resolution:  fixed|   Keywords:  r.mapcalc
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by glynn):

 Replying to [comment:10 mankoff]:
 > Would it be possible to support this by making {{{r.mapcalc}}} a
 wrapper, which replaces the {{{LHS}}} with something unique (if it is
 detected on the {{{RHS}}}, and then as a final step, setting the user
 {{{result}}} to the LHS-unique variable?
 It can't realistically be implemented as a wrapper, and I'm not sure that
 the behaviour would even be desirable. If change is warranted, it would be
 better to just check for the situation where an output map will overwrite
 any of the input maps, and report it as an error.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] IAU to wkt C code (converted from Trent Hare's Python code)

[Markus Neteler]

Hi Yann,

back to this topic:

On Tue, Feb 23, 2016 at 5:26 PM, Yann  wrote:
...
> I have converted the Python script
> from Trent Hare to generate on the fly PROJCS and GEOCS WKTdescriptions for
> all IAU2000 and IAU2009.
...
> PS: GDAL is also going to insert it.

Did this actually happen?

Because GRASS no longer reads local CSV files and - to my knowledge -
completely relies on GDAL/PROJ (see https://trac.osgeo.org/grass/ticket/2456).
Hence, your two CSV files iau2000.csv + iau2009.csv and no longer shipped.

Can you confirm that all works fine through GDAL (which version is
needed to have IAU support?)
?

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

Re: [GRASS-dev] [GRASS GIS] #2888: r.external wizzard shows "projection match: no" although location was created by one of the dataset

[GRASS GIS]

#2888: r.external wizzard shows "projection match: no" although location was
created by one of the dataset
-+-
  Reporter:  hellik  |  Owner:  martinl
  Type:  defect  | Status:  assigned
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:  r.external
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by neteler):

 The libproj/GDAL interface received important updates (see #2456).

 Can you please try again?

--
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] #2545: i.atcorr RapidEye band1

[GRASS GIS]

#2545: i.atcorr RapidEye band1
--+-
  Reporter:  chrisraa |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  6.4.6
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.atcorr
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+-

Comment (by neteler):

 I think I identified the issue:

 The filter function values for RapidEye do not have the needed precision
 (only 2 digits!):

 compare:

 
https://trac.osgeo.org/grass/browser/grass/trunk/imagery/i.atcorr/sensors_csv/rapideye.csv

 to e.g.

 
https://trac.osgeo.org/grass/browser/grass/trunk/imagery/i.atcorr/sensors_csv/geoeye1.csv

 We need a higher resolution rapideye.csv

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

[Markus Neteler]

On Sun, May 1, 2016 at 10:49 AM, Markus Neteler  wrote:
> On May 1, 2016 10:41 AM, "Martin Landa"  wrote:
>> 2016-05-01 9:35 GMT+02:00 Markus Neteler :
>> > I have added a new 7.2.0 milestone in trac (also a 7.3.0 milestone
>> > which replaces the function of the actual 7.1.0 milestone).
>>
>> probably we could rename dev version milestone as 7.1 / 7.3 since
>> these version will be never released (?)
>>
> Good idea!

Done as suggested:

milestone 7.1.0 renamed to 7.2.0:
https://trac.osgeo.org/grass/milestone/7.2.0

We have a an additional 7.3.0 (will never be released) which we will
rename to 7.4.0 in future.
All tickets not to be solved for 7.2.0 can be migrated to 7.3.0 now as
well as 8.0.0.

At time we have 155 open tickets on 7.2.0 which need to be reviewed
for that (or solved).

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

Re: [GRASS-dev] [GRASS-SVN] r68061 - grass/trunk/lib/gis

[Huidae Cho]

Hi Martin,

This fix only affects the history, not its behavior. "v.info -h n" gives
you:

COMMAND: v.edit map="n" layer="1" type="point,line,boundary,centroid"
tool="delete" threshold=-1,0,0 where="" snap="no"

Without this fix, you'll see:

COMMAND: v.edit map="n" layer="1" type="point,line,boundary,centroid"
tool="delete" threshold=-1,0,0 snap="no"

and cannot reuse this command without manually adding where="".

BTW, I think v.edit n tool=delete where="" should delete all features
because you're selecting all records by "select * from n" without any where
conditions. So your results look OK.

Huidae


On Sun, May 1, 2016 at 4:51 PM, Martin Landa  wrote:

> Hi,
>
> 2016-03-15 9:56 GMT+01:00  :
> > Author: hcho
> > Date: 2016-03-15 01:56:28 -0700 (Tue, 15 Mar 2016)
> > New Revision: 68061
> >
> > Modified:
> >grass/trunk/lib/gis/parser.c
> > Log:
> > G_recreate_command: Add empty answers.
> > Fix the command history for e.g., v.edit where="". Without this fix,
> where="" is not included, which makes an invalid command.
>
> I tried to backport this commit to relbr70. My quick test:
>
> v.random out=n n=100 --o
> v.db.addtable n
>
> leads to the all features removed.
>
> v.edit n tool=delete where=""
> Selecting features...
> 100 of 100 features selected from vector map 
> 100 features deleted
>
> I thought that this should be fixed by this commit, right? So no
> features removed (?)
>
> Thanks for explanation. 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
___
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

[Maris Nartiss]

I would strongly suggest to set up a dual boot on your system with
Ubuntu or Debian as a development platform. You will save tons of time
wasted on fighting with Windows'isms. Don't waste your time on
virtualisation unless you can give VM two cores + 8Gb RAM. No,
developing GRASS GIS doesn't need so much resources but full
virtualisation does (to be reasonable fast). Yes, it will take a day
or two to get dualboot up and running but will pay back (by time)
really fast.

Save yours (and our) time!
Māris.

2016-05-05 2:19 GMT+03:00 Yang, Bo (yangb2) :
> Hello,
>

>
> In addition, is there anyone who use win10 OS to compile the GRASS? I have
> compiled GRASS in window 10 64bit system followed the tutorial [1]. In last
> step of the tutorial it mentioned:
>
> >Usage:
>
> >To start GRASS use the icon on the desktop or if you want
> to be able to use the command line from within GRASS.
>
> >Type in cmd console (assuming that we compiled GRASS 7.1):
>
> >c:\osgeo4w\bin\grass71svn.bat
>
> However, No matter I use CMD console or the OSGeo4W Shell. I got the same
> error below:
>
> '""' is not recognized as an internal or external command,
> operable program or batch file.
>
> From the error.log there is no error during the compiling. There is no error
> reported in former steps either, and I can see the file " grass71svn.bat "
> is located in the right place. But I still can't start the compiled GRASS. I
> Googled this error but can't find helpful information. Any suggestion would
> be greatly appreciate.
>
>
>
> P.S. scripts in grass71svn.bat:
>
> @echo off
>
> rem
> #
>
> rem #
>
> rem # GRASS initialization bat script (OSGeo4W)
>
> rem #
>
> rem
> #
>
>
>
> SET OSGEO4W_ROOT=@osgeo4w@
>
>
>
> rem
>
> rem Set environmental variables
>
> rem
>
> call %OSGEO4W_ROOT%\bin\o4w_env.bat
>
> call %OSGEO4W_ROOT%\apps\grass\grass-7.1.svn\etc\env.bat
>
>
>
> rem
>
> rem Launch GRASS GIS
>
> rem
>
> "%GRASS_PYTHON%" "%GISBASE%\etc\grass71.py" %*
>
>
>
> rem
>
> rem Pause on error
>
> rem
>
> if %ERRORLEVEL% GEQ 1 pause
>
>
>
> [0] https://wiki.osgeo.org/wiki/GRASS_GSoC_2016_Segment_Algorithms
>
> [1] https://trac.osgeo.org/grass/wiki/CompileOnWindows
>
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev