Re: [GRASS-dev] PostGIS manager for GRASS GIS

[Mohit Kumar]

Hi all,
Shall I go with this PostGIS manager proposal and apply on melange 
website?

Any further suggestions are welcome
Only one day is left to appply.

Thanks and regards,
Mohit

On Wed, 04 Apr 2012 01:56:17 +0530, Mohit Kumar wrote:

Hello Martin,
Sorry couldn't reply earlier as I was stuck with some college work.

On Mon, 2 Apr 2012 21:00:51 +0200, Martin Landa wrote:

Hi,

2012/4/2 Mohit Kumar :
I am interested in making a PostGIS manager in GRASS as a GSoc 
2012 task.
PyGreSQL is a python module that allows easy use of database 
operation

API
from a pyhton script. So it will be like a wrapper over
the database. This can be done using wxPython and will be OS 
independent.
Sorry to bug you all, but I am very much interested in developing 
for

GRASS.


[...]

there is new development ongoing for this in GRASS 7, perhaps a 
good

moment to integrate a manager. Maybe Martin has some insights for
us over the next days.


Its good to know that development is ongoing for this in GRASS, I 
sincerely

want to work on this as my GSoc task.


the current PostGIS-related development in G7 is not much related to
this idea. The vector engine in G7 is currently able to read PostGIS
geometry data natively without any abstract level (like 
OGR-PostgreSQL
driver). Also write support has been recently implemented. The 
current

implementation is focused on simple feature access, GRASS builds a
pseudo-like topology as for OGR links (see v.external). At this 
moment

I am working on PostGIS topology support in GRASS.

I have made a brief idea for the manager. The following are the 
various

modules of the manager
1. Setup connection : This module will set up the connection with 
the remote
database. It will take the input parameters from user and pass them 
to a
connection string. After the connection has been established, the 
user will
be shown the various tables(maps) that are stored and other 
information

about the database and the connection


This is already available in wxGUI [1]. Of course there is always a
space for any kind of improvements. But basically it's already 
there,
to add widgets for entering username and password is quite easy 
task.


2. View and edit data : This will display the data of the table in 
a window
frame. One can view the map and modify the table values or the 
attributes.


Also possible in current wxGUI [2]. You just create a link using
`v.external` and display the map in the map canvas as normal GRASS
vector map. Also direct OGR access [3] is possible (no links,
pseudo-topology built on the fly)

3. Import to GRASS Data : This gives the user an option to save the 
data in
Grass format for further processing/analysis of the data. This also 
gives

user an option to discard the data which is of no use.


Possible with `v.in.ogr`. Simple wrapper based `v.in.ogr` for
importing PostGIS is already there [4].

4. Execute PostGis functions (geometry processing)on database and 
save

output in grass data format.


This could be improvement.

5. SQL interface : This provides the advanced user to modify the 
database by

use of direct SQL commands on the database.


6. Export GRASS data to PostGIS data : Convert the Grass Data to 
SQL
database. First convert the Grass data to Esri Shapefile(.shp) 
using OGR and

then converting that data to SQL database (shape2sql).


Why?? You can export data directly using `v.out.ogr` [5]. No need 
for

Shapefiles, that's bad idea.

7. Projection support : I was also thinking of adding projection 
support to

the manager.


In which sense, do you mean on-the fly re-projection (ST_transform)?

Martin

[1]

http://grass.osgeo.org/wiki/Working_with_external_data_in_GRASS_7#Using_wxGUI
[2]

http://grass.osgeo.org/wiki/Working_with_external_data_in_GRASS_7#Digitize_OGR_layer_using_wxGUI
[3]

http://grass.osgeo.org/wiki/Working_with_external_data_in_GRASS_7#Direct_access_to_external_data
[4] http://grass.osgeo.org/wiki/PostGIS#Import_into_GRASS
[5] http://grass.osgeo.org/wiki/PostGIS#Export_to_PostGIS


