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
flow or
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_VALUES_.
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 importance]:
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 ) 0.45
Hi,
2009/3/1 Nikos Alexandris nikos.alexand...@felis.uni-freiburg.de:
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
On Sun, Mar 1, 2009 at 4:05 PM, Hamish hamis...@yahoo.com 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==
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 it
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.
Hamish:
to
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
and
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:
done in
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 installed,
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
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
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
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
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 problem?
Thanks
Miguel
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.osgeo.org/pipermail/grass-user/attachments/20090301/e4581944
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
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
On Sat, Feb 21, 2009 at 1:42 PM, Moritz Lennert
mlenn...@club.worldonline.be 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
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 -
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 USGSDEM out of
21 matches
Mail list logo