Re: [GRASS-dev] Building GRASS packages from tarball on Launchpad

[Martin Landa]

2015-02-12 7:53 GMT+01:00 Martin Landa :
> thats a problem, nothing else happen till now [1]. I will try it once
> more. Martin
>
> [1] https://launchpad.net/~grass/+archive/ubuntu/grass-stable/+packages

hm,

dput ppa:grass/grass-stable ../grass70_7.0.0RC2-1_source.changes
Package has already been uploaded to ppa on ppa.launchpad.net
Nothing more to do for ../grass70_7.0.0RC2-1_source.changes

Any idea where to find out what is wrong? Thanks in advance! Martin

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

Re: [GRASS-dev] Building GRASS packages from tarball on Launchpad

[Martin Landa]

Hi,

2015-02-12 0:28 GMT+01:00 Ivan Mincik :

[...]

> I will start to build automatically once source package is uploaded
> :). No other manual action is needed.

thats a problem, nothing else happen till now [1]. I will try it once
more. Martin

[1] https://launchpad.net/~grass/+archive/ubuntu/grass-stable/+packages

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

Re: [GRASS-dev] file->new vector

[Martin Landa]

Hi Yann,

2015-02-12 7:15 GMT+01:00 Yann Chemin :
> Was looking to create a new vector file to deliniate an area.
> I have been repeatedly using qgis up to now (Ctrl+Shift+N) and was looking
> in GRASS for a (non-existing) menu entry "File->New" from some usability
> habit from other software.
>
> Maybe this could be useful for users, File->New and/or Ctrl+Shift+N (common
> shortcut in many software)

hm, there is `Vector -> Develop vector map -> Create new vector map`,
but you are right, it's somehow hidden. Martin

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

[GRASS-dev] file->new vector

[Yann Chemin]

Hi,

Was looking to create a new vector file to deliniate an area.
I have been repeatedly using qgis up to now (Ctrl+Shift+N) and was looking
in GRASS for a (non-existing) menu entry "File->New" from some usability
habit from other software.

Maybe this could be useful for users, File->New and/or Ctrl+Shift+N (common
shortcut in many software)

Cheers,
Yann

-- 

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

Re: [GRASS-dev] [GRASS GIS] #2588: wxGUI digitizer: error when adding a new column

[GRASS GIS]

#2588: wxGUI digitizer: error when adding a new column
+---
 Reporter:  mlennert|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  digitizer crash add column  |Platform:  Unspecified 
 
  Cpu:  Unspecified |  
+---

Comment(by annakrat):

 I think v.support doesn't need to open the vector on level 2. Changing it
 to level 1 solves this issue. Any opinion on that?

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Fwd: Re: [GRASS GIS] #2531: v.parallel/v.segment: strange output

[Moritz Lennert]

Markus,

As you are probably the one that knows the buffer code the best: do you 
have any idea about this ?



Moritz

 Forwarded Message 
Subject: Re: [GRASS GIS] #2531: v.parallel/v.segment: strange output
Date: Fri, 09 Jan 2015 11:32:27 -
From: GRASS GIS 
Reply-To: grass-dev@lists.osgeo.org
To: undisclosed-recipients:;

#2531: v.parallel/v.segment: strange output
---+
 Reporter:  hellik |   Owner:  grass-dev@… 

 Type:  defect |  Status:  new 

 Priority:  critical   |   Milestone:  7.0.0 


Component:  Vector | Version:  svn-trunk
 Keywords:  v.parallel, v.segment  |Platform:  MSWindows Vista 


  Cpu:  Unspecified|
---+

Comment(by mlennert):

 In Vect_line_parallel2 in

[http://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/Vlib/buffer2.c#L1181
 lib/vector/Vlib/buffer2.c], a call to clean_parallel is commented out.
 clean_parallel exists in buffer.c, not in buffer2.c. Maybe this might be a
 path to a solution.

 What seems to be the issue (AFAIU) is that the length of the parallel line
 segments is longer than that of the original line segments, as if the
 lines as projected outward. This seems to be what leads to the loops.
 Don't know why such a projection is done... I'll attach a screenshot to
 show what I mean.

 Have you checked out the -b flag ? And possibly tried to generalize the
 line before creating using v.parallel. Both might actually give you what
 you are looking for ?

--
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] #1242: vector fills and line widths not displaying in latlon regions

[GRASS GIS]

#1242: vector fills and line widths not displaying in latlon regions
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Display  | Version:  svn-trunk
 Keywords:  vector, display, d.vect  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by mlennert):

 Does anyone have any idea where this might come from ?

-- 
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] #2588: wxGUI digitizer: error when adding a new column

[GRASS GIS]

#2588: wxGUI digitizer: error when adding a new column
+---
 Reporter:  mlennert|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  digitizer crash add column  |Platform:  Unspecified 
 
  Cpu:  Unspecified |  
+---

Comment(by mlennert):

 A bit more info:

  * the column actually gets created
  * I can reproduce this with any existing map by just putting it into
 editing mode and then trying to add a column

-- 
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] #2252: wxGUI vector digitizer passing unescaped text to database

[GRASS GIS]

#2252: wxGUI vector digitizer passing unescaped text to database
-+
 Reporter:  marisn   |  
 Owner:  grass-dev@…  
 Type:  defect   |  
Status:  new  
 Priority:  blocker  |  
 Milestone:  7.0.0
Component:  wxGUI|  
   Version:  svn-trunk
 Keywords:  security, code injection, SQL injection, data loss, v.db.update  |  
  Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+

Comment(by mlennert):

 I can't reproduce this bug. I've tried with different SQL texts and they
 all are just put into the text field in the attribute table.

 Maris, can you still confirm this bug ?

-- 
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] #2588: wxGUI digitizer: error when adding a new column

[GRASS GIS]

#2588: wxGUI digitizer: error when adding a new column
+---
 Reporter:  mlennert|   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  7.0.0   
 
Component:  wxGUI   | Version:  svn-releasebranch70 
 
 Keywords:  digitizer crash add column  |Platform:  Unspecified 
 
  Cpu:  Unspecified |  