Thanks for your feedback.
I know that various modules are possible in GRASS wxGUI. I want to
integrate them all and provide a direct interface for them. Regarding
data Export I was thinking about 'v.out.ogr' only.
And I was talking about on-the fly re-projection. The projection
tables can be stored in which ever way the user wants.
What more would you like to add to the current idea to make it worth
for a GSOC proposal?
Looking forward to your support.

Regards,
Mohit Kumar (mohitkharb on irc)
Lab For Spatial Informatics
International Institute of Information and Technology
Hyderabad, India
+91-970-3840-175
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev



Mohit Kumar (mohitkharb on irc)
Lab For Spatial Informatics
International Institute of Information and Technology
Hyderabad, India
+91-970-3840-175

___
grass-dev maili

[GRASS-dev] [GRASS GIS] #1636: r.patch in GRASS 7 does not respect region settings

[GRASS GIS]

#1636: r.patch in GRASS 7 does not respect region settings
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.0.0
Component:  Default | Version:  svn-trunk
 Keywords:  |Platform:  Unspecified  
  Cpu:  x86-64  |  
+---
 When using r.patch two patch one smaller and one larger raster layer in
 GRASS 7 (revision 51117 and previous revisions), the new layer created is
 of the extend of the first (smaller) layer. Regions extent is set to equal
 that of the second larger raster layer.

 In GRASS 6.4 the region settings are respected and the output raster layer
 has the same extent as defined in the region settings.

-- 
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] #1635: allow r.los to run with a point vector layer as input for "coordinate identifying the viewing position"

[GRASS GIS]

#1635: allow r.los to run with a point vector layer as input for "coordinate
identifying the viewing position"
-+--
 Reporter:  lutra|   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  minor|   Milestone:  6.4.3
Component:  Default  | Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 This is my first feature request for GRASS.

 It would be nice for modules like r.los (or even r.lake) to have the
 option to interactively create a list of coordinates or even use a vector
 point layer as input for "coordinate identifying the viewing position".

-- 
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] #1634: wingrass7: i.spectral -error

[GRASS GIS]

#1634: wingrass7: i.spectral -error
--+-
 Reporter:  hellik|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Imagery   | Version:  unspecified  
 Keywords:  wingrass  |Platform:  MSWindows Vista  
  Cpu:  x86-32|  
