Re: [GRASS-user] Elevation profi le from intersecting shapefiles
Dylan, using v.surf.rst gives me "Segmentation fault", using: v.surf.rst [EMAIL PROTECTED] layer=1 zcolumn=ELEVATION elev=kahu-surf-rast tension=40. segmax=40 npmin=300 dmin=168.547850 dmax=842.739250 zmult=1.0 --overwrite I am on GRASS 6.3, Ubuntu 8.04, AMD64 Any suggestions please? Maris, I cannot find v.profile on my GRASS6.3! Regards Dylan Beaudette-2 wrote: > > Dude- It is saturday night. Your request is for a fairly simple > operation, but there are several steps. > > Some hints: > > 1. convert your contours into a DEM: > v.surf.rst > -- View this message in context: http://www.nabble.com/Elevation-profile-from-intersecting-shapefiles%E2%80%8F-tp20744104p20808111.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Elevation profi le from intersecting shapefiles
Micha, I followed your instructions with the following results: Import data from 2 shapefiles, Contour (layer 1)and Track (layer 2): (no problems reported) v.in.ogr dsn=/home/george/GRASSDATA/ output=testvectmap min_area=0.0001 snap=-1 Display vector map: (no problems, map displayes correctly) d.vect [EMAIL PROTECTED] color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundary,area icon=basic/circle size=5 layer=-1 lsize=8 xref=left yref=center llayer=1 Convert vector to raster and thin: (no problems reported) v.to.rast [EMAIL PROTECTED] output=testrastmap use=attr type=point,line,area layer=1 column=ELEVATION value=1 rows=10 r.thin [EMAIL PROTECTED] output=thinrastmap iterations=200 Display raster map (PROBLEM:only displays large, brightly coloured rectangles, no contours d.rast [EMAIL PROTECTED] -o At this point I stopped as I got the impression something was already wrong but could not work out what. Also, should I not rasterize the track data as well? Any help would be appreciated. If you require the source shapefiles I have no problems sending them to you. Micha Silver wrote: > > > Yes. > I think you should be looking at converting the shapefile contour lines > to a raster > > v.in.org to import the contour lines and tracks into grass > v.to.rast and r.thin to convert the contour lines to a raster map. > r.surf.contour to create an elevation surface from the rasterized > contours > r.profile to get the elevations along the tracks. > > Post back with specific questions if you hit a snag. > > Regards, > Micha > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > -- View this message in context: http://www.nabble.com/Elevation-profile-from-intersecting-shapefiles%E2%80%8F-tp20744104p20803902.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass topography and postgis
I think there is some confusion here: The main Postgis functionality is in line with the OGC SFS model, which is inherently NOT topological. This means that under Postgis as it currently stands, GRASS topological geometries cannot be stored. It does not mean that using Postgis, topological structures cannot be stored, if suitable structures are built to support them, either with the PostGIS umbrella or as a third party toolset.. It is possible to store topological geometries in a relational database, ESRI geodatabases & Oracle are a couple of examples where this can be done. See http://postgis.refractions.net/support/wiki/index.php?PostgisTopology for some work with PostGIS in this direction. If GRASS users are interested in having native PostGIS support for GRASS topological vectors, then it might be worth keeping in touch with this project, ans see if it can be kept in line with the GRASS topological data model to facilitate a future.GRASS data management role. Cheers, Brent Wood Brent Wood DBA/GIS consultant NIWA, Wellington New Zealand >>> "G. Allegri" <[EMAIL PROTECTED]> 12/02/08 11:27 PM >>> Topological datas are "intrinsically " topological: it's not about rules (that you can control with geometrical operators) but the geometrical structures. In topological geodatas, for example, two adjacent polygons share a common, single, boundary, while in Simple Feature model two polygons have their own boundaries. You could have a look at: http://grass.itc.it/grass63/manuals/html63_user/vectorintro.html This means that GRASS needs to use its own data model, because its algorithms code are based on it, and it wouldn't work on Simple Features (Postgis data model, Shapefiles, etc.). Hope this helps, Giovanni tt B <[EMAIL PROTECTED]>: > Hi Markus, > I possibly don't have a full understanding of what topology is. I thought it > was more or less the geometry, with a few rules relating different objects > to each other. Attributes are things like place names or a value at a > location, within a boundary etc. As postgis allows the storage of geometries > then isn't this the topology? I've not had much luck with grass getting it > to recognise things like shared boundaries (so I only have to digitise them > once) apart from using the snap to vertice feature (though as postgis seems > the most useful at the moment I'm concentrating on that). > > Thanks > Matt > > > > On Tue, Dec 2, 2008 at 7:45 PM, Markus Neteler <[EMAIL PROTECTED]> wrote: >> >> Matt, >> >> On Tue, Dec 2, 2008 at 4:31 AM, Matt B <[EMAIL PROTECTED]> wrote: >> > Hi Group, >> > I'd like to set up grass to edit / work with data in a postgis database. >> > So >> > far I've figured out (and been informed, thanks Richard) that grass >> > stores >> > the topologoly data in it's own database and the external database is >> > just >> > used for attributes. >> >> GRASS stores per default all data (geometry + attributes) in its own >> format >> (i.e., attributes in a DBF file in GRASS 6 and in SQLite in GRASS 7). >> >> Optionally attributes can be stored in PostgreSQL (not PostGIS), Mysql, >> SQLite, and ODBC. >> >> > Is there a way to have grass store the topology data in >> > postgis so I can easily work with the data in different applications? >> >> Yes, using v.external. But note that this is a read-only connection. >> We hope that in future this will be read-write. >> >> The issue behind this is that GRASS is a topological GIS while >> PostGIS is Simple Features (no topology per default). So there >> is a "conversion" needed between these two worlds. >> >> Markus > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user NIWA is the trading name of the National Institute of Water & Atmospheric Research Ltd. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] speeding up context evaluation...
Hufkens Koen wrote: > for a validation exercise I need to extract the class values around certain > pixel location. > > I have a map with all the locations (numbered) and a map with the validation > map. > > The code you find below is the one I came up with to get this information > (only output to terminal for the moment). > > However, this code includes a loop and is terribly slow. Has anyone an idea > how to speed things up? If your groundtruth points are sufficiently spaced that their buffers don't overlap[1], you can avoid the loop by creating a single buffer map rather than one for each category. [1] Or you can accept assigning overlapped cells to the nearest point. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] speeding up context evaluation...
Sorry, I was not reading carefully Your code snippet, but can't You just use mapcalc's ability to access neighborhood pixel values (see "THE NEIGHBORHOOD MODIFIER" in help page). Like output=if(location[-1,-1],validation,null()) || etc... It may eliminate need to create buffer, mask etc. still if it takes lot of time, consider to create new C module. Also take a look at v.sample. Maris. 2008/12/2, Hufkens Koen <[EMAIL PROTECTED]>: > > Hi list, > > for a validation exercise I need to extract the class values around certain > pixel location. > > I have a map with all the locations (numbered) and a map with the validation > map. > > The code you find below is the one I came up with to get this information > (only output to terminal for the moment). > > However, this code includes a loop and is terribly slow. Has anyone an idea > how to speed things up? > > Kind regards, > Koen > > -- my code - > > #!/bin/bash > # > ### > # > # Get context around pixels... > # > # !!! Bash script only works within the GRASS terminal !!! > # > ### > > > # > # get number of pixels in location file... write to variable $pixels... > # > > pixels=`r.info -r map=$1 | tail -n +2 | sed 's/max=//'` > > echo "their are $pixels groundtruth points..." > > for i in `seq 1 $pixels`; > do > > echo "evaluating pixel $i of $pixels pixels..." > > # > # Make MASK based upon pixel number evaluate one at a time. Mask name is > MASK and patch.mask > # after renaming... If kept as MASK it will apply to all operations and is a > system wide setting (not wanted)... > # > > r.mask -o input=$1 maskcats=$i --quiet > g.rename rast=MASK,pixel.mask --overwrite --quiet > > # > # create buffer around pixel value... > # > > r.buffer input=pixel.mask output=tmp.buffer distances=4 units=meters > --overwrite --quiet > > # > # writes temporary reclass rules file... > # > > echo "1 = NULL" > tmp.rules > echo "2 = 1" >> tmp.rules > echo "end" >> tmp.rules > > # > # reclass context values using rules above... > # > > r.reclass input=tmp.buffer output=context.mask rules=tmp.rules --overwrite > > # > # calculate category statistics for pixel and context location... > # > > r.mapcalculator amap=pixel.mask bmap=$2 formula=A*B outfile=pixel.category > help=- --overwrite --quiet > echo "pixel data..." > r.stats -c -n input=pixel.category fs=space nv=* nsteps=255 > > r.mapcalculator amap=context.mask bmap=$2 formula=A*B > outfile=context.category help=- --overwrite --quiet > echo "context data..." > r.stats -c -n input=context.category fs=space nv=* nsteps=255 > > done > > # > # clean up tmp files... > # > > rm tmp.rules > g.remove rast=pixel.mask > g.remove rast=context.mask > > echo "!!!DONE!!!" > echo > "#" > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] speeding up context evaluation...
Hi list, for a validation exercise I need to extract the class values around certain pixel location. I have a map with all the locations (numbered) and a map with the validation map. The code you find below is the one I came up with to get this information (only output to terminal for the moment). However, this code includes a loop and is terribly slow. Has anyone an idea how to speed things up? Kind regards, Koen -- my code - #!/bin/bash # ### # # Get context around pixels... # # !!! Bash script only works within the GRASS terminal !!! # ### # # get number of pixels in location file... write to variable $pixels... # pixels=`r.info -r map=$1 | tail -n +2 | sed 's/max=//'` echo "their are $pixels groundtruth points..." for i in `seq 1 $pixels`; do echo "evaluating pixel $i of $pixels pixels..." # # Make MASK based upon pixel number evaluate one at a time. Mask name is MASK and patch.mask # after renaming... If kept as MASK it will apply to all operations and is a system wide setting (not wanted)... # r.mask -o input=$1 maskcats=$i --quiet g.rename rast=MASK,pixel.mask --overwrite --quiet # # create buffer around pixel value... # r.buffer input=pixel.mask output=tmp.buffer distances=4 units=meters --overwrite --quiet # # writes temporary reclass rules file... # echo "1 = NULL" > tmp.rules echo "2 = 1" >> tmp.rules echo "end" >> tmp.rules # # reclass context values using rules above... # r.reclass input=tmp.buffer output=context.mask rules=tmp.rules --overwrite # # calculate category statistics for pixel and context location... # r.mapcalculator amap=pixel.mask bmap=$2 formula=A*B outfile=pixel.category help=- --overwrite --quiet echo "pixel data..." r.stats -c -n input=pixel.category fs=space nv=* nsteps=255 r.mapcalculator amap=context.mask bmap=$2 formula=A*B outfile=context.category help=- --overwrite --quiet echo "context data..." r.stats -c -n input=context.category fs=space nv=* nsteps=255 done # # clean up tmp files... # rm tmp.rules g.remove rast=pixel.mask g.remove rast=context.mask echo "!!!DONE!!!" echo "#" ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass topography and postgis
On Tue, Dec 2, 2008 at 11:12 AM, Matt B <[EMAIL PROTECTED]> wrote: > Hi Markus, > I possibly don't have a full understanding of what topology is. I thought it > was more or less the geometry, with a few rules relating different objects > to each other. Inofficial definition, without reflecting too much about it: - Geometry is the geometry (primitives like points, lines, boundaries, centroids etc). - Topology is the relationship between these primitives. - Attributes are values/descriptions logically attached to the geometry (in GRASS, the cat column is used for that, cat is also stored in the geometry). In topological GIS (eg GRASS) common boundaries are shared while in non-topological GIS (eg ESRI, PostGIS,ok that's no real GIS) they are not, obviously leading to more work to keep data consistent (i.e., avoid slivers and gaps). Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] libgrass_gis.6.3.0.dll
Chris Heys wrote: > I recently downloaded the Windows version of 6.3.0, to run under XP, > and it looks like it will be useful to me. But I keep seeing an error > which says that file > > libgrass_gis.6.3.0.dll > > cannot be found. This happens if I navigate to > > C:\GRASS\bin > > and type, for example, > > g.version > > The dll exists all right. It is in > > C:\GRASS\lib > > so I'm struggling. Is there a crucial environment variable that I > need to reset? There are several environment variables which need to be set in order for GRASS modules to work. This is done by the grass63.bat script. GISBASE needs to be set to the root of the GRASS installation, i.e. C:\GRASS in this case. PATH needs to include $GISBASE\bin and $GISBASE\scripts, and on Windows, $GISBASE\lib (other OSes have a separate variable for libraries). GISRC needs to be set to the path to a file which contains several configuration settings (by default, the file is $HOME\.grassrc6). GIS_LOCK needs to be set in order for g.mapset to work (the actual value doesn't matter). GRASS_SH needs to be set to the path of a Bourne shell in order for scripts to work. Various modules may need other environment variables, e.g. GRASS_PAGER may need to be set to the name of a pager such as "more" or "less". A (mostly) complete list can be found in the docs/html/variables.html file within the GRASS installation. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass topography and postgis
The simple answer is that Postgis and Shapefiles etc store data per record, all the information for a polygon is stored in a geometry which defines it's points and if several points then a line or a polygon. This system allows for overlap and duplication as each object is independent. GRASS, Arc Coverages etc store points, and lines between them. Each line has an object to either side of it. Even if that object is empty space, that just means there's not related attribute table. In this type of storage it's impossible to have overlap or duplicates all points and lines are stored only once. The spatial information is stored separately from the attribute data and every part of it can have a relationship to many different tables. I realize thats not a very clear answer but it's a fundamental difference. You are correct that you want to snap features while digitizing in order to create shared boundaries. In a shapefile the shared boundary would exist twice in GRASS that line would only exist once. So I see a few options: 1. digitize in GRASS and export to Postgis afterward converting to non-topological format with ogr. v.out.ogr should make it easy to write out your data. 2. digitize in QGIS or some other editor that edits directly on Postgis Alex Matt B wrote: > Hi Markus, > I possibly don't have a full understanding of what topology is. I thought it > was more or less the geometry, with a few rules relating different objects > to each other. Attributes are things like place names or a value at a > location, within a boundary etc. As postgis allows the storage of geometries > then isn't this the topology? I've not had much luck with grass getting it > to recognise things like shared boundaries (so I only have to digitise them > once) apart from using the snap to vertice feature (though as postgis seems > the most useful at the moment I'm concentrating on that). > > Thanks > Matt > > > > On Tue, Dec 2, 2008 at 7:45 PM, Markus Neteler <[EMAIL PROTECTED]> wrote: > >> Matt, >> >> On Tue, Dec 2, 2008 at 4:31 AM, Matt B <[EMAIL PROTECTED]> wrote: >>> Hi Group, >>> I'd like to set up grass to edit / work with data in a postgis database. >> So >>> far I've figured out (and been informed, thanks Richard) that grass >> stores >>> the topologoly data in it's own database and the external database is >> just >>> used for attributes. >> GRASS stores per default all data (geometry + attributes) in its own format >> (i.e., attributes in a DBF file in GRASS 6 and in SQLite in GRASS 7). >> >> Optionally attributes can be stored in PostgreSQL (not PostGIS), Mysql, >> SQLite, and ODBC. >> >>> Is there a way to have grass store the topology data in >>> postgis so I can easily work with the data in different applications? >> Yes, using v.external. But note that this is a read-only connection. >> We hope that in future this will be read-write. >> >> The issue behind this is that GRASS is a topological GIS while >> PostGIS is Simple Features (no topology per default). So there >> is a "conversion" needed between these two worlds. >> >> Markus >> > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass topography and postgis
Topological datas are "intrinsically " topological: it's not about rules (that you can control with geometrical operators) but the geometrical structures. In topological geodatas, for example, two adjacent polygons share a common, single, boundary, while in Simple Feature model two polygons have their own boundaries. You could have a look at: http://grass.itc.it/grass63/manuals/html63_user/vectorintro.html This means that GRASS needs to use its own data model, because its algorithms code are based on it, and it wouldn't work on Simple Features (Postgis data model, Shapefiles, etc.). Hope this helps, Giovanni tt B <[EMAIL PROTECTED]>: > Hi Markus, > I possibly don't have a full understanding of what topology is. I thought it > was more or less the geometry, with a few rules relating different objects > to each other. Attributes are things like place names or a value at a > location, within a boundary etc. As postgis allows the storage of geometries > then isn't this the topology? I've not had much luck with grass getting it > to recognise things like shared boundaries (so I only have to digitise them > once) apart from using the snap to vertice feature (though as postgis seems > the most useful at the moment I'm concentrating on that). > > Thanks > Matt > > > > On Tue, Dec 2, 2008 at 7:45 PM, Markus Neteler <[EMAIL PROTECTED]> wrote: >> >> Matt, >> >> On Tue, Dec 2, 2008 at 4:31 AM, Matt B <[EMAIL PROTECTED]> wrote: >> > Hi Group, >> > I'd like to set up grass to edit / work with data in a postgis database. >> > So >> > far I've figured out (and been informed, thanks Richard) that grass >> > stores >> > the topologoly data in it's own database and the external database is >> > just >> > used for attributes. >> >> GRASS stores per default all data (geometry + attributes) in its own >> format >> (i.e., attributes in a DBF file in GRASS 6 and in SQLite in GRASS 7). >> >> Optionally attributes can be stored in PostgreSQL (not PostGIS), Mysql, >> SQLite, and ODBC. >> >> > Is there a way to have grass store the topology data in >> > postgis so I can easily work with the data in different applications? >> >> Yes, using v.external. But note that this is a read-only connection. >> We hope that in future this will be read-write. >> >> The issue behind this is that GRASS is a topological GIS while >> PostGIS is Simple Features (no topology per default). So there >> is a "conversion" needed between these two worlds. >> >> Markus > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass topography and postgis
Hi Markus, I possibly don't have a full understanding of what topology is. I thought it was more or less the geometry, with a few rules relating different objects to each other. Attributes are things like place names or a value at a location, within a boundary etc. As postgis allows the storage of geometries then isn't this the topology? I've not had much luck with grass getting it to recognise things like shared boundaries (so I only have to digitise them once) apart from using the snap to vertice feature (though as postgis seems the most useful at the moment I'm concentrating on that). Thanks Matt On Tue, Dec 2, 2008 at 7:45 PM, Markus Neteler <[EMAIL PROTECTED]> wrote: > Matt, > > On Tue, Dec 2, 2008 at 4:31 AM, Matt B <[EMAIL PROTECTED]> wrote: > > Hi Group, > > I'd like to set up grass to edit / work with data in a postgis database. > So > > far I've figured out (and been informed, thanks Richard) that grass > stores > > the topologoly data in it's own database and the external database is > just > > used for attributes. > > GRASS stores per default all data (geometry + attributes) in its own format > (i.e., attributes in a DBF file in GRASS 6 and in SQLite in GRASS 7). > > Optionally attributes can be stored in PostgreSQL (not PostGIS), Mysql, > SQLite, and ODBC. > > > Is there a way to have grass store the topology data in > > postgis so I can easily work with the data in different applications? > > Yes, using v.external. But note that this is a read-only connection. > We hope that in future this will be read-write. > > The issue behind this is that GRASS is a topological GIS while > PostGIS is Simple Features (no topology per default). So there > is a "conversion" needed between these two worlds. > > Markus > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] raster and vector shift
Hi, I'm working on some rasters derived from spot images. When I utilise the command r.to.vect it's work, but I've some trouble about the display of the rasters. Sometimes the raster and vector match correctly: http://i35.tinypic.com/2ed3vy8.png Sometimes there are some problems: http://i34.tinypic.com/24eq4pu.png There is a shift. Any suggestion? Alfredo -- View this message in context: http://n2.nabble.com/raster-and-vector-shift-tp1603088p1603088.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] libgrass_gis.6.3.0.dll
Hi Christopher, I recently downloaded the Windows version of 6.3.0, to run under XP, and it looks like it will be useful to me. But I keep seeing an error which says that file libgrass_gis.6.3.0.dll cannot be found. This happens if I navigate to C:\GRASS\bin and type, for example, g.version to use GRASS you cannot just type the commands (executable files) from the directory where they are located. You need to start GRASS first (from DOS or MSYS command line. or using the TclTk or Python GUI). The dll exists all right. It is in C:\GRASS\lib so I'm struggling. Is there a crucial environment variable that I need to reset? Yes. All the needed variables are already set in the grass63.bat file that is called when you launch GRASS from the GRASS group menu or from the desktop icon. Read the release notes on about launching WinGRASS: http://grass.osgeo.org/grass63/binary/mswindows/native/README.html#Launching%20GRASS Regards, Marco ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] libgrass_gis.6.3.0.dll
Dear Grass Experts I recently downloaded the Windows version of 6.3.0, to run under XP, and it looks like it will be useful to me. But I keep seeing an error which says that file libgrass_gis.6.3.0.dll cannot be found. This happens if I navigate to C:\GRASS\bin and type, for example, g.version The dll exists all right. It is in C:\GRASS\lib so I'm struggling. Is there a crucial environment variable that I need to reset? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass topography and postgis
Matt, On Tue, Dec 2, 2008 at 4:31 AM, Matt B <[EMAIL PROTECTED]> wrote: > Hi Group, > I'd like to set up grass to edit / work with data in a postgis database. So > far I've figured out (and been informed, thanks Richard) that grass stores > the topologoly data in it's own database and the external database is just > used for attributes. GRASS stores per default all data (geometry + attributes) in its own format (i.e., attributes in a DBF file in GRASS 6 and in SQLite in GRASS 7). Optionally attributes can be stored in PostgreSQL (not PostGIS), Mysql, SQLite, and ODBC. > Is there a way to have grass store the topology data in > postgis so I can easily work with the data in different applications? Yes, using v.external. But note that this is a read-only connection. We hope that in future this will be read-write. The issue behind this is that GRASS is a topological GIS while PostGIS is Simple Features (no topology per default). So there is a "conversion" needed between these two worlds. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] script in python
Glynn thanks.
Now go better.
I added
#%option
#% key: buff
#% type: string
#% description: misura buffer (in metri)
#% required : yes
#%end
buff1 = options['buff']
grass.run_command('v.buffer', input = vect1, output = "buffer", buffer =
buff1)
> Apart from anything else, it's hard to write shell scripts which work
> reliably on Windows. More generally, it's hard to write anything other
> than simple scripts using bash (or any Bourne shell).
>
> The intention is that it will be possible to run all of GRASS on
> Windows without requiring a shell or Unix utilities.
>
I want to learn . to get the best GRASS :-)
Now continuing with the script, but the script does not finish ever (I also
tried with grass.exec_command and I inserted at the end sys.exit (0) as
I saw in your scripts).
I'm happy for the evolution of GRASS 7. I sometimes are forced to use GRASS
on windows and use all the scripts in pyhton would be great.
Grazie
Ciao
Gabriele
Glynn Clements wrote:
>
>
> Gabriele Nolè wrote:
>
>> I use ubuntu 8.10 and grass64 svn
>> I made the changes based on your claims.
>> This is my code:
>> -
>> def main():
>> # con = assegno le variabili
>> vect1 = options['vect_1']
>> vect2 = options['vect_2']
>> vect3 = options['vect_3']
>>
>> grass.run_command('v.buffer', input = vect_1, output = buffer_200m,
>> buffer = 200)
>>
>> if __name__ == "__main__":
>> options, flags = grass.parser()
>> main()
>> -
>> But if __name__ == "__main__": etc .. what is your job?
>
> __name__ contains the name of the current module. For a Python script
> which is being executed (rather than "import"ed), the name is "__main__".
>
> The check allows scripts to contain code which is only executed if the
> script is being executed directly.
>
>> Unfortunately, I made several attempts, but I have an error:
>
>> grass.run_command('v.buffer', input = vect_1, output = buffer_200m,
>> buffer = 200)
>
>> NameError: global name 'vect_1' is not defined
>
> The above code assigns the variable "vect1":
>
>> vect1 = options['vect_1']
>
> but references "vect_1":
>
>> grass.run_command('v.buffer', input = vect_1, output = buffer_200m,
>> buffer = 200)
>
> The two must match.
>
>> I do not know how "to treat" the output of the v.buffer (in this case,
>> buffer_200m).
>
> As buffer_200m is a literal string, not a variable, it needs to be
> quoted, e.g.:
>
> grass.run_command('v.buffer', input = vect1, output = "buffer_200m",
> buffer = 200)
>
>> With grass 7 will work scripts in bash?
>
> You can script GRASS commands in any language, but we intend to
> convert all of the shell scripts which are included in GRASS to Python
> for GRASS 7.
>
> Apart from anything else, it's hard to write shell scripts which work
> reliably on Windows. More generally, it's hard to write anything other
> than simple scripts using bash (or any Bourne shell).
>
> The intention is that it will be possible to run all of GRASS on
> Windows without requiring a shell or Unix utilities.
>
> --
> Glynn Clements <[EMAIL PROTECTED]>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
--
View this message in context:
http://www.nabble.com/script-in-python-tp20758838p20788071.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