+---
 - In wxGUI Display Manager, chose Digitize -> New map
 - Try to add a new column to the new map:


 {{{
 ATTENTION: Unable to open vector map  on level 2. Try to
rebuild vector topology with v.build.
 ERREUR :Unable to open vector map 
 Traceback (most recent call last):
   File "/data/home/mlennert/SRC/GRASS/grass-7.0.0RC2/dist.x86_64-unknown-
 linux-gnu/scripts/v.db.addcolumn", line 88, in 
 main()
   File "/data/home/mlennert/SRC/GRASS/grass-7.0.0RC2/dist.x86_64-unknown-
 linux-gnu/scripts/v.db.addcolumn", line 84, in main
 grass.vector_history(map)
   File "/data/home/mlennert/SRC/GRASS/grass-7.0.0RC2/dist.x86_64-unknown-
 linux-gnu/etc/python/grass/script/vector.py", line 145, in vector_history
 run_command('v.support', map=map, cmdhist=os.environ['CMDLINE'])
   File "/data/home/mlennert/SRC/GRASS/grass-7.0.0RC2/dist.x86_64-unknown-
 linux-gnu/etc/python/grass/script/core.py", line 375, in run_command
 return handle_errors(returncode, returncode, args, kwargs)
   File "/data/home/mlennert/SRC/GRASS/grass-7.0.0RC2/dist.x86_64-unknown-
 linux-gnu/etc/python/grass/script/core.py", line 310, in handle_errors
 returncode=returncode)
 grass.exceptions.CalledModuleError: Module run None ['v.support',
 'map=test1@user1', 'cmdhist=v.db.addcolumn "--q" "map=test1@user1"
 "layer=1" "columns=tt1 integer"'] ended with error
 Process ended with non-zero return code 1. See errors in the (error)
 output.
 }}}

-- 
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] r64426 - grass/trunk/lib/python/script

[Markus Neteler]

Hi,

should this be backported?

Markus

On Tue, Feb 3, 2015 at 4:20 PM,   wrote:
> Author: glynn
> Date: 2015-02-03 07:20:48 -0800 (Tue, 03 Feb 2015)
> New Revision: 64426
>
> Modified:
>grass/trunk/lib/python/script/array.py
> Log:
> numpy.memmap() no longer has _close; use __del__ instead
>
>
> Modified: grass/trunk/lib/python/script/array.py
> ===
> --- grass/trunk/lib/python/script/array.py  2015-02-03 15:01:35 UTC (rev 
> 64425)
> +++ grass/trunk/lib/python/script/array.py  2015-02-03 15:20:48 UTC (rev 
> 64426)
> @@ -150,8 +150,7 @@
>  self.filename = filename
>  return self
>
> -def _close(self):
> -numpy.memmap._close(self)
> +def __del__(self):
>  if isinstance(self, array):
>  try_remove(self.filename)
>
> @@ -273,10 +272,8 @@
>
>  return self
>
> -def _close(self):
> -
> -numpy.memmap._close(self)
> -if isinstance(self, array):
> +def __del__(self):
> +if isinstance(self, array3d):
>  try_remove(self.filename)
>
>  def read(self, mapname, null=None):
>
> ___
> grass-commit mailing list
> grass-com...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-commit
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2583: v.net: crash on Windows

[GRASS GIS]

#2583: v.net: crash on Windows
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Default  | Version:  svn-releasebranch70  
 Keywords:  v.net crash  |Platform:  MSWindows 7  
  Cpu:  Unspecified  |  
-+--

Comment(by mlennert):

 Can anyone using Windows confirm this bug ?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Building GRASS packages from tarball on Launchpad

[Ivan Mincik]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11.02.2015 21:52, Martin Landa wrote:
> Hi Ivan,
> 
> 2015-02-10 9:34 GMT+01:00 Martin Landa :
>> dpkg-source -b pkg-grass dpkg-source: info: using options from
>> pkg-grass/debian/source/options: 
>> --extend-diff-ignore=(^|/)(config\.sub|config\.guess|mswindows/osgeo4w/grass.tmpl|config.log)$
>>
>> 
dpkg-source: error: can't build with source format '3.0 (native)':
>> native package version may not have a revision dpkg-buildpackage:
>> error: dpkg-source -b pkg-grass gave error exit status 255 
>> debuild: fatal error at line 1376: dpkg-buildpackage -rfakeroot
>> -d -us -uc -S -sa failed gbp:error: 'debuild -S -sa' failed: it
>> exited with 29
> 
> I managed to solve this problem, the last command I entered was:
> 
> dput ppa:grass/grass-stable ../grass70_7.0.0RC2-1_source.changes
> 
> it seems to be OK
> 
> Uploading to ppa (via ftp to ppa.launchpad.net): Uploading
> grass70_7.0.0RC2-1.dsc: done. Uploading grass70_7.0.0RC2-1.tar.gz:
> done. Uploading grass70_7.0.0RC2-1_source.changes: done.
> 
> But I cannot find at Launchpad [1] any "button" where I could
> launch building process...

I will start to build automatically once source package is uploaded
:). No other manual action is needed.

> 
> Thanks again for the patience (being debian user who has no
> experience with creating packages)! Martin
> 
> [1]
> https://launchpad.net/~grass/+archive/ubuntu/grass-stable/+packages
>
> 
- -- 
Ivan Min?ík
ivan.min...@gmail.com  GPG: 0x79529A1E
http://imincik.github.io/0x79529A1E.key
ivan.min...@gista.sk GPG: 0xD714B02C
http://imincik.github.io/0xD714B02C.key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU2+WjAAoJEPfdLsR5UpoetgwH/2KnE5dzLceZ5by3JOQD3dA/
gBFUhUBpofEUG3M+1KsBHU+Jox4gxKVl+x+cIzU7ZTpMgB+PT1oGhJJHrNWFLt2C
KpjcgUIMMbsgW5j6ris9JYyoL8f+CKMU7/gYQjKSUxXpKfXcq1ty1VxJY19/G2m5
iOWBFlwaYb5pc4erU45VOIpBiv/KcfyHcQ2qdPG0S4p55dEaGmpgKlASWVTDOS28
RBlZE+5A1Rxatb49ExUuH11UejIj4iJqniEtTH3UtnJjNIirEaaxQQ13w+Dq4qjE
shXrgCJpWcWqg+J/ACIZPWcKCAQ1Rc0H2XuWGGTSG8vHotvxBAtI45oyCi69g2c=
=aIZ7
-END PGP SIGNATURE-
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Planning GRASS GIS 7.0.0 final: a few days left