--+-
 tested with osgeo4w-wingrass7, nc-sample dataset:

 gnuplot is in the path:

 {{{
 _path=C:\OSGeo4W\apps\Python27\Scripts
 OSGEO4W home is C:\OSGeo4W
 Der Befehl "manpath" ist entweder falsch geschrieben oder
 konnte nicht gefunden werden.
 Cleaning up temporary files...
 Starting GRASS GIS...
 WARNUNG: Sperren gleichzeitiger Zugriffe auf ein Mapset ist unter Windows
  nicht m÷glich.

   __  ___   _____
  / / __ \/   | / ___/ ___/   / /  _/ ___/
 / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
/ /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
\/_/ |_/_/  |_///   \/___///

 Welcome to GRASS 7.0.svn??GRASS homepage:
 http://grass.
 osgeo.org
 This version running through:shell
 (C:\OSGeo4W\apps\msys\bin\sh.exe)

 Help is available with the command:  g.manual -i
 See the licence terms with:  g.version -c
 If required, restart the GUI with:   g.gui wxpython
 When ready to quit enter:exit

 GRASS 7.0.svn> gnuplot

 G N U P L O T
 Version 4.6 patchlevel 0last modified 2012-03-04
 Build System: MS-Windows 32 bit

 Copyright (C) 1986-1993, 1998, 2004, 2007-2012
 Thomas Williams, Colin Kelley and many others

 gnuplot home: http://www.gnuplot.info
 faq, bugs, etc:   type "help FAQ"
 immediate help:   type "help"  (plot window: hit 'h')

 gnuplot changed the codepage of this console from 850 to 1252 to
 match the graph window. Some characters might only display correctly
 if you change the font to a non-raster type.

 Terminal type set to 'wxt'
 gnuplot> exit
 GRASS 7.0.svn>
 }}}

 adapted example from the manual:
 http://grass.osgeo.org/grass70/manuals/html70_user/i.spectral.html

 {{{
 GRASS 7.0.svn> i.spectral.py raster=$LIST east_north=637502.25,221744.25
 Traceback (most recent call last):
   File "C:/OSGeo4W/apps/grass/grass-7.0.svn/scripts/i.spectral.py", line
 210, in
  
 main()
   File "C:/OSGeo4W/apps/grass/grass-7.0.svn/scripts/i.spectral.py", line
 205, in
  main
 draw_linegraph(what)
   File "C:/OSGeo4W/apps/grass/grass-7.0.svn/scripts/i.spectral.py", line
 127, in
  draw_linegraph
 xf = file(xfile, 'w')
 IOError: [Errno 13] Permission denied: 'data_x'
 }}}

 {{{
 GRASS 7.0.svn> i.spectral.py -g raster=$LIST
 east_north=637502.25,221744.25
 Traceback (most recent call last):
   File "C:/OSGeo4W/apps/grass/grass-7.0.svn/scripts/i.spectral.py", line
 210, in
  
 main()
   File "C:/OSGeo4W/apps/grass/grass-7.0.svn/scripts/i.spectral.py", line
 203, in
  main
 draw_gnuplot(what, xlabels, output, label)
   File "C:/OSGeo4W/apps/grass/grass-7.0.svn/scripts/i.spectral.py", line
 76, in
 draw_gnuplot
 outf = file(outfile, 'w')
 IOError: [Errno 13] Permission denied: 'data_0'
 GRASS 7.0.svn>
 }}}

 Helmut

-- 
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.dissolve not working with string column

[Markus Metz]

Michael Barton wrote:

> I want to dissolve on sector, but it complains that this is not a "string".

This is still happening in trunk r51246?

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

Re: [GRASS-dev] v.dissolve not working with string column

[Michael Barton]

Right! That's the problem.


v.info -c muro_temp
Displaying column types/names for database connection of layer <1>:
INTEGER|cat
TEXT|Subsector
TEXT|valley
TEXT|sector
GRASS 7.0.svn (Spain_utm_wgs84z30):~ > 

I want to dissolve on sector, but it complains that this is not a "string".

Michael

On Apr 4, 2012, at 9:05 AM, Markus Neteler wrote:

> On Wed, Apr 4, 2012 at 4:58 PM, Michael Barton  wrote:
>> Thanks very much. For sqlite, there is no field type called "character".
> 
> ... but there is TEXT. Please post
> 
> v.info -c muro_temp
> 
> thanks
> markusN

_
C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
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

Re: [GRASS-dev] v.dissolve not working with string column

[Markus Neteler]

On Wed, Apr 4, 2012 at 4:58 PM, Michael Barton  wrote:
> Thanks very much. For sqlite, there is no field type called "character".

... but there is TEXT. Please post

v.info -c muro_temp

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

[GRASS-dev] Re: [GRASS GIS] #548: grass7 - v.reclass with sqlite driver: "Cannot step: SQL logic error or missing database"

[GRASS GIS]

#548: grass7 - v.reclass with sqlite driver: "Cannot step: SQL logic error or
missing database"
--+-
 Reporter:  mlennert  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.3
Component:  Database  | Version:  svn-releasebranch64  
 Keywords:  v.reclass sqlite  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-
Changes (by neteler):

  * version:  svn-trunk => svn-releasebranch64
  * milestone:  7.0.0 => 6.4.3


Comment:

 Backport of trunk r48333 to GRASS 6.5 in r51261. Can I backport to 6.4 as
 well?
 The zipcodes_wake example in comment 11 succeeds.

-- 
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.dissolve not working with string column

[Michael Barton]

Thanks very much. For sqlite, there is no field type called "character". I 
tried changing the field type to varchar, but that didn't work either.

Michael

