Illidan wrote:
> By now I'm successful with importing the ESRI ASC by r.in.arc
>
> > r.in.arc input=srtm_60_04.asc output=beijing
> CREATING SUPPORT FILES FOR beijing
>
> However, when I try
>
> r.out.gdal input=beijing output=beijing.dem format=USGSDEM
>
> it replies with "Error: value out
Hello Hamish,
You're right. The file format is exactly as you say. In fact I was
just about to paste the beginning of that file.
By now I'm successful with importing the ESRI ASC by r.in.arc
> r.in.arc input=srtm_60_04.asc output=beijing
CREATING SUPPORT FILES FOR beijing
However, when I try
Illidan wrote:
> e00 is plain text file containing raster data, developed by ESRI. It
> contains headers of about six lines, followed by raster data for each
> cell. Its format is somewhat similar to USGS DEM.
does it look like:
ncols:
nrows:
xllcorner:
yllcorner:
cellsize:
nodata_value:
[
Illidan wrote:
> However, I'm only fortunate enough to get DEM data in ESRI ASCII
> format. That's why I have to do a conversion.
>
> http://en.wikipedia.org/wiki/ESRI_grid
>
> I guess ESRI ASCII format is well-known to GIS guys. Maybe I made a
> mistake mixing e00 up with ESRI ASCII. A friend o
That would be simply great!
With SpatiaLite support evolving in GRASS, QGIS and (perhaps)
gvSIG, there would finally be a sane way for direct exchange
of vector data between open source GIS without crippling it
by going through abominations like Shapefiles.
Ben
- Original Message -
From
On Sat, Feb 21, 2009 at 1:42 PM, Moritz Lennert
wrote:
...
> The SQLite support in GRASS concerns the attribute management, not
> geometries. To access geometries in a SpatiaLite, you have to go through
> v.external.
Last Friday I met the SpatiaLite developer at the Italian GRASS/GFOSS
meeting (h
On Sat, Feb 28, 2009 at 1:03 PM, Thybério Luna Freire
wrote:
> Hi,
> i'm Linux user, but now i installed GRASS in my windows XP.
> I never have problems with connections to postgis when i'm using GRASS in my
> Ubuntu, but i simply can't connect to postgre/postgis on Windows.
> I have the follow me
Given the limitations that exist with using GRASS and Postgres I do not know
how.
There is someone who manages a GIS (with others), based mainly on GRASS?
1) If yes, how do? how organized these data? how to manage them?
2) If I put everything on postgres, To do spatial analysis with GRASS I am
On Fri, Feb 27, 2009 at 11:47 AM, achim wrote:
...
> qgis: symbol lookup error: /usr/lib64/libqgisgrass.so.1.0: undefined
> symbol: G__no_gisinit
Here the full explanations from Glynn to an older mail
with a similar question:
On Thu, Aug 14, 2008 at 5:37 AM, Glynn Clements
wrote:
> G. Allegri w
You're on the right track. If you have obtained a an ESRI GRID representing
a DEM in an e00 format, then with GDAL and/or GRASS you can convert from
ESRI GRID (e00) to USGS DEM format, with the workflow Hamish outlined
previously.
ESRI data is in binary raster/vector formats when ESRI software is
roblem?
Thanks
Miguel
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.osgeo.org/pipermail/grass-user/attachments/20090301/e4581944/attachment.html
Edit .grassrc6 in the user's HOME directory.
An even better solution is to upgrade to GRASS 6.4
I just started using the python interface with GRASS (6.3), where I have
typically used the older interface.
I ran r.contour. I wanted to re-run it, but change the input/output names.
I noticed two things, and was wondering if they are intentional. This
behavior was not present in the previous G
I'm overall new to GIS. But my work has to rely on USGS DEM formatted
data, so I cannot run away.
However, I'm only fortunate enough to get DEM data in ESRI ASCII
format. That's why I have to do a conversion.
http://en.wikipedia.org/wiki/ESRI_grid
I guess ESRI ASCII format is well-known to GIS g
Hello list,
I´ve been working for a while in Grass in a windows xp machine. I have just
installed the software (wingrass 6.3) in another XP machine and when trying
to launch the program I get the message: "ERROR: LOCATION_NAME not set".
Anyone can give me a hint as to how can I work around this p
Nikos:
> > It should be the case with i.pca as well since eigen_VALUES_ (=represent
> > the variances of the original dimensions that are "kept" in each
> > component) are important for the interpretation of what exactly are each
> > of the components. But, i.pca just does not report the eigen_VAL
Nikos:
> >* Present first the variance (=eigenvalues) because it's the
> >first thing you will look at to know "how much variance of the
> >original data is _expressed_ in each new component.
> >* The importance, since it refers to the eigenvalue, it's better
> >to come right after it.
Ha
Nikos:
>* Present first the variance (=eigenvalues) because it's the first
> thing you will look at to know "how much variance of
> the original data is _expressed_ in each new component.
>
>* The importance, since it refers to the eigenvalue,
> it's better to come right after it.
to me
On Sun, 2009-03-01 at 12:46 +0100, Nikos Alexandris wrote:
> Nikos:
> > [...] i.pca just does not report the eigen_VALUES_. At some point some
> > C-expert needs to have a look in the code (i.pca) and correct the
> > "bug" which does not let the eigen_VALUES_ from being printed.
>
>
> Hamish:
> >
Hi,
2009/3/1 Nikos Alexandris :
> gcc -I/usr/local/src/grass6_devel/dist.x86_64-unknown-linux-gnu/include -g
> -Wall -DPACKAGE=\""grassmods"\"
> -I/usr/local/src/grass6_devel/dist.x86_64-unknown-linux-gnu/include -o
> OBJ.x86_64-unknown-linux-gnu/support.o -c support.c
> support.c: In f
Nikos:
> [...] i.pca just does not report the eigen_VALUES_. At some point some
> C-expert needs to have a look in the code (i.pca) and correct the
> "bug" which does not let the eigen_VALUES_ from being printed.
Hamish:
> done in devbr6 (6.5svn) please test, I'm not a multivariate stats guru
>
On Sun, 2009-03-01 at 01:59 -0800, Hamish wrote:
> Hamish wrote:
> > # 'automatic method'
> > imagery60:G6.5svn> i.pca in=spot.ms.1,spot.ms.2,spot.ms.3 out=spot_pca
> >
> > Eigen (vectors) and values:
> > PC1 ( -0.63 -0.65 -0.43 ) 88.07
> > PC2 ( 0.23 0.37 -0.90 ) 11.48
> > PC3 ( 0.75 -0.66 -0.08
Hi Achim
Achim wrote:
>> starting qgis(1.0.1) with grass64 I can open a grass location, but when
>> I open a rastermap, qgis terminates with following error:
>>
>> qgis: symbol lookup error: /usr/lib/gdalplugins/gdal_GRASS.so: undefined
>> symbol: G_no_gisinit
>>
>> When I start qgis with grass63
On Sun, Mar 1, 2009 at 4:05 PM, Hamish wrote:
>
> Illidan wrote:
>> I'm trying a conversion of from ERSI Grid ASCII(e00) to legacy USGS
>> DEM that one old piece of software I'm using supports. I searched the
>> web and only got results about the reverse conversion, i.e. USGS
>> DEM==> e00. So I a
Matthew Mulbrandon wrote:
> I just want to output all my data in file tenn_county_all
> into a comma delimited file with all variables.
>
> I have done
>
> v.out.ascii format=standard
>
> it works but I only get x,y coord and the ID but I need all
> variables.
>
> -84.28851567|35.99395611|1
Hamish wrote:
> # 'automatic method'
> imagery60:G6.5svn> i.pca in=spot.ms.1,spot.ms.2,spot.ms.3 out=spot_pca
>
> Eigen (vectors) and values:
> PC1 ( -0.63 -0.65 -0.43 ) 88.07
> PC2 ( 0.23 0.37 -0.90 ) 11.48
> PC3 ( 0.75 -0.66 -0.08 ) 0.45
changed to:
Eigen values, (vectors), and [percent import
Nikos wrote:
> It should be the case with i.pca as well since eigen_VALUES_ (=represent
> the variances of the original dimensions that are "kept" in each
> component) are important for the interpretation of what exactly are each
> of the components. But, i.pca just does not report the eigen_VALUE
Illidan wrote:
> I'm trying a conversion of from ERSI Grid ASCII(e00) to legacy USGS
> DEM that one old piece of software I'm using supports. I searched the
> web and only got results about the reverse conversion, i.e. USGS
> DEM==> e00. So I ask for help here. I appreciate any feasible work
> flo
27 matches
Mail list logo