[Markus Neteler]

Hi devs,

according to our
http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

the final release is due on 15th of February.

Please check/update
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing

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

Re: [GRASS-dev] [GRASS GIS] #2579: Specify command to be exectued as parameter of grass command

[GRASS GIS]

#2579: Specify command to be exectued as parameter of grass command
--+-
 Reporter:  wenzeslaus|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Startup   | Version:  svn-trunk 
   
 Keywords:  batch job, GRASS_BATCH_JOB, init  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by wenzeslaus):

 Replying to [comment:1 mlennert]:
 > Why do you need the --mapset as in:
 >
 {{{
 grass7 --mapset ~/grassdata/location/mapset --batch r.mapcalc "aaa = 5"
 }}}
 >
 > ?
 >
 > The current GRASS startupt script already allows to define a mapset at
 startup, so this seems redundant.
 >

 This is a thing I'm not sure about. The current syntax is

 {{{
 grass ~/grassdata/nc_spm_08_grass7/user1
 grass -c ~/grassdata/nc_spm_08_grass7/user1
 }}}

 which follows the following general pattern

 {{{
 name options/flags files
 name [option]... [file]...
 name [option]... [file] [arg]...
 }}}

 where options/flags are distinguished by `-` or `--` and first thing which
 is not an option starts a file list. The last row actually describes
 `python` and `Rscript`:

 {{{
 python [option] ... [-c cmd | -m mod | file | -] [arg] ...
 Rscript [--options] [-e expr [-e expr2 ...] | file] [args]
 }}}

 So it seems that they actually leave out (equivalent of) `--batch`. If we
 would allow not to specify db+l+mapset then one could use:

 {{{
 grass .../test_script.sh
 grass r.info
 grass r.mapcalc "aaa = 5"
 }}}

 which could be hard to distinguish from (current):

 {{{
 grass ~/grassdata/nc_spm_08_grass7/user1
 }}}

 We can also say that db+l+mapset is always required when passing module or
 script because the usual use case is when GRASS GIS is used as processing
 backend and in this case you rarely want to use db+l+mapset from rc file.
 This gives us:

 {{{
 grass ~/grassdata/nc_spm_08_grass7/user1 .../test_script.sh
 grass ~/grassdata/nc_spm_08_grass7/user1 r.info
 grass ~/grassdata/nc_spm_08_grass7/user1 r.mapcalc "aaa = 5"
 }}}

 In this case, I'm not sure how well we can distinguish different cases
 (standard/batch) when parsing and how we can provide good error messages.

 Similar, but not the same, case is `grep`. With `grep` you always have to
 provide the `PATTERN` parameter:

 {{{
 grep [OPTION]... PATTERN [FILE]...
 }}}

 In our case all parameters would be optional. The order is really
 important in this case and identification of options can become tricky,
 although hopefully not as much as with `grep` (try to search for a string
 which starts with `-`). If we decide for something like this, the command
 line parsing in `grass.py` will have to be reimplemented, at least I think
 according to the code. For example, you have to recognize where the actual
 command starts because then everything else should not be used (trivial
 with `--batch`, hard without).

-- 
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] #2572: grass command welcomes batch job and requires user input

[GRASS GIS]

#2572: grass command welcomes batch job and requires user input
-+--
  Reporter:  wenzeslaus  |   Owner:  grass-dev@…
  Type:  defect  |  Status:  closed 
  Priority:  minor   |   Milestone:  6.4.5  
 Component:  Startup | Version:  6.4.4  
Resolution:  fixed   |Keywords:  GRASS_BATCH_JOB, rc file, init, startup
  Platform:  Linux   | Cpu:  Unspecified
-+--
Changes (by wenzeslaus):

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


Comment:

 Replying to [comment:1 wenzeslaus]:

 > r64408 should be safe enough to be backported any time to release branch
 but the right time is after RC2 considering the freeze.

 Backported to 7.0 in r64569 after RC2 and after test on MS Windows (with
 removed `GRASS7` in the `AppData` `Roaming` directory). I got to startup
 window so easily that I had to start beta3 too see what I'm actually
 testing.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.in.ogr: islands not recognized

[Markus Neteler]

On Wed, Feb 11, 2015 at 9:47 PM, Markus Metz
 wrote:
> On Wed, Feb 11, 2015 at 9:34 PM, Markus Neteler  wrote:
>> HI,
>>
>> I tried to import the NUTS3 map(s) from EU which leads to some obscur
>> warnings (see below). While most can be solved with a "mild" snapping,
>> still four islands are reported as an error. They are Andorra, etc and
>> apparently really valid. The error message though suggests that the
>> import was not successful. Could this be fixed?
>
> This might have been fixed already in trunk, please test!

Unfortunately not:

GRASS 7.1.svn (eu_etrs89):~ > g.version -g
version=7.1.svn
date=2015
revision=64567
build_date=2015-01-11
build_platform=x86_64-unknown-linux-gnu
GRASS 7.1.svn (eu_etrs89):~ > v.in.ogr
/data/maps/nuts3/NUTS_2010_03M_SH/Data/NUTS_RG_03M_2010.shp
output=NUTS_RG_03M_2010  --o
...
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
WARNING: Unable to calculate area centroid
WARNING: Unable to calculate area centroid
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
...
Attaching centroids...
 100%
Number of nodes: 32451
Number of primitives: 59076
Number of points: 0
Number of lines: 0
Number of boundaries: 48083
Number of centroids: 10993
Number of areas: 16925
Number of isles: 1335
WARNING: Number of incorrect boundaries: 36
-
Some input polygons are overlapping each other.
If overlapping is not desired, the data need to be cleaned.
The input could be cleaned by snapping vertices to each other.
Estimated range of snapping threshold: [1e-13, 1e-05]
Try to import again, snapping with at least 1e-13: 'snap=1e-13'

--> the messages are the same. But...