On Apr 4, 2012, at 1:49 AM, Markus Metz wrote:

> On Wed, Apr 4, 2012 at 8:11 AM, Moritz Lennert
>  wrote:
>> On 04/04/12 07:56, Michael Barton wrote:
>>> 
>>> I'm trying to do a dissolve but keep getting an error saying that it
>>> only works with integer or string columns. But the column I'm using for
>>> the dissolve IS string.
>>> 
>>> GRASS 7.0.svn (Spain_utm_wgs84z30):~ > db.describe table=muro_temp
>>> table:muro_temp
>>> description:
>>> insert:?
>>> delete:?
>>> ncols:4
>>> nrows:177
>>> 
>>> column:cat
>>> description:
>>> type:INTEGER
>>> len:20
>>> scale:0
>>> precision:0
>>> default:
>>> nullok:yes
>>> select:?
>>> update:?
>>> 
>>> column:Subsector
>>> description:
>>> type:TEXT
>>> len:1000
>>> scale:0
>>> precision:0
>>> default:
>>> nullok:yes
>>> select:?
>>> update:?
>>> 
>>> column:valley
>>> description:
>>> type:TEXT
>>> len:1000
>>> scale:0
>>> precision:0
>>> default:
>>> nullok:yes
>>> select:?
>>> update:?
>>> 
>>> column:sector
>>> description:
>>> type:TEXT
>>> len:1000
>>> scale:0
>>> precision:0
>>> default:
>>> nullok:yes
>>> select:?
>>> update:?
>>> 
>>> 
>>> GRASS 7.0.svn (Spain_utm_wgs84z30):~ > v.dissolve input=muro_temp
>>> column=sector output=muro_sectors3
>>> ERROR: Key column must be of type integer or string
>>> GRASS 7.0.svn (Spain_utm_wgs84z30):~ >
>>> 
>>> 
>>> Note above that the column "sector" IS text.
>>> 
>>> So what is wrong?
>> 
>> 
>> v.dissolve checks for integer and character, but not for text.
>> 
>> Try this simple patch:
>> 
>> --- v.dissolve.py   2011-08-17 13:49:29.0 +0200
>> +++ v.dissolve.new.py   2012-04-04 08:04:00.0 +0200
>> @@ -66,7 +66,7 @@
>> except KeyError:
>> grass.fatal(_('Column <%s> not found') % column)
>> 
>> -   if coltype['type'] not in ('INTEGER', 'CHARACTER'):
>> +   if coltype['type'] not in ('INTEGER', 'CHARACTER', 'TEXT'):
>>grass.fatal(_("Key column must be of type integer or string"))
>> 
>> f = grass.vector_layer_db(input, layer)
>> 
> 
> I have committed the patch and also added SMALLINT as valid integer in r51246.
> 
> Markus M

_
C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
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

Re: [GRASS-dev] GsoC2012: High level map interaction with python

[Pietro]

Hi Sören,

2012/4/4 Sören Gebbert :
> [cut]
> The VTK GRASS bridge uses the VTK style[1]. This assures the same
> convincing coding style in
> C++, Java and Python. Therefore it is not Python specific but it
> integrates itself into the VTK
> pipeline framework to use the more than 500 existing algorithms of VTK
> for image, voxel and vector processing.

Thank you Sören. I didn't know!

> [cut]
> The idea why i am pointing you to this interface is not use use its
> coding style, but to get an idea what
> classes are needed and how they should be designed to access the low
> level GRASS library functions.
> You will have to think about this aspect too, since these access
> methods are needed to implement
> more complex and massive data processing ready algorithms. So maybe
> the vtk-grass-bridge will give you
> some interesting insights how the C-level of GRASS works?

Thank you! Although I'm new to C/C++, but I will give a closer look at
the source code of vtk-grass-bridge!
Do you think that this project could achieved during the Google Summer
of Code or do you think that is not realistic, because there are a lot
of things in the project idea that are missing?
Would you be interested in being my mentor?

