RE: [GRASS-user] install grass with new wxPython user interface in Ubuntu
[cc list] Jhon Ortiz wrote: > >> But with this errors: > >> ** > >> Errors in: > >> /usr/local/src/grass-6.3.0/visualization/nviz > >> ** > When I type > cd /usr/local/src/grass-6.3.0/visualization/nviz > make > > Give me a lot erros, but this errors is because nviz is > working with tcltk, and I compiled without tcltk. > I resolved that compiled with tcltk ok, it is already fixed in SVN that nviz will only build if Tcl/Tk is used: http://trac.osgeo.org/grass/changeset/31328 but 6.3.0 shipped before that change. > [...] and python > > ./configure -with-cxx -with-gdal=/usr/bin/gdal-config > -with-postgres > -with-postgres-includes=/usr/include/postgresql > -with-postgres-libs=/usr/lib/postgresql/8.2/lib > -with-tcltk-includes=/usr/include/tcl8.4 -without-mysql > -without-odbc -with-readline -with-fftw > -with-fftw-libs=/usr/local/lib -with-freetype > --with-freetype-includes=/usr/include/freetype2 > -enable-largefile -with-python > -with-proj-share=/usr/share/proj "-with-python" is not enough to get the new wxPython GUI installed. That is only required for the new vdigit. You will need to install wxPython 2.8 and friends. see grass-6.3.0/gui/wxpython/README > But now when I type in the terminal for start grass > (grass63 -wxpython), give me this error: > > *** > >>[EMAIL PROTECTED]:~$ grass63 -wxpython > Cleaning up temporary files. > Starting GRASS ... > Traceback (most recent call last): > File > "/usr/local/grass-6.3.0/etc/wxpython/gis_set.py", > line 31, in > from gui_modules import globalvar > File > "/usr/local/grass-6.3.0/etc/wxpython/gui_modules/globalvar.py", > line 48, in > CheckForWx() > File > "/usr/local/grass-6.3.0/etc/wxpython/gui_modules/globalvar.py", > line 39, in CheckForWx > except (ImportError, ValueError, > wxversion.VersionError), e: > UnboundLocalError: local variable 'wxversion' referenced before > assignment > Error in GUI startup. If necessary, please > report this error to the GRASS developers. > Switching to text mode now. > Hit RETURN to continue... > *** but the Tcl/Tk GUI works, right? and -text mode? $ grass63 -tcltk I think just the wxPython 2.8 packages are missing. > Thanks Hamish and all list > > And sorry for repet the post, but is for answer the > question to Hamish. answers are good to have in the archives for others who search for the same error. > someone has an idea of how I can install grass with new > wxPython user interface in Ubuntu 7.10? If you wish to use the new wxGUI I would suggest to download the latest 6.4svn source code snapshot. The GUI has seen a lot of improvements. http://grass.osgeo.org/grass64/source/snapshot/ And see grass64.svn/debian/README.debian there for instructions on how to download Debian packaging rules from DebianGIS and build a .deb for your version of Ubuntu. (it is almost as simple as "dpkg-buildpackage" to create them using the automated scripts) or if you prefer just compile it yourself as you have been doing. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.fillnulls (GRASS BOOK 3rd edition)
Qui, 2008-09-18 às 18:33 -0700, Hamish escreveu: > Luís Ferreira wrote: > > Using g.gisenv and g.gisenv --help: > > > >GRASS 6.4.svn (nc_spm_08):~ > g.gisenv > >GISDBASE=/home/lf/GRASSDATA > >LOCATION_NAME=nc_spm_08 > >MAPSET=user1 > >"GRASS_HTML_BROWSER=/usr/lib/iceweasel/iceweasel" > >GRASS_DB_ENCODING=iso8859-1 > >GRASS_GUI=wxpython > > > edit ~/.grassrc6 and remove the GRASS_HTML_BROWSER line. > > Besides not needing the "quotes" it doesn't belong in that file as it is > an environment variable not a GIS system variable. > > running this before starting GRASS should get that set correctly: > export GRASS_HTML_BROWSER=iceweasel > > (assuming you use bash) > > Hamish Editing ~/.grassrc6 solved all the r.fillnulls error warnings in bash, gis.m and g.gui. Thank you very much Luís Ferreira ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.fillnulls (GRASS BOOK 3rd edition)
Luís Ferreira wrote: > Using g.gisenv and g.gisenv --help: > >GRASS 6.4.svn (nc_spm_08):~ > g.gisenv >GISDBASE=/home/lf/GRASSDATA >LOCATION_NAME=nc_spm_08 >MAPSET=user1 >"GRASS_HTML_BROWSER=/usr/lib/iceweasel/iceweasel" >GRASS_DB_ENCODING=iso8859-1 >GRASS_GUI=wxpython edit ~/.grassrc6 and remove the GRASS_HTML_BROWSER line. Besides not needing the "quotes" it doesn't belong in that file as it is an environment variable not a GIS system variable. running this before starting GRASS should get that set correctly: export GRASS_HTML_BROWSER=iceweasel (assuming you use bash) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.fillnulls (GRASS BOOK 3rd edition)
Qui, 2008-09-18 às 15:40 -0700, Hamish escreveu:
> > GRASS 6.4.svn (nc_spm_08):~ > r.fillnulls \
> > elev_srtm_30m_null out=elev_srtm_30mfilled
> >
> > it gives me the errors
> >
> > /usr/lib/grass-6.4.svn/scripts/r.fillnulls: eval: line 82:
> > unexpected EOF while looking for matching `''
>
>
> goes "g.gisenv --help" or just "g.gisenv" work from the command prompt?
>
> it sounds like GRASS is not fully installed correctly.
> Hamish
I had compiled GRASS 6.4 from
https://svn.osgeo.org/grass/grass/branches/develbranch_6 grass6_devel.
Kernel : Linux 2.6.26-1-vserver-amd64 (x86_64)
Compiled: #1 SMP Thu Aug 28 13:09:10 UTC 2008
C Library : GNU C Library version 2.7 (stable)
Distribution: Debian GNU/Linux lenny/sid
Code lines in /usr/lib/grass-6.4.svn/scripts/r.fillnulls
82 eval `g.gisenv`
83 : ${GISBASE?} ${GISDBASE?} ${LOCATION_NAME?} ${MAPSET?}
84 LOCATION=$GISDBASE/$LOCATION_NAME/$MAPSET
Using g.gisenv and g.gisenv --help:
GRASS 6.4.svn (nc_spm_08):~ > g.gisenv
GISDBASE=/home/lf/GRASSDATA
LOCATION_NAME=nc_spm_08
MAPSET=user1
"GRASS_HTML_BROWSER=/usr/lib/iceweasel/iceweasel"
GRASS_DB_ENCODING=iso8859-1
GRASS_GUI=wxpython
GRASS 6.4.svn (nc_spm_08):~ > g.gisenv --help
Descrição:
Sai e modifica as atuais variáveis de usuário do GRASS.
Palavras chave:
general
Uso:
g.gisenv [get=VARIABLE] [set=VARIABLE=value] [store=string]
[--verbose] [--quiet]
Flags:
--v Saída do módulo verbosa
--q Saída do módulo silenciosa
Parâmetros:
get Variável do GRASS para capturar
set Variável do GRASS para ajustar
store Onde as variáveis do GRASS são guardadas
opções: gisrc,mapset
padrão: gisrc
Using gis.m gives:
/usr/lib/grass-6.4.svn/scripts/r.fillnulls: eval: line
82: unexpected EOF while looking for matching `''
/usr/lib/grass-6.4.svn/scripts/r.fillnulls: eval: line
83: syntax error: unexpected end of file
Locating and isolating NULL areas...
Reading input raster map <[EMAIL PROTECTED]>...
Finding buffer zones...
Writing output raster map ...
Creating interpolation points...
Extracting points...
Building topology for vector map
...
egistering primitives:
Building areas:
Número de nós : 2187
Número de primitivas: 2187
Número de pontos: 2187
Número de linhas : 0
Número de fronteiras: 0
Número de centróides : 0
Número de áreas : 0
Número de ilhas : 0
Topology was built
0 areas built
0 isles built
Anexando ilhas:
Anexando centróides:
r.to.vect completo.
2187 primitives registered
2187 vertices registered
Interpolating 2187 points
Note: The following warnings may be ignored.
Removing raster
Using segmentation for interpolation...
Porcentagem completada:
Carregando dados da tabela de atributos ...
Lendo linhas do mapa vetorial ...
Lendo nós do mapa vetorial
Processing all selected output files
Porcentagem completada:
will require 1818544 bytes of disk space for temp files
The number of points from vector map is 2187
The number of points outside of 2D/3D region 0
The number of points being used is 2187
há uma faixa com dados insuficientes
demorando demais para encontrar pontos para
interpolação--fav
Re: [GRASS-user] Trouble with ESRI TIGER/LINE Files and Coordinate System
Hamish: > In my experience reprojection on-the-fly is nice in theory, > a disaster in practice. I wonder if instead of reprojecting the data we just reprojected the mouse cursor coordinate displayed in the GUI display status bar? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Trouble with ESRI TIGER/LINE Files and Coordinate System
Ryan R. Rosari wrote: > Which gets me to thinking... It would be great if GRASS had a similar > feature, where the user can select how the coordinates are displayed at > the bottom of the map output window (meters, feet, degrees) as > a quick reference. see: "g.proj -p" from the command line "PROJ_UNITS" file in the location's PERMANENT mapset G_database_unit_name(), G_database_units_to_meters_factor() in libgis In my experience reprojection on-the-fly is nice in theory, a disaster in practice. I would suggest to help QGIS (and Arc for that matter) get that working correctly before thinking about doing so in GRASS. (neither handle mixed datums well; real raster reproj is too expensive) see also viewproj from GRASS 5, http://freegis.org/cgi-bin/viewcvs.cgi/grass/src.contrib/LM/viewproj/README?rev=1.1&content-type=text/vnd.viewcvs-markup Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] updating site-vector map in grass62
Francois Delclaux wrote: > I imported a site list from grass54 to grass62, so I obtained a vector > map with a corresponding dbf table. > Now I would like to simply update this map by adding new > points for which I have the coordinates and names. > In grass5, it was quite simple, I just had to edit the > ascii site file and add new records. > But, in grass6, what is the best - and most simple- method > for doing that ? v.in.ascii + v.patch Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.fillnulls (GRASS BOOK 3rd edition)
Luís Ferreira wrote: > GRASS 6.4.svn (nc_spm_08):~ > r.fillnulls \ > elev_srtm_30m_null out=elev_srtm_30mfilled > > it gives me the errors > > /usr/lib/grass-6.4.svn/scripts/r.fillnulls: eval: line 82: > unexpected EOF while looking for matching `'' goes "g.gisenv --help" or just "g.gisenv" work from the command prompt? it sounds like GRASS is not fully installed correctly. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error: too many nested evaluations
I can't see any "*_modify" nor "update" inside progressbar.tcl
2008/9/18 Glynn Clements <[EMAIL PROTECTED]>:
>
> G. Allegri wrote:
>
>> While importing a polygon with v.in.ogr I've received the following
>> message on the console:
>>
>> too many nested evaluations (infinite loop?)
>> (procedure "Gronsole::add_data_tag" line 1)
>> invoked from within
>> "Gronsole::add_data_tag $path $ci out"
>> (procedure "Gronsole::readout" line 13)
>> invoked from within
>> "Gronsole::readout $path $ci $mark $fh"
>> invoked from within
>> "if [eof $fh] {
>> Gronsole::readeof $path $ci $mark $fh
>> Gronsole::done_command $path $ci
>> } else {
>> Gronsole::readout $path $ci $mark $fh
>> }"
>> (procedure "Gronsole::file_callback" line 2)
>> invoked from within
>> "Gronsole::file_callback .gronsole.gronsole 41 cmdinsert41 file9"
>>
>> and the process stalls...
>> This is the output until the crash:
>> http://www.geospatial.it/allegri/v.in.ogr_console.txt
>
> Try removing the "update" call from the end of ProgressBar::_modify,
> at the bottom of $GISBASE/bwidget/progressbar.tcl.
>
> --
> Glynn Clements <[EMAIL PROTECTED]>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Display window export
Has anybody had this problem : I try to export a raster image of the Display window (tcltk interface), with the button on the top bar : 'Export display to graphics file > JPG* > very high resolution (300% your current resolution)' The file generated through this command is actually 3 x the display resolution, but features (e.g. vector lines, raster maps, etc.) are drawn at the screen low resolution, i.e. 3 times coarser than the .jpg image resolution ! in other words 9 contiguous pixels have the same value. What does this suggest you ? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.fillnulls (GRASS BOOK 3rd edition)
Hi On page 123 of the book "Open Source Gis - A GRASS GIS Aproach", when performing GRASS 6.4.svn (nc_spm_08):~ > r.fillnulls elev_srtm_30m_null out=elev_srtm_30mfilled it gives me the errors /usr/lib/grass-6.4.svn/scripts/r.fillnulls: eval: line 82: unexpected EOF while looking for matching `'' /usr/lib/grass-6.4.svn/scripts/r.fillnulls: eval: line 83: syntax error: unexpected end of file /usr/lib/grass-6.4.svn/scripts/r.fillnulls: line 83: GISDBASE: parameter null or not set I'm starting using GRASS. Any suggestion to solve this? Thank you ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Trouble with ESRI TIGER/LINE Files and Coordinate System
*Blushes* Solved. It ended up being a dumb error on my part. Months ago, I converted the shape files to EPSG 3310 (California Teale Albers) to match another line file I was using but no longer need. That is why gvSIG was able to convert the coordinates to lat/lon, because the view (location) was projected as 3310. Using the original, untouched shape files, I have pure lat/lon. Which gets me to thinking... It would be great if GRASS had a similar feature, where the user can select how the coordinates are displayed at the bottom of the map output window (meters, feet, degrees) as a quick reference. R. Ryan R. Rosario wrote: > > Ugh. The LINESTRINGs contain the weird coordinates (in the 10s), not > raw lat/lon. > > Extent: (-59948.354015, -457156.354302) - (51189.384222, -322776.485268) > > QGIS also uses the weird coordinates as well. gvSIG did as well, until I > changed the measurement unit to "degree." It's GUI for map display is very > similar to QGIS. Is there a such thing switching measurement units to > degrees in GRASS? ;-) > > Unfortunately, there is no PRJ file with these shapefiles, which is really > frustrating. The website claims they are NAD83 lat/lon decimal degrees. My > region should be 119W to 121W and 34N to 36N. Could these be UTM > coordinates?? > > R. > > > > hamish_b wrote: >> >> can you check with ogrinfo what's *really* in the shapefile? >> >>ogrinfo -ro -al mapname.shp >> >> That will dump a huge amount of stuff to the terminal (^C to kill it) >> but you should see LINESTRING with a comma separated list of coordinates. >> >> Are those raw coordinates in lat/lon or ...? >> >> what does the shapefile.prj look like? >> >> >> I am not too familiar with gvSIG's capabilities; will QGIS load it and >> show correct projection info and mouse-over coords on the bottom status >> line? >> >> >> Hamish >> > > -- View this message in context: http://www.nabble.com/Trouble-with-ESRI-TIGER-LINE-Files-and-Coordinate-System-tp19506319p19556958.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] v.build.polylines
It does (for me), I just used it. Please be more specific. Markus Hi! I have the same problem: need to merge every adjacent lines with a specific equal attribute, and need to add some others atributes when the lines are merged. I tried to solve using the v.edit module and have concluded that the simple use of this module cannot solve the problem. If I'm wrong, how should be the WHERE clausle? I believe that the only way out is to build a script involving several steps... Alexandre -- View this message in context: http://www.nabble.com/v.build.polylines-tp11807899p19554205.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
[GRASS-user] updating site-vector map in grass62
Grass-users, I am not used in manipulating vector maps in grass6. So my question is the following: I imported a site list from grass54 to grass62, so I obtained a vector map with a corresponding dbf table. Now I would like to simply update this map by adding new points for which I have the coordinates and names. In grass5, it was quite simple, I just had to edit the ascii site file and add new records. But, in grass6, what is the best - and most simple- method for doing that ? Thanks in advance for your reply Sincerely -- Francois DELCLAUX UMR HydroSciences Montpellier Universite Montpellier II - Place Eugene Bataillon Case courrier MSE 34095 Montpellier Cedex 5 FRANCE http://www.hydrosciences.fr/ mailto: [EMAIL PROTECTED] Tel : (33) (0)4 67 14 90 11 Fax : (33) (0)4 67 14 47 74 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error: too many nested evaluations
G. Allegri wrote:
> While importing a polygon with v.in.ogr I've received the following
> message on the console:
>
> too many nested evaluations (infinite loop?)
> (procedure "Gronsole::add_data_tag" line 1)
> invoked from within
> "Gronsole::add_data_tag $path $ci out"
> (procedure "Gronsole::readout" line 13)
> invoked from within
> "Gronsole::readout $path $ci $mark $fh"
> invoked from within
> "if [eof $fh] {
> Gronsole::readeof $path $ci $mark $fh
> Gronsole::done_command $path $ci
> } else {
> Gronsole::readout $path $ci $mark $fh
> }"
> (procedure "Gronsole::file_callback" line 2)
> invoked from within
> "Gronsole::file_callback .gronsole.gronsole 41 cmdinsert41 file9"
>
> and the process stalls...
> This is the output until the crash:
> http://www.geospatial.it/allegri/v.in.ogr_console.txt
Try removing the "update" call from the end of ProgressBar::_modify,
at the bottom of $GISBASE/bwidget/progressbar.tcl.
--
Glynn Clements <[EMAIL PROTECTED]>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to import grass ASCII grid with comma as a separator
Since the comma is used to format decimal numbers in several countries, I still think a flag to interpret it that way should be added to all modules affected by this. I can think of: v.in.ascii, r.in.xyz, r.in.ascii Any others? Ben Adam Dershowitz wrote: Translate (tr) is very fast. If you do: tr ',' '.' < input_file.txt > out_file.txt it should do the job pretty quickly. --Adam On Sep 16, 2008, at 9:08 AM, Jarekj wrote: Hi I recived a number of grass ascii grid floating point maps with resolution 6000 x8000 (over 300 MB) px with comma (,) instead of point (.) as a decimal separator. I have problem with import that data due to bad interpretation of comma in file. I tiried with find/replace command in gedit but due to file size it takes to much time. Is some method to import such file without replacing commas with points in external text editor Jarek ___ 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 -- Benjamin Ducke Senior Applications Support and Development Officer Oxford Archaeology Ltd Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 [EMAIL PROTECTED] -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.generalize / reanimation of dead lines ?
Further on this subject, I tried v.generalize on the North Carolina sample dataset and ran into the same "attempt to read dead line" error with the "boundary_county" areal layer. Very small threshold settings ( < 1.0 ) worked OK, but obviously, there is only a minimal simplification to be gained from this. Any threshold setting around 10.0 resulted in the above error not more than 10% through the data. I tried all different algorithms and did not have better success with any of them. Best, Ben Markus Metz wrote: Hi Peter, as an interim solution you might try an alternative to v.generalize that I called v.simplify, available here: http://markus.metz.giswork.googlepages.com/line_simplification.tar.gz The module works for me so far, but I still discover strange behaviour now and then. I developed that module specifically for areas, before v.generalize was available. Differences to v.generalize are that this module only simplifies/generalizes lines/boundaries, smoothing is not available, and only the Douglas-Peucker algorithm is implemented. The appropriate level of topology is always maintained, centroids are always kept and never altered. Boundaries are not simplified if this would result in area deletion or changed centroid attachment. All the work is done with a temporary vector, and after simplifying the temporary vector, only alive lines are copied to the final output vector (no dead lines, smaller file size). v.simplify can also delete duplicate points only, i.e. of two adjacent vertices in a line/boundary with identical coordinates one is removed. This should be done before simplification in v.simplify. As far as I understand the source code v.generalize discards all centroids and builds them anew at the end, area topology is not maintained during simplification. This is not meant to be competition for v.generalize, just some ideas on how to avoid dead lines in the output vector and how to preserve all areas/centroids, with their original category ID. Markus Peter Löwe wrote: Hi, I second the "unclean deletion" theory as I encountered this phenomenon before. Also, when generalizing areas which are attached to each other, while the overall "appearance" of the generalized borderlines is ok, more than 50 % of the areas cease to exist, which needs further investigation: Apart from "dead lines" we're dealing with "area mutilation" and "centroid abduction"! The (topological) truth is somewhere out there, Peter Original-Nachricht Datum: Fri, 29 Aug 2008 19:17:46 +0300 Von: Wolf Bergenheim <[EMAIL PROTECTED]> An: [EMAIL PROTECTED] CC: grass-user@lists.osgeo.org, [EMAIL PROTECTED], [EMAIL PROTECTED], Daniel Bundala <[EMAIL PROTECTED]> Betreff: Re: [GRASS-user] v.generalize / reanimation of dead lines ? On 29.08.2008 18:54, Dylan Beaudette wrote: I have noticed this behavior as well when using v.generalize. I will try and dig up the exact situation that caused it-- but I am pretty sure that the initial linework was correct = unclean deletion. That is very much possible. This module is still quite young and hasn't gone through a lot of live testing yet. Dylan, I'd be vey interested in this, if you can give me a simple case where it goes wrong. --Wolf Adding Daniel Bundala to the Cc list, as he wrote it last summer. -- <:3 ) Wolf Bergenheim ( 8:> ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Benjamin Ducke Senior Applications Support and Development Officer Oxford Archaeology Ltd Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 [EMAIL PROTECTED] -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Not this pest again!
Richard, The NASA SRTM seems as if it would suit my purposes, except that using r.in.srtm I get a lovely image with no elevation data. So r.what comes up with latitude, longitude, and null, eg: 150 | -34 | | * also consider the option to import ASCII SRTM data usign r.in.gdal in GRASS. the projection is lat/long (WGS84, epsg id = 4326), while the elevation data are in meters. Regards, Marco ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