# snapping
GRASS 7.1.svn (eu_etrs89):~ > v.in.ogr
/data/maps/nuts3/NUTS_2010_03M_SH/Data/NUTS_RG_03M_2010.shp
output=NUTS_RG_03M_2010 snap=1e-08 --o
Note: In latitude-longitude coordinate system specify threshold in degree
unit
Check if OGR layer  contains polygons...
 100%
WARNING: Vector map  already exists and will be
 overwritten
Importing 1920 features (OGR layer )...
 100%
-
Registering primitives...
24361 primitives registered
844894 vertices registered
Number of nodes: 15122
Number of primitives: 24361
Number of points: 0
Number of lines: 0
Number of boundaries: 24361
Number of centroids: 0
Number of areas: -
Number of isles: -
-
Cleaning polygons
-
Snapping boundaries (threshold = 1.000e-08)...
Reading features...
Snap vertices Pass 1: select points
 100%
Snap vertices Pass 2: assign anchor vertices
 100%
Snap vertices Pass 3: snap to assigned points
 100%
-
Breaking polygons...
Breaking polygons (pass 1: select break points)...
 100%
Breaking polygons (pass 2: break at selected points)...
 100%
-
Removing duplicates...
 100%
-
Breaking boundaries...
 100%
-
Removing duplicates...
 100%
-
Cleaning boundaries at nodes...
 100%
-
Merging boundaries...
 100%
-
Removing dangles...
 100%
-
Building areas...
 100%
2759 areas built
1315 isles built
Number of nodes: 20120
Number of primitives: 94462
Number of points: 0
Number of lines: 0
Number of boundaries: 94462
Number of centroids: 0
Number of areas: 2759
Number of isles: 1315
-
Removing bridges...
 100%
-
Registering primitives...
5664 primitives registered
214577 vertices registered
Building areas...
 100%
2759 areas built
1315 isles built
Attaching islands...
 100%
Number of nodes: 4220
Number of primitives: 5664
Number of points: 0
Number of lines: 0
Number of boundaries: 5664
Number of centroids: 0
Number of areas: 2759
Number of isles: 1315
-
Finding centroids for OGR layer ...
 100%
-

Re: [GRASS-dev] Building GRASS packages from tarball on Launchpad

[Vaclav Petras]

On Wed, Feb 11, 2015 at 3:54 PM, Martin Landa 
wrote:

> > As a quick solution for your problem, is to set package version in
> > debian/chagelog to something like 7.0.0~RC2-1 [2]
>
> done, btw, why '~'? Is it some kind of naming convention? I would
> expect just 7.0.0RC2-1.


Semantic Versioning 2.0.0 says you should use hyphen (7.0.0-RC2-1).
Semantic Versioning 1.0.0-beta used nothing (7.0.0RC2-1).

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

Re: [GRASS-dev] Building GRASS packages from tarball on Launchpad

[Martin Landa]

Hi,

2015-02-10 17:51 GMT+01:00 Ivan Mincik :

> We should really move to Debian packaging done inside of DebianGIS [1]
> for final 7.0 version (Sebastiaan from DebianGIS in CC). I can provide
> some help for this.

seems to be reasonable to me.

> As a quick solution for your problem, is to set package version in
> debian/chagelog to something like 7.0.0~RC2-1 [2]

done, btw, why '~'? Is it some kind of naming convention? I would
expect just 7.0.0RC2-1.

Martin

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

Re: [GRASS-dev] Building GRASS packages from tarball on Launchpad

[Martin Landa]

Hi Ivan,

2015-02-10 9:34 GMT+01:00 Martin Landa :
> dpkg-source -b pkg-grass
> dpkg-source: info: using options from pkg-grass/debian/source/options:
> --extend-diff-ignore=(^|/)(config\.sub|config\.guess|mswindows/osgeo4w/grass.tmpl|config.log)$
> dpkg-source: error: can't build with source format '3.0 (native)':
> native package version may not have a revision
> dpkg-buildpackage: error: dpkg-source -b pkg-grass gave error exit status 255
> debuild: fatal error at line 1376:
> dpkg-buildpackage -rfakeroot -d -us -uc -S -sa failed
> gbp:error: 'debuild -S -sa' failed: it exited with 29

I managed to solve this problem, the last command I entered was:

dput ppa:grass/grass-stable ../grass70_7.0.0RC2-1_source.changes

it seems to be OK

Uploading to ppa (via ftp to ppa.launchpad.net):
  Uploading grass70_7.0.0RC2-1.dsc: done.
  Uploading grass70_7.0.0RC2-1.tar.gz: done.
  Uploading grass70_7.0.0RC2-1_source.changes: done.

But I cannot find at Launchpad [1] any "button" where I could launch
building process...

Thanks again for the patience (being debian user who has no experience
with creating packages)! Martin

[1] https://launchpad.net/~grass/+archive/ubuntu/grass-stable/+packages

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

Re: [GRASS-dev] v.in.ogr: islands not recognized

[Markus Metz]

On Wed, Feb 11, 2015 at 9:34 PM, Markus Neteler  wrote:
> HI,
>
> I tried to import the NUTS3 map(s) from EU which leads to some obscur
> warnings (see below). While most can be solved with a "mild" snapping,
> still four islands are reported as an error. They are Andorra, etc and
> apparently really valid. The error message though suggests that the
> import was not successful. Could this be fixed?

This might have been fixed already in trunk, please test!

Markus M