Best regards.

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

Re: [GRASS-user] Re: [GRASS-dev] trying to update column with another text column

[Moritz Lennert]

On 04/04/12 08:33, Moritz Lennert wrote:

On 04/04/12 08:02, Michael Barton wrote:

I want to update a column with the value of another column. I am using
v.db.update.

The docs say that I can update a column with the value of another column
by specifying that column in the value field. In fact, if I put the
names of numeric columns, this works fine (e.g., v.db.update
map=myvector layer=1 column=summary value=col3 + col4).

But if I do something like this for a string column, I simply get the
string of the name of the column (e.g., v.db.update map=myvector layer=1
column=summary value=col5 put "col5" into the summary column, NOT the
strings that are STORED in col5).

Are the docs wrong or is this a bug?


When the column to update is a string column, the script surrounds the
value given with the value= parameter with quotes. It could check
whether the given value is a column name and then not quote it but then
again, how can we know that the person does not what to just fill a
column with a string that corresponds to the name of another column ?

Try using the qcolumn parameter.

So docs should be updated to reflect that.


How about:

Index: v.db.update.py
===
--- v.db.update.py  (révision 51255)
+++ v.db.update.py  (copie de travail)
@@ -33,12 +33,12 @@
 #%option
 #% key: value
 #% type: string
-#% description: Value to update the column with, can be (combination 
of) other column(s)

+#% description: Value to update the column with
 #% required: no
 #%end
 #%option G_OPT_DB_COLUMN
 #% key: qcolumn
-#% description: Name of attribute column to query
+#% description: Name of other attribute column to query, can be 
combination of columns (e.g. co1+col2)

 #%end
 #%option G_OPT_DB_WHERE
 #%end
Index: v.db.update.html
===
--- v.db.update.html(révision 51255)
+++ v.db.update.html(copie de travail)
@@ -1,8 +1,8 @@
 DESCRIPTION

 v.db.update allows to assign a new value to a column in the
-attribute table connected to a given map. Alternatively, values can be
-copied from another column in the table.
+attribute table connected to a given map. The value parameter 
allows updating with a literal value. Alternatively, with the 
qcol parameter values can be
+copied from another column in the table or be the result of a 
combination or transformation of other columns.


 NOTES


?

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

Re: [GRASS-dev] GsoC2012: High level map interaction with python

[Sören Gebbert]

Hi Pietro,
more below:

2012/4/4 Pietro :
> Hi Sören,
>
> 2012/4/4 Sören Gebbert :
>> Hi Pietro,
>> this is an interesting and very useful submission. A numpy matrix
>> interface would be a valuable addition, but as Markus Metz said, we
>> need also direct row access without reading the whole raster or vector
>> map into the memory.
>
> Exactly, I'm not interesting to the numpy interface, I'm interested to
> use the grass data library in a more pythonic way, similar to numpy
> but using all the smart things that GRASS have.
>
>> Actually with the vtk-grass-bridge there is already an object
>> orientated interface to the grass raster, vector and voxel libraries
>> providing convenient high level access classes and methods for C++,
>> Java and Python[1]. You may orient on this interface when designing
>> the Python GRASS classes?
>> [1] http://code.google.com/p/vtk-grass-bridge
>
> Thank you for the link, I didn't know this interface. It seem quite
> far from a python style: the PEP 8 style guide (Python) says
> methodnames should be lowercase and that sometimes method_names may
> have embedded underscores ...
[snip]

The VTK GRASS bridge uses the VTK style[1]. This assures the same
convincing coding style in
C++, Java and Python. Therefore it is not Python specific but it
integrates itself into the VTK
pipeline framework to use the more than 500 existing algorithms of VTK
for image, voxel and vector processing.

