date:20171125

Re: [GRASS-dev] [GRASS GIS] #2708: Run GRASS with Python3

2017-11-25 Thread 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 wenzeslaus):

 In [changeset:"71838" 71838]:
 {{{
 #!CommitTicketReference repository="" revision="71838"
 fix most obvious Python 3 compatibility issues: tabs, has_key, print in po
 script (see #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

2017-11-25 Thread 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 wenzeslaus):

 One option is to use Python virtual environments on your computer with
 Python 3 (I had to install `python3-venv`):

 {{{
 python3 -m venv test-python-3
 source test-python-3/bin/activate
 }}}

 After r71832 and r71833 (already compiled) GRASS GIS is now able to start
 in text mode with Python 3 and give acceptable error messages for GUI.

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

2017-11-25 Thread 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 wenzeslaus):

 In [changeset:"71832" 71832]:
 {{{
 #!CommitTicketReference repository="" revision="71832"
 init: use spaces consistently (no mixed tabs), required in Python 3 (PEP8
 E101, W191, see #2708)
 }}}

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Unresolved directions in r.fill.dir

2017-11-25 Thread Vaclav Petras

Hi all,

r.fill.dir with the bellow artificial DEM leaves part of the directions
unresolved and this area is marked in areas, although the area is filled in
the output. Here is the code to reproduce:

g.region n=220750 s=22 w=638300 e=639000 nsres=1 ewres=1 rows=750
cols=700 -p
r.mapcalc "hills = 500 * sin(row()) + 500 * sin(col())"
r.fill.dir input=hills output=filled direction=directions areas=areas

In r71809, I have committed a fix which transforms these unresolved
directions to NULLs because in the previous implementation (current 7.4svn
and older) internal representation of angles was leaking outside of the
module.

I have 2 questions:

Should I backport r71809 to 7.4?

Should we pursue this issue further to resolve why these edge cases are not
resolved, although they are filled? Does anybody has suggestions at this
point? (Paper with the method is linked in the doc.)

Thank you,
Vaclav

https://trac.osgeo.org/grass/changeset/71809
https://grass.osgeo.org/grass74/manuals/r.fill.dir.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Hole / NULL filling module naming

2017-11-25 Thread Anna Petrášová

Hi,

On Wed, Apr 19, 2017 at 4:36 AM, Benjamin Ducke  wrote:
> On 19/04/17 09:31, Maris Nartiss wrote:
>> Hello list,
>> as r.fill.gaps add on got ported from G6, it sparked my interest in
>> hole (NULL area) filling. At the moment there is one dedicated tool
>> r.fillnulls, but I would put my +1 of moving r.fill.gaps to main trunk
>> (with some light changes). Still it raises a question - how it should
>> be named? And in more general - how other hole filling modules should
>> be named? Answer is not so easy, as current r.fillnulls is a Python
>> script thus any new C based method would result in a separate module.
>>
>> One option would be splitting everything into separate modules based
>> on method/method group. Thus r.fillnulls could become i.e.
>> r.fill.spline (as at the moment all options are spline based) and
>> r.fill.gaps could become i.e. r.fill.stats. Such approach would allow
>> to add new C or Py modules as r.fill.idw, r.fill.nn, r.fill.nat etc.
>>
>
> I would be in favour of that option.
> A common naming scheme for modules with similar
> purposes makes good sense.


coming back to this, I would like to put r.fill.gaps into 7.4. If
there is agreement on renaming it to r.fill.stats,
I can write a test and move it to the core. Related to this we should
probably consider renaming r.fill.dir to something like r.fill.sink in
grass 8.

I was wondering about the formula to compute the weights for spatially
weighted mean option, because in the manual it says it's equivalent to
IDW, but in fact, the weights are computed little bit differently
(1-d/maxd)^2, so should we still call it IDW?

Thanks,

Anna

>
> Best,
>
> Ben
>
>> Second option would be just integrate new methods into r.fillnulls. At
>> the moment module already is a wrapper script around other modules
>> thus adding extra methods + their parameter groups would not be too
>> hard thus not creating tens of small modules. Other plus would be
>> keeping its "cool"/easy to understand name. Downside of this approach
>> would be r.fillnulls becoming a real monster with a gazzillion of
>> parser options.
>>
>> Of course, for the lifetime of G7, r.fillnulls will have to remain as
>> is to provide backwards compatibility.
>>
>> Wbr,
>> Māris.
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
>
> --
> Dr. Benjamin Ducke
> {*} Geospatial Consultant
> {*} GIS Developer
>
> Spatial technology for the masses, not the classes:
> experience free and open source GIS at http://gvsigce.org
> ___
> 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

Re: [GRASS-dev] [GRASS GIS] #26: please let people find their EPSG on the web

2017-11-25 Thread GRASS GIS

#26: please let people find their EPSG on the web
--+
  Reporter:  timmie   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  trivial  |  Milestone:  7.4.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  wxgui, location-wizard
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by neteler):

 Related update from GDAL project:


 On Sat, Nov 25, 2017 at 9:02 PM, GDAL  wrote:
 {{{
 > #6188: OSRAutoIdentifyEPSG does not identify EPSG 3358 (North Carolina)
 >
 +
 >  Reporter:  Markus Neteler  |   Owner:
 warmerdam
 >  Type:  enhancement |  Status:  closed
 >  Priority:  normal  |   Milestone:  2.3.0
 > Component:  default | Version:  1.11.2
 >  Severity:  normal  |  Resolution:  fixed
 >  Keywords:  AutoIdentifyEPSG, GetAuthorityCode  |
 >
 +
 > Changes (by Even Rouault):
 >
 >  * status:  new => closed
 >  * resolution:   => fixed
 >  * milestone:   => 2.3.0
 >
 >
 > Comment:
 >
 >  OSRFindMatches() added in GDAL trunk should help
 }}}

 >  {{{
 >  $ gdalsrsinfo -e 'PROJCS["Lambert Conformal Conic",
 >  > GEOGCS["grs80",
 >  > DATUM["North_American_Datum_1983",
 SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101]],
 >  > PRIMEM["Greenwich",0],
 >  > UNIT["degree",0.0174532925199433]],
 >  > PROJECTION["Lambert_Conformal_Conic_2SP"],
 >  > PARAMETER["standard_parallel_1",36.16],
 >  > PARAMETER["standard_parallel_2",34.34],
 >  > PARAMETER["latitude_of_origin",33.75],
 >  > PARAMETER["central_meridian",-79],
 >  > PARAMETER["false_easting",609601.22],
 >  > PARAMETER["false_northing",0],
 >  > UNIT["Meter",1]]'
 >  EPSG:32119
 >  }}}
 >
 > --
 > Ticket URL: 
 > GDAL 
 > Geospatial Data Abstraction Library is a translator library for raster
 and vector geospatial data formats.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [release planning] 7.4.0