>
> # Download NUTS3 2010, 3M and 10M
> # 
> http://ec.europa.eu/eurostat/web/gisco/geodata/reference-data/administrative-units-statistical-units
>
> # create new location from SHP file
> grass70 -c NUTS_BN_03M_2010.shp ~/grassdata/eu_etrs89
> g.proj -w
>
> # import NUTS3 polygons (performs topology check)
> v.in.ogr input=NUTS_RG_03M_2010.shp output=NUTS_RG_03M_00
> ...
> Cleaning polygons
> -
> Breaking polygons...
> ...
> -
> Building areas...
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
> ...
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
>  100%
> 16926 areas built
> 1325 isles built
> Number of nodes: 113763
> Number of primitives: 37
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 37
> Number of centroids: 0
> Number of areas: 16926
> Number of isles: 1325
> WARNING: Number of incorrect boundaries: 157
> -
> Removing bridges...
>  100%
> -
> Registering primitives...
> 48083 primitives registered
> 343316 vertices registered
> Building areas...
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
> ...
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
>  100%
> 16925 areas built
> 1335 isles built
> Attaching islands...
>  100%
> Number of nodes: 32451
> Number of primitives: 48083
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 48083
> Number of centroids: 0
> Number of areas: 16925
> Number of isles: 1335
> WARNING: Number of incorrect boundaries: 36
> WARNING: Vect_get_point_in_poly_isl(): collapsed area
> WARNING: Unable to calculate area centroid
> WARNING: Vect_get_point_in_poly_isl(): collapsed area
> WARNING: Unable to calculate area centroid
> WARNING: Vect_get_point_in_poly_isl(): collapsed area
> WARNING: Unable to calculate area centroid
> WARNING: Vect_get_point_in_poly_isl(): collapsed area
> ...
> WARNING: Unable to calculate area centroid
> WARNING: Vect_get_point_in_poly_isl(): collapsed area
> WARNING: Unable to calculate area centroid
> -
> Finding centroids for OGR layer ...
>  100%
> -
> Writing centroids...
>  100%
> WARNING: 9912 areas represent more (overlapping) features, because polygons
>  overlap in input layer(s). Such areas are linked to more than 1
>  row in attribute table. The number of features for those areas is
>  stored as category in layer 2
> -
> 7007 input polygons
> Total area: 5.75852E+12 (16925 areas)
> Overlapping area: 5.74784E+12 (9912 areas)
> Area without category: 5.32057E+08 (19 areas)
> -
> Copying features...
>  100%
> Building topology for vector map ...
> Registering primitives...
> 59076 primitives registered
> 354309 vertices registered
> Building areas...
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
> ...
> WARNING: Area of size = 0.0 ignored
> WARNING: Area of size = 0.0 ignored
>  100%
> 16925 areas built
> 1335 isles built
> Attaching islands...
>  100%
> Attaching centroids...
>  100%
> Number of nodes: 32451
> Number of primitives: 59076
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 48083
> Number of centroids: 10993
> Number of areas: 16925
> Number of isles: 1335
> WARNING: Number of incorrect boundaries: 36
> -
> WARNING: Errors were encountered during the import
> Estimated range of snapping threshold: [1e-13, 1e-05]
> Try to import again, snapping with at least 1e-13: 'snap=1e-13'
>
> # --> the "WARNING: Vect_get_point_in_poly_isl(): collapsed area"
> looks like a debug message to an average user.
>
>
>
> # NEW ATTEMPT WITH SNAPPING
> GRASS 7.0.0svn (eu_etrs89): > v.in.ogr input=NUTS_RG_03M_2010.shp
> output=NUTS_RG_03M_2010 snap=1e-8 --o
> ...
> Writing centroids...
>  100%
> WARNING: 2748 areas represent more (overlapping) features, because polygons
>  overlap in input layer(s). Such areas are linked to more than 1
>  

[GRASS-dev] v.in.ogr: islands not recognized

[Markus Neteler]

HI,

I tried to import the NUTS3 map(s) from EU which leads to some obscur
warnings (see below). While most can be solved with a "mild" snapping,
still four islands are reported as an error. They are Andorra, etc and
apparently really valid. The error message though suggests that the
import was not successful. Could this be fixed?

# Download NUTS3 2010, 3M and 10M
# 
http://ec.europa.eu/eurostat/web/gisco/geodata/reference-data/administrative-units-statistical-units

# create new location from SHP file
grass70 -c NUTS_BN_03M_2010.shp ~/grassdata/eu_etrs89
g.proj -w

# import NUTS3 polygons (performs topology check)
v.in.ogr input=NUTS_RG_03M_2010.shp output=NUTS_RG_03M_00
...
Cleaning polygons
-
Breaking polygons...
...
-
Building areas...
WARNING: Area of size = 0.0 ignored
WARNING: Area of size = 0.0 ignored
WARNING: Area of size = 0.0 ignored
WARNING: Area of size = 0.0 ignored
...
WARNING: Area of size = 0.0 ignored
WARNING: Area of size = 0.0 ignored
 100%
16926 areas built
1325 isles built
Number of nodes: 113763
Number of primitives: 37
Number of points: 0
Number of lines: 0
Number of boundaries: 37
Number of centroids: 0
Number of areas: 16926
Number of isles: 1325
WARNING: Number of incorrect boundaries: 157
-
Removing bridges...
 100%
-
Registering primitives...
48083 primitives registered
343316 vertices registered
Building areas...
WARNING: Area of size = 0.0 ignored
WARNING: Area of size = 0.0 ignored
WARNING: Area of size = 0.0 ignored
...
WARNING: Area of size = 0.0 ignored
WARNING: Area of size = 0.0 ignored
 100%
16925 areas built
1335 isles built
Attaching islands...
 100%
Number of nodes: 32451
Number of primitives: 48083
Number of points: 0
Number of lines: 0
Number of boundaries: 48083
Number of centroids: 0
Number of areas: 16925
Number of isles: 1335
WARNING: Number of incorrect boundaries: 36
WARNING: Vect_get_point_in_poly_isl(): collapsed area
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
...
WARNING: Unable to calculate area centroid
WARNING: Vect_get_point_in_poly_isl(): collapsed area
WARNING: Unable to calculate area centroid
-
Finding centroids for OGR layer ...
 100%
-
Writing centroids...
 100%
WARNING: 9912 areas represent more (overlapping) features, because polygons
 overlap in input layer(s). Such areas are linked to more than 1
 row in attribute table. The number of features for those areas is
 stored as category in layer 2
-
7007 input polygons
Total area: 5.75852E+12 (16925 areas)
Overlapping area: 5.74784E+12 (9912 areas)
Area without category: 5.32057E+08 (19 areas)
-
Copying features...
 100%
Building topology for vector map ...
Registering primitives...
59076 primitives registered
354309 vertices registered
Building areas...
WARNING: Area of size = 0.0 ignored
WARNING: Area of size = 0.0 ignored
WARNING: Area of size = 0.0 ignored
...
WARNING: Area of size = 0.0 ignored
WARNING: Area of size = 0.0 ignored
 100%