For example the Delaunay triangulation is now as simple as it can be:
{{{
# Init grass variables
init = vtkGRASSInit()
init.Init("VectorDelaunayTriangulation")

# Build the VTK pipeline
# This reader does not need topology information
reader = vtkGRASSVectorPolyDataReader()
reader.SetVectorName("elev_lid792_randpts")

# The Delaunay triangulation
delaunay = vtkDelaunay2D()
delaunay.SetInputConnection(reader.GetOutputPort())

# Start the processing (udpate) and write the resulting
# grass vector map into the grass database
writer = vtkGRASSVectorPolyDataWriter()
writer.SetVectorName("delaunay_triangulation")
writer.SetInputConnection(delaunay.GetOutputPort())
writer.BuildTopoOn()
writer.Update()
}}}

The idea why i am pointing you to this interface is not use use its
coding style, but to get an idea what
classes are needed and how they should be designed to access the low
level GRASS library functions.
You will have to think about this aspect too, since these access
methods are needed to implement
more complex and massive data processing ready algorithms. So maybe
the vtk-grass-bridge will give you
some interesting insights how the C-level of GRASS works?

Best regards
Soeren

[1] http://www.vtk.org/Wiki/VTK_Coding_Standards

btw.:
I included developer list in CC to get this discussion back to the list
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1268: r.out.vtk does not work as desired for RGB images

[GRASS GIS]

#1268: r.out.vtk does not work as desired for RGB images
--+-
  Reporter:  voncasec |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.1
 Component:  Default  | Version:  svn-releasebranch64  
Resolution:  invalid  |Keywords:  vtk  
  Platform:  Linux| Cpu:  x86-64   
--+-
Changes (by neteler):

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


Comment:

 Replying to [ticket:1268 voncasec]:
 > r.out.vtk does not allow a user to export an RGB series of images to vtk
 format without specifying a required image as well.
 >
 > For example, running r.out.vtk for an rgb series, as described in the
 user manual, returns the follwing:
 >
 >
 > {{{
 > r.out.vtk rgbmaps=Landsat_NIR,Landsat_Red,Landsat_Green
 elevation=elevation.10m output=/tmp/out.vtk
 > ERROR:
 > Parameter 'input' (Name of input raster map(s)) is missing.
 > }}}

 For a working example (the input map is the elevation map), see

 http://grass.osgeo.org/wiki/GRASS_and_Paraview#RGB_visualization

 I am not sure that this is a valid bug report. I have improved the
 manual page of r.out.vtk (for all GRASS versions):

 http://grass.osgeo.org/grass64/manuals/html64_user/r.out.vtk.html

 Closing, feel free to reopen if needed.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GsoC2012: High level map interaction with python

[Sören Gebbert]

Hi Pietro,
this is an interesting and very useful submission. A numpy matrix
interface would be a valuable addition, but as Markus Metz said, we
need also direct row access without reading the whole raster or vector
map into the memory.

Actually with the vtk-grass-bridge there is already an object
orientated interface to the grass raster, vector and voxel libraries
providing convenient high level access classes and methods for C++,
Java and Python[1]. You may orient on this interface when designing
the Python GRASS classes?

Best regards
Soeren

[1] http://code.google.com/p/vtk-grass-bridge

Example vector and raster processing in C++, Java and Python:
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Modules/Cxx/v.sample.rast.cxx
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Modules/Java/v_sample_rast.java
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Modules/Python/v.sample.rast.py

vtk-grass-bridge Python unit tests:
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Raster/Testing/Python/GRASSRasterMapReaderWriterTest.py
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Vector/Testing/Python/GRASSVectorMapTopoReaderWriter.py
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Raster3d/Testing/Python/GRASSRaster3dMapReaderWriterTest.py