2017-11-25 Thread Stefan Blumentrath

Zofie did use the tools in trunk. So, she can tell details.
What I understood is that all works well now, with proper GCPs. However, the 
algorithm seems to be very (very) sensitive to poorly placed GCPs. A single GCP 
can cause severely misplaced results. No idea if it is possible to do something 
about that...
@Zofie, please elaborate if I missed important details or misunderstood...

Cheers
Stefan

-Original Message-
From: neteler.os...@gmail.com [mailto:neteler.os...@gmail.com] On Behalf Of 
Markus Neteler
Sent: fredag 24. november 2017 16.01
To: Martin Landa 
Cc: GRASS developers list ; Žofie Cimburová 
; Stefan Blumentrath 
Subject: Re: [GRASS-dev] [release planning] 7.4.0

(cc Žofie, Stefan)

On Tue, Nov 21, 2017 at 11:08 AM, Martin Landa  wrote:
> Hi,
>
> 2017-11-21 9:31 GMT+01:00 Moritz Lennert :
>> AFAICT, the man page of g.gui.image2target is strictly identical to 
>> that of g.gui.gcp. Has this not been updated, yet ?
>
> there is probably some code duplication between g.gui.gcp and 
> g.gui.image2target. Does anyone tested the new GUI tools? Ma

Žofie, Stefan: did you use these tools in your i.ortho.photo experiments?

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

Re: [GRASS-dev] [GRASS GIS] #3453: i.segment.stats add-on : Empty output csv when flags ‘s’ is activated

2017-11-25 Thread GRASS GIS

#3453: i.segment.stats add-on : Empty output csv when flags ‘s’ is activated
--+-
  Reporter:  tgrippa  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:
 Component:  Addons   |Version:  unspecified
Resolution:  fixed|   Keywords:  i.segment.stats
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Thanks for the report and fix.  The issue also put the light on another
 bug in the object error message output. Both should be fixed in r71822.
 Please test.

--
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] #3453: i.segment.stats add-on : Empty output csv when flags ‘s’ is activated

2017-11-25 Thread GRASS GIS

#3453: i.segment.stats add-on : Empty output csv when flags ‘s’ is activated
--+-
  Reporter:  tgrippa  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:
 Component:  Addons   |Version:  unspecified
Resolution:  fixed|   Keywords:  i.segment.stats
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by mlennert):

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


Comment:

 In [changeset:"71822" 71822]:
 {{{
 #!CommitTicketReference repository="" revision="71822"
 i.segment.stats: fix #3453 and object error output
 }}}

--
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] #3453: i.segment.stats add-on : Empty output csv when flags ‘s’ is activated

2017-11-25 Thread GRASS GIS

#3453: i.segment.stats add-on : Empty output csv when flags ‘s’ is activated
-+-
 Reporter:  tgrippa  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Addons   |Version:  unspecified
 Keywords:  i.segment.stats  |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Hi, I notice a bug in i.segment.stats. When using the ‘s’ flag, the output
 csv is empty (in fact, the header is written, but not the rest of the
 file).

 I check the code I think the problem comes from L222-225 which are:

 {{{
 if area_measures:
  output_dict[values[0]] = output_dict[values[0]]+ [values[x] for x in
 stat_indices]
 else:
  output_dict[values[0]] = [values[x] for x in stat_indices]
 }}}

 and shoud be :
 {{{
 output_dict[values[0]] = output_dict[values[0]]+ [values[x] for x in
 stat_indices]
 }}}


 I make the change on my local version of the add-on and it seems working
 as expected.

 Also, I noticed the L220 and L221 are duplicates.

 Cheers,

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] All attempts to enable English language have failed. GRASS running with C locale. (trunk)

2017-11-25 Thread Helmut Kudrnovsky

Moritz Lennert wrote
> On 25/11/17 10:46, Helmut Kudrnovsky wrote:
>> here a win 10 with german locale; setting preferences in GRASS to en,
>> then I
>> get:
>> 
>> --
>> All attempts to enable English language have failed. GRASS running with C
>> locale.
>> If you observe UnicodeError in Python, install en_US.UTF-8 locale and
>> restart GRASS.
>> -
>> 
>> what does this mean?
> 
> See https://trac.osgeo.org/grass/ticket/3441.

"install en_US.UTF-8 locale and restart GRASS."

from the #3441:

"My question was how widespread C.UTF-8 is as a locale present on machines.
"

all the things mentioned in the ticket and the message may work in *nix
environments, not sure that this  will work in win (e.g. [1], [2], ...) and
mac.

[1]
https://stackoverflow.com/questions/4324542/what-is-the-windows-equivalent-for-en-us-utf-8-locale
[2]
https://superuser.com/questions/239810/setting-utf8-as-default-character-encoding-in-windows-7



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] All attempts to enable English language have failed. GRASS running with C locale. (trunk)

2017-11-25 Thread Moritz Lennert


On 25/11/17 10:46, Helmut Kudrnovsky wrote:

here a win 10 with german locale; setting preferences in GRASS to en, then I
get:

--
All attempts to enable English language have failed. GRASS running with C
locale.
If you observe UnicodeError in Python, install en_US.UTF-8 locale and
restart GRASS.
-

what does this mean?


See https://trac.osgeo.org/grass/ticket/3441.

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

[GRASS-dev] All attempts to enable English language have failed. GRASS running with C locale. (trunk)

2017-11-25 Thread Helmut Kudrnovsky

here a win 10 with german locale; setting preferences in GRASS to en, then I
get:

--
All attempts to enable English language have failed. GRASS running with C
locale.
If you observe UnicodeError in Python, install en_US.UTF-8 locale and
restart GRASS.
-

what does this mean?



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
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

Re: [GRASS-dev] [GRASS GIS] #2708: Run GRASS with Python3

Re: [GRASS-dev] [GRASS GIS] #2708: Run GRASS with Python3

[GRASS-dev] Unresolved directions in r.fill.dir

Re: [GRASS-dev] Hole / NULL filling module naming

Re: [GRASS-dev] [GRASS GIS] #26: please let people find their EPSG on the web

Re: [GRASS-dev] [release planning] 7.4.0

Re: [GRASS-dev] [GRASS GIS] #3453: i.segment.stats add-on : Empty output csv when flags ‘s’ is activated

Re: [GRASS-dev] [GRASS GIS] #3453: i.segment.stats add-on : Empty output csv when flags ‘s’ is activated

[GRASS-dev] [GRASS GIS] #3453: i.segment.stats add-on : Empty output csv when flags ‘s’ is activated

Re: [GRASS-dev] All attempts to enable English language have failed. GRASS running with C locale. (trunk)

Re: [GRASS-dev] All attempts to enable English language have failed. GRASS running with C locale. (trunk)

[GRASS-dev] All attempts to enable English language have failed. GRASS running with C locale. (trunk)

13 matches

Site Navigation

Mail list logo

Footer information