16925 areas built
1335 isles built
Attaching islands...
 100%
Attaching centroids...
 100%
Number of nodes: 32451
Number of primitives: 59076
Number of points: 0
Number of lines: 0
Number of boundaries: 48083
Number of centroids: 10993
Number of areas: 16925
Number of isles: 1335
WARNING: Number of incorrect boundaries: 36
-
WARNING: Errors were encountered during the import
Estimated range of snapping threshold: [1e-13, 1e-05]
Try to import again, snapping with at least 1e-13: 'snap=1e-13'

# --> the "WARNING: Vect_get_point_in_poly_isl(): collapsed area"
looks like a debug message to an average user.



# NEW ATTEMPT WITH SNAPPING
GRASS 7.0.0svn (eu_etrs89): > v.in.ogr input=NUTS_RG_03M_2010.shp
output=NUTS_RG_03M_2010 snap=1e-8 --o
...
Writing centroids...
 100%
WARNING: 2748 areas represent more (overlapping) features, because polygons
 overlap in input layer(s). Such areas are linked to more than 1
 row in attribute table. The number of features for those areas is
 stored as category in layer 2
-
7007 input polygons
Total area: 5.75852E+12 (2759 areas)
Overlapping area: 5.74784E+12 (2748 areas)
Area without category: 5.32057E+08 (4 areas)
-
Copying features...
 100%
Building topology for vector

[GRASS-dev] [GRASS GIS] #2587: copying attribute tables very inefficient if tables are in same database

[GRASS GIS]

#2587: copying attribute tables very inefficient if tables are in same database
--+-
 Reporter:  mlennert  |   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.1.0
Component:  Database  | Version:  svn-trunk
 Keywords:  libdb copy table  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-
 The function copy_table in lib/db/dbmi_client/copy_tab.c seems very
 inefficient to me when both the old and the new table are in the same
 database and it is a database with real SQL functionalities. IIUC, the
 function actually selects all rows from the input table into a cursor and
 the inserts them, row by row, into the output table. With a large table
 this takes a long time.

 Using a simple "CREATE TABLE new_table AS SELECT [*, ListOfColumns] FROM
 old_table WHERE [Conditions]" is much faster !

 So, it would be a great addition if for the relevant drivers, such as
 SQLite and PostgreSQL, could use this approach.

 P.S. There is no LibDB component in the tracker. Don't know if there
 should be...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] NVIZ broken in GRASS 7.0 RC2

[Anna Petrášová]

On Tue, Feb 10, 2015 at 10:46 PM, Michael Barton 
wrote:

>  Maybe. I just looked at the code and I agree that it looks OK.
>
>  The problem seems to be somewhere in
>
>   def _createSurfacePage(self, parent):
>
>  The ‘selection’ (map selection for surfaces) part seems fine and it is
> possible to select a map. But the remaining widgets don’t work (e.g.
> ‘draw’, ‘mode’, etc).
>
>  The change sets you reference are not in the section where the
> SurfacePage and its controls are defined. Hopefully, these have something
> to do with with it anyway and you can find out what is the problem.
>
>
I reverted the previous change which was fixing a problem on Windows. The
problem there is initialization, where on each system the initialization
events behave differently and I would need more time to rewrite it.
I also removed all progressbar calls on Mac in nviz, because I was getting
some recursion problems which were slowing down the gui. I don't really
have time for proper fix (if there is any).
Could you test this change (r64564), if you can see any improvement so that
I can backport it?

Anna


> Michael
> 
>  C. Michael Barton
>  Director, Center for Social Dynamics & Complexity
>  Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
>  Arizona State University
>
>  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>  www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  On Feb 10, 2015, at 5:27 PM, Anna Petrášová 
> wrote:
>
>
>
> On Tue, Feb 10, 2015 at 6:50 PM, Michael Barton 
> wrote:
>
>> I just compiled RC2 today for the Mac.
>>
>>  The NVIZ control panels have been redesigned to use staticbox
>> containers. But these have not been defined in the correct order with their
>> contents. So mouse clicks do not register.  This is probably a simple fix.
>> But I can’t post the broken binaries.
>>
>
>  I don't understand, there has been no such change.  But I suspect this
> one
>
> http://trac.osgeo.org/grass/changeset/64299/grass/branches/releasebranch_7_0/gui/wxpython/nviz/tools.py
>  you can try to see if this is the revision when it stopped working. I
> will try to get access to a Mac to fix it.
>
>  Anna
>
>>
>>  Michael
>> 
>>  C. Michael Barton
>>  Director, Center for Social Dynamics & Complexity
>>  Professor of Anthropology, School of Human Evolution & Social Change
>> Head, Graduate Faculty in Complex Adaptive Systems Science
>>  Arizona State University
>>
>>  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>>  www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] problem using GRASS Python interface from QGIS in windows

[Luca Delucchi]

Hi everybody,

for a project I'm using grass python interface from QGIS. Everything
is working on Linux (I tested different OS) but on windows I get this
error

Traceback (most recent call last):
 File "C:\Users\delucchil\.qgis2\python\plugins\stem\tools\feat_vege.py",
line 106, in onRunLocal
   tempin, tempout, gs = STEMUtils.temporaryFilesGRASS(name)
 File "C:\Users\delucchil\.qgis2\python\plugins\stem\stem_utils.py",
line 304, in temporaryFilesGRASS
   gs = stemGRASS(pid, grassdatabase, location, grassbin, epsg)
 File "C:\Users\delucchil\.qgis2\python\plugins\stem\libs\grass_stem.py",
line 103, in __init__
   gcore.create_location(grassdatabase, location, epsg=epsg)
 File "C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\grass\script\core.py",
line 1351, in create_location
   gisdbase = gisenv()['GISDBASE']
 File "C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\grass\script\core.py",
line 902, in gisenv
   s = read_command("g.gisenv", flags='n')
 File "C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\grass\script\core.py",
line 424, in read_command
   process = pipe_command(*args, **kwargs)
 File "C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\grass\script\core.py",
line 399, in pipe_command
   return start_command(*args, **kwargs)
 File "C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\grass\script\core.py",
line 354, in start_command
   if debug_level() > 0:
 File "C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\grass\script\core.py",