2012/4/1 Pietro :
> Hi everyone!
>
> I'm Pietro Zambelli a ph.D student of Trento University, I would like
> to apply to the GSoC, my idea in short is: extend the python GRASS API
> to make it more pythonic :-).
>
> I would like to interact with region, raster and vector maps as
> object, using and interacting with the map and the other GRASS
> functionality in a more higher and abstract way.
>
> For people used to `numpy` I would like to interact with the map with
> the same simplicity that I interact with matrix using `numpy`.
>
> For curious people, that want to understand my insane idea I add a new
> page in the Wiki [0] to try to explain what I mean. I have used the
> python doctest [1]: to give an brief idea of how we could interact
> with the new python module, and in case of consensus, as the basis for
> a test-driven development approach for the GSoC.
>
> There are many aspect that could be improved and that must be
> resolved, I try to highlight possible problems. But, of course, I need
> some help to find out more and to understand if the idea, is or not,
> good to contribute to the great GRASS software.
> Please feel free to critique, add new examples, raise problems,
> doubts, etcetera. In particular I would like to invite all developers
> to check to find incoherence/inconsistency with the GRASS and/or
> Python philosophy[2].
>
> Any suggestions and criticism are more than welcome!
>
> Pietro
>
> [http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction]
> [http://docs.python.org/library/doctest.html]
> [http://www.python.org/dev/peps/pep-0020/]
> ___
> 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] GsoC2012: High level map interaction with python

[Markus Metz]

On Sun, Apr 1, 2012 at 12:16 AM, Pietro  wrote:
> Hi everyone!
>
> I'm Pietro Zambelli a ph.D student of Trento University, I would like
> to apply to the GSoC, my idea in short is: extend the python GRASS API
> to make it more pythonic :-).
>
> I would like to interact with region, raster and vector maps as
> object, using and interacting with the map and the other GRASS
> functionality in a more higher and abstract way.
>
> For people used to `numpy` I would like to interact with the map with
> the same simplicity that I interact with matrix using `numpy`.
>
> For curious people, that want to understand my insane idea I add a new
> page in the Wiki [0] to try to explain what I mean. I have used the
> python doctest [1]: to give an brief idea of how we could interact
> with the new python module, and in case of consensus, as the basis for
> a test-driven development approach for the GSoC.
>
> There are many aspect that could be improved and that must be
> resolved, I try to highlight possible problems. But, of course, I need
> some help to find out more and to understand if the idea, is or not,
> good to contribute to the great GRASS software.
> Please feel free to critique, add new examples, raise problems,
> doubts, etcetera. In particular I would like to invite all developers
> to check to find incoherence/inconsistency with the GRASS and/or
> Python philosophy[2].
>
> Any suggestions and criticism are more than welcome!

I like the general concept of making the GRASS python API more
python-like. But I am not so sure about the raw data access in a numpy
way with a matrix holding raster data. Actually I am against it,
because GIS data handling is, because of their potential size,
different from say statistical data handling. When working with raster
data, there are a number of ways how to deal with them in chunks or
rows to avoid memory issues. You can have a look at r.example, the
cache used by r.proj, the segment lib and the rowio lib in order to
better understand how GIS raster algorithm development works. Also the
file-based spatial index in the GRASS 7 vector lib can give you an
idea about GIS data handling. See also the recent post of Alex Mandel
in the user ml [0]. Raw data access should IMHO be left to existing
modules, in particular because you intend to provide an easy to use
GRASS Python API primarily for users.

Markus M

[0] http://osgeo-org.1560.n6.nabble.com/Re-ArcGIS-vs-GRASS-notes-td4679637.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC introduction

[Luca Delucchi]

2012/4/4 Markus Metz :

>
> Definitively! I have converted X-terminal based i.points to the wxGUI
> and worked on the i.ortho.photo suite, so please do not hesitate to
> ask me if you have any questions! You should be able to recycle quite
> a bit of the wxGUI georectifier for a new wxGUI orthorectifier, in
> particular for i.photo.2target.
>

Maybe, the GUI for i.ortho.photo could be the same of i.points?
The user could choose between georectifier and orthorectifier
Maybe this proposal could integrate also something else?

> Markus M
>


-- 
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] GSoC introduction

[Markus Metz]

On Mon, Apr 2, 2012 at 6:54 PM, stepan.turek  wrote:
> Hello,
>
> I would like to introduce my topic for  GSoC.
>
> My proposal for GSoC is porting of module i.ortho.photo into GRASS 7. The
> module is  based on x monitors, which support was removed  from
> GRASS 7, so
> it  is needed to integrate the ortorectification into wxGUI. The
> x-monitor
> support is related to these imaginary functions:
>     photo.2image
>     photo.2target
>
> That would be core of my work in GSoC.
>
> Waiting for your feedback! Do you consider this topic to be suitable for
> GSoC?

Definitively! I have converted X-terminal based i.points to the wxGUI
and worked on the i.ortho.photo suite, so please do not hesitate to
ask me if you have any questions! You should be able to recycle quite
a bit of the wxGUI georectifier for a new wxGUI orthorectifier, in
particular for i.photo.2target.

Markus M

>
> I already have some experience
> in developing in GRASS. This semester I have
> been working on my bachelors thesis, which is focused on implementation on
> WMS support into GRASS GIS and SAGA GIS. So far I have rewritten module
> r.in.wms. This or next week the module should be accessible for testing on
> GRASS
> Addons SVN with name r.in.wms2.
>
> Thanks,
>
> Stepan
>
>
> ___
> 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] v.dissolve not working with string column

[Markus Metz]

On Wed, Apr 4, 2012 at 8:11 AM, Moritz Lennert
 wrote:
> On 04/04/12 07:56, Michael Barton wrote:
>>
>> I'm trying to do a dissolve but keep getting an error saying that it
>> only works with integer or string columns. But the column I'm using for
>> the dissolve IS string.
>>
>> GRASS 7.0.svn (Spain_utm_wgs84z30):~ > db.describe table=muro_temp
>> table:muro_temp
>> description:
>> insert:?
>> delete:?
>> ncols:4
>> nrows:177
>>
>> column:cat
>> description:
>> type:INTEGER
>> len:20
>> scale:0
>> precision:0
>> default:
>> nullok:yes
>> select:?
>> update:?
>>
>> column:Subsector
>> description:
>> type:TEXT
>> len:1000
>> scale:0
>> precision:0
>> default:
>> nullok:yes
>> select:?
>> update:?
>>
>> column:valley
>> description:
>> type:TEXT
>> len:1000
>> scale:0
>> precision:0
>> default:
>> nullok:yes
>> select:?
>> update:?
>>
>> column:sector
>> description:
>> type:TEXT
>> len:1000
>> scale:0
>> precision:0
>> default:
>> nullok:yes
>> select:?
>> update:?
>>
>>
>> GRASS 7.0.svn (Spain_utm_wgs84z30):~ > v.dissolve input=muro_temp
>> column=sector output=muro_sectors3
>> ERROR: Key column must be of type integer or string
>> GRASS 7.0.svn (Spain_utm_wgs84z30):~ >
>>
>>
>> Note above that the column "sector" IS text.
>>
>> So what is wrong?
>
>
> v.dissolve checks for integer and character, but not for text.
>
> Try this simple patch:
>
> --- v.dissolve.py       2011-08-17 13:49:29.0 +0200
> +++ v.dissolve.new.py   2012-04-04 08:04:00.0 +0200
> @@ -66,7 +66,7 @@
>         except KeyError:
>             grass.fatal(_('Column <%s> not found') % column)
>
> -       if coltype['type'] not in ('INTEGER', 'CHARACTER'):
> +       if coltype['type'] not in ('INTEGER', 'CHARACTER', 'TEXT'):
>            grass.fatal(_("Key column must be of type integer or string"))
>
>         f = grass.vector_layer_db(input, layer)
>

I have committed the patch and also added SMALLINT as valid integer in r51246.

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

Re: [GRASS-dev] Vector network analysis in WxGUI proposal for GSoC

[Martin Landa]

Hi,

2012/4/3 stepan.turek :
> another interesting topic for GSoC  could be integration of vector network
> analysis (modules with prefix v.net) into WxGUI.

[...]

both your topics are interesting, please submit the proposals on Melange...

Martin

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