line 1485, in debug_level
   _debug_level = int(gisenv().get('DEBUG', 0))
 File "C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\grass\script\core.py",
line 902, in gisenv
   s = read_command("g.gisenv", flags='n')
 File "C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\grass\script\core.py",
line 424, in read_command
   process = pipe_command(*args, **kwargs)
 File "C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\grass\script\core.py",
line 399, in pipe_command
   return start_command(*args, **kwargs)
 File "C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\grass\script\core.py",
line 360, in start_command
   return Popen(args, **popts)
 File "C:\OSGeo4W\apps\grass\grass-7.0.0RC2\etc\python\grass\script\core.py",
line 62, in __init__
   subprocess.Popen.__init__(self, args, **kwargs)
 File "C:\OSGeo4W\apps\Python27\lib\subprocess.py", line 703, in __init__
   errread, errwrite) = self._get_handles(stdin, stdout, stderr)
 File "C:\OSGeo4W\apps\Python27\lib\subprocess.py", line 839, in _get_handles
   p2cread = self._make_inheritable(p2cread)
 File "C:\OSGeo4W\apps\Python27\lib\subprocess.py", line 878, in
_make_inheritable
   _subprocess.DUPLICATE_SAME_ACCESS)
WindowsError: [Error 6] Handle non valido

I don't know if it is a problem of GRASS, or QGIS or subprocess, can
someone help me?

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] On GSoC Proposal "New easy-to-use command line interface for GRASS GIS"

[Vaclav Petras]

On Wed, Feb 11, 2015 at 3:20 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> Vaclav,
>
> I don't want to mess with the wiki page, so I'm sending my remarks here.
> If you (and others) think that this kind of discussion should go directly
> onto the page then I can do that.
>
> Mailing list is the right place to discuss it but otherwise, feel free to
edit the ideas.


> I've looked at your proposal for GSoC and I think I understand the reasons
> for it. However, I do have a few remarks:
>
> - "The GRASS GIS Database, Location and Mapset should be created on the
> fly and deleted afterwards (the .grassrc wouldn't be used)."
>
> How is this different from what QGIS Processing already does now ?
>
> It is not. The difference is that GRASS GIS part of QGIS Processing would
not have to deal with it because GRASS GIS itself would solve it. However,
the main point is that this does not apply only to QGIS Processing.


> - "There are different workarounds for calling GRASS modules without
> starting GRASS explicitly, or running GRASS in a batch mode. However, none
> of these allows one to skip the database setup phase. This leads to the
> need for constant reimplementing of setup, import and export steps in
> various environments including user scripts (Bash, Python, R), QGIS
> Processing, gvSIG/SEXTANTE, uDig/JGrassTools and all the web/server/cloud
> tools which use GRASS GIS as a processing backend."
>
> Idem: if you create GISDBASE, etc on the fly, what is it you are proposing
> to change through this project ?
>

It will work the same. The change is in API approach and place where the on
the fly creation, import and export is done. I propose that it should be
done in GRASS GIS in a best way possible, once and for all, i.e. all the
other projects and users who wants to use "GRASS without starting it
explicitly" will be provided with API which solves this for them.

What I'm afraid of is if this is convenient enough and if it will actually
work for all, e.g. because of performance issues, interface complexity
(getting files from it) and complicated data sources such as PostGIS.

>
> - "The input maps could be linked (external) rather than imported (except
> for the cases when projection differs) which should be faster than import."
>
> Please don't forget issues of topology that can arise when you use
> v.external. E.g. compare the result of
>
> v.overlay ain=boundary_municp atyp=area bin=zipcodes_wake btype=area
> op=and out=muni_and_zipcodes
>
> using both imported and externally linked maps...
>
> Yes, I forgot to discuss sentence from #2579: "But obviously we could be
hitting issues with projection and topology here, so it is a bit tricky."
which is quite an issue.

When the external map is raster, it is not an issue, when it is a PostGIS
vector, it can be linked with topology (it it exists). Shapefile should be
imported and perhaps cleaned (expensive) but output might be just linked.
These are the complexities which should be solved inside GRASS GIS, so that
caller does not have to know all the GRASS tricks.


> In general, IIUC, what you are looking for is actually a form of special
> script that:
>
> - creates a location based on the input data (question: how to handle
> input data that is not in the same projection ?)
>
> - links (or imports) the data into that location
>
> - executes the command and saves the output via r/v.external.out
>
> This seems like a very short project to put in place.
>
> That's basically it and was also afraid of this being too simple. However,
I asked myself, if it is so simple, why we don't have it already? So,
probably there is a lot of issues of different formats (ranging from
potentially large but simple GeoTIFF, through messy Shapefile, to complex
PostGIS with topology), special (relatively unique) GRASS data types
(spatio-temporal data), projections (no projections, different projections
for different files, broken projections) and determining what should be
imported and exported (without the need to specify file - grass map pairs
manually, this might be really challenging for r.mapcalc).

I don't see more issues now but I'm afraid there are some more (this is a
call for ideas).

I think that the interface implemented in patch for #2579 is great
improvement in convenience and I'm going to commit it but it does not
address the import/export part (and reimplementing this over and over
again). Does this seems reasonable to you?

Vaclav

http://trac.osgeo.org/grass/ticket/2579

Or is there something I'm missing ?
>
> Moritz
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2586: Display of labels in raster query results window is limited to the first 60 characters

[GRASS GIS]

#2586: Display of labels in raster query results window is limited to the first 
60
characters
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  svn-releasebranch70  
 Keywords:  query|Platform:  Linux
  Cpu:  Unspecified  |  
-+--
Changes (by annakrat):

  * keywords:  => query
  * milestone:  6.4.5 => 7.0.0


Comment:

 I assume you are talking about the query dialog. You can make the column
 wider to show the entire label, but at least on my system, the place where
 the column ends and where you should drag it is not very well visible, so
 I enlarged the default width of the column in r64562 and r64563. Let me
 know if that's what you meant.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Preparation of ideas pages for GSoC 2015 (deadline: 18th February!)

[Margherita Di Leo]

Dear All,

*(Apologies for cross posting)*

*GSoC 2015* was officially announced earlier this year. The applications
for mentoring organizations are now open and this year Hamish Bowman and
myself will be applying for OSGeo's participation.

The application deadline for mentoring organizations is the 20th of
February, and right after that, Google will proceed examining the
organizations. The showcase for evaluating the applications are the GSoC
ideas pages [1], and for this reason, they need to be in perfect shape.
This means that OSGeo teams are required to set up and shape their pages *this
week*, coordinating their teams through their dev mailing lists. The pages
will then linked to the main GSoC 2015 ideas page on the wiki.

Please bear in mind that there is no guarantee whatsoever of the acceptance
by Google based on the success of previous years, but they will judge the
organizations *only on the basis of ideas pages for 2015.*

Please forward this email to your project leaders and past GSoC mentors,
and start listing ideas right away!

Please cc soc list with your doubts and questions.


 [1] http://en.flossmanuals.net/GSoCMentoring/making-your-ideas-page/

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Howto use a Python function as error handler in libgis

[Sören Gebbert]

Dear Developers,
any clue about how to register a Python function
as error handler in libgis using libgis.G_add_error_handler()?

Or is there any other way to recognize a fatal error call from libgis in Python?
I tried to catch the signals, unfortunately is Python not able to
catch signals emitted from a C-library.
Is it possible to write an error handler in C that can transfer a
signal that Python is able to catch using the Python API?

My current approach is a Python-thread that checks if the Python
process that accesses the C-library functions every 0.2 seconds is
still alive. The reason why i need this is, that the Python Pipe
communication object between the processes must be closed correctly to
avoid endless waiting in the receiver process/thread.

Any suggestions are welcome.

Best regards
Soeren

2015-02-06 23:41 GMT+01:00 Sören Gebbert :
> Dear developers,
> i am trying to register a Python function as error handler callback
> using ctypes in libgis.
> I use this code in the temporal framework:
>
>
> {{{
> def error_handler(data):
> pass
>
> CALLBACK = CFUNCTYPE(None, c_void_p)
> CALLBACK.restype = None
> CALLBACK.argtypes = c_void_p
>
> cerror_handler = CALLBACK(error_handler)
>
> libgis.G_add_error_handler(cerror_handler, POINTER(None))
> }}}
>
> Unfortunately i get this error:
>
> {{{
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/multiprocessing/process.py", line 258, in 
> _bootstrap
> self.run()
>   File "/usr/lib/python2.7/multiprocessing/process.py", line 114, in run
> self._target(*self._args, **self._kwargs)
>   File 
> "/home/soeren/src/grass7.1/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/temporal/c_libraries_interface.py",
> line 759, in c_library_server
> libgis.G_add_error_handler(cerror_handler, POINTER(None))
> ArgumentError: argument 1: : expected
> CFunctionType instance instead of CFunctionType
> }}}
>
> Does anyone know what the correct way is to register a Python function
> as error handler in libgis?
>
> Any help is highly welcome.
>
> Best regards
> Soeren
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2584: Vectors skipping columns (character limit !!!) while exporting to OGR data

[Luca Delucchi]

On 10 February 2015 at 18:58, Newcomb, Doug  wrote:
> Sajid,

Hi Doug,

> The shape file format has a 10 character limit on field name length.  The
> smallest field name I see above is 11. see,
> http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Geoprocessing%20considerations%20for%20shapefile%20output
>

Yes, but If I remember well v.out.ogr was cutting the field name
length more then 10. Am I wrong?
Otherwise we could add this feature..

> Doug
>


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2586: Display of labels in raster query results window is limited to the first 60 characters

[GRASS GIS]

#2586: Display of labels in raster query results window is limited to the first 
60
characters
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.5
Component:  Default  | Version:  svn-releasebranch70  
 Keywords:   |Platform:  Linux
  Cpu:  Unspecified  |  
-+--
 Using the query raster function shows only the first 60 characters of the
 raster label.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] On GSoC Proposal "New easy-to-use command line interface for GRASS GIS"

[Moritz Lennert]

Vaclav,

I don't want to mess with the wiki page, so I'm sending my remarks here. 
If you (and others) think that this kind of discussion should go 
directly onto the page then I can do that.


I've looked at your proposal for GSoC and I think I understand the 
reasons for it. However, I do have a few remarks:


- "The GRASS GIS Database, Location and Mapset should be created on the 
fly and deleted afterwards (the .grassrc wouldn't be used)."


How is this different from what QGIS Processing already does now ?

- "There are different workarounds for calling GRASS modules without 
starting GRASS explicitly, or running GRASS in a batch mode. However, 
none of these allows one to skip the database setup phase. This leads to 
the need for constant reimplementing of setup, import and export steps 
in various environments including user scripts (Bash, Python, R), QGIS 
Processing, gvSIG/SEXTANTE, uDig/JGrassTools and all the 
web/server/cloud tools which use GRASS GIS as a processing backend."


Idem: if you create GISDBASE, etc on the fly, what is it you are 
proposing to change through this project ?


- "The input maps could be linked (external) rather than imported 
(except for the cases when projection differs) which should be faster 
than import."


Please don't forget issues of topology that can arise when you use 
v.external. E.g. compare the result of


v.overlay ain=boundary_municp atyp=area bin=zipcodes_wake btype=area 
op=and out=muni_and_zipcodes


using both imported and externally linked maps...

In general, IIUC, what you are looking for is actually a form of special 
script that:


- creates a location based on the input data (question: how to handle 
input data that is not in the same projection ?)


- links (or imports) the data into that location

- executes the command and saves the output via r/v.external.out

This seems like a very short project to put in place.

Or is there something I'm missing ?

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

Re: [GRASS-dev] [GRASS GIS] #2579: Specify command to be exectued as parameter of grass command

[GRASS GIS]

#2579: Specify command to be exectued as parameter of grass command
--+-
 Reporter:  wenzeslaus|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Startup   | Version:  svn-trunk 
   
 Keywords:  batch job, GRASS_BATCH_JOB, init  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 Why do you need the --mapset as in:

 {{{
 grass7 --mapset ~/grassdata/location/mapset --batch r.mapcalc "aaa = 5"
 }}}

 ?

 The current GRASS startupt script already allows to define a mapset at
 startup, so this seems redundant.

-- 
Ticket URL: 
GRASS GIS 

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