[GRASSLIST:5265] ARCViewImport too slow

Hello all and happy new year!

I'm working with someone who uses ArcView and I need a dem that is stored in
his ArcView. We are having serious problem importing it. In fact we can't do
it.
We have export it as a shape file from ArcView. And I'm using r.in.shape to
import it. The translation into a ascii file is slow but a file is obtained
(A 4.5 millions of lines one!), but r.in.poly is dispiriting slow.
After 14 hours it is in the third pass of 26.
I've stopped it because this is clearly not a good method to operate.
Has anyone made this kind of ArcView export-GRASS import with distributed
data as a dem with success?

Thanks and regards

--
A. Javier GarcĂ­a
Water and Soil Conservation Department
CEBAS-CSIC
Apartado 4195
30080 Murcia
Spain

Tel.: +34 968 39 63 90
Fax: +34 968 39 62 13

On Fri, Jan 03, 2003 at 07:25:57PM +0100, javier garcia wrote:

Hello all and happy new year!

I'm working with someone who uses ArcView and I need a dem that is stored in
his ArcView. We are having serious problem importing it. In fact we can't do
it.
We have export it as a shape file from ArcView. And I'm using r.in.shape to
import it. The translation into a ascii file is slow but a file is obtained
(A 4.5 millions of lines one!), but r.in.poly is dispiriting slow.
After 14 hours it is in the third pass of 26.
I've stopped it because this is clearly not a good method to operate.
Has anyone made this kind of ArcView export-GRASS import with distributed
data as a dem with success?

You've got an elevation model? a raster? You convert it to a shapefile?
How? Seems r.in.ascii, r.in.arc, r.in.gdal, or m.in.e00 would all be
better ways to import raster data.

--
"...the plural of anecdote is [not?] data." - attrib. to George Stigler

even importing large shapefiles that are not rasters is too slow (polygons,
etc)....

"Eric G. Miller" <egm2@jps.net> wrote in message
news:20030104051446.GA3107@localhost...

On Fri, Jan 03, 2003 at 07:25:57PM +0100, javier garcia wrote:
> Hello all and happy new year!
>
> I'm working with someone who uses ArcView and I need a dem that is

stored in

> his ArcView. We are having serious problem importing it. In fact we

can't do

> it.
> We have export it as a shape file from ArcView. And I'm using r.in.shape

to

> import it. The translation into a ascii file is slow but a file is

obtained

> (A 4.5 millions of lines one!), but r.in.poly is dispiriting slow.
> After 14 hours it is in the third pass of 26.
> I've stopped it because this is clearly not a good method to operate.
> Has anyone made this kind of ArcView export-GRASS import with

distributed

> data as a dem with success?

You've got an elevation model? a raster? You convert it to a shapefile?
How? Seems r.in.ascii, r.in.arc, r.in.gdal, or m.in.e00 would all be
better ways to import raster data.

--
"...the plural of anecdote is [not?] data." - attrib. to George Stigler

On Fri, Jan 03, 2003 at 10:16:32PM -0800, Jeff D. Hamann wrote:

even importing large shapefiles that are not rasters is too slow (polygons,
etc)....

Yes, shapefiles (mostly polygons) are a problem. The point is, for
rasters (DEM's) you probably can and should use some other method.

--
"...the plural of anecdote is [not?] data." - attrib. to George Stigler

On Fri, 3 Jan 2003, Eric G. Miller wrote:

On Fri, Jan 03, 2003 at 10:16:32PM -0800, Jeff D. Hamann wrote:
> even importing large shapefiles that are not rasters is too slow (polygons,
> etc)....

Yes, shapefiles (mostly polygons) are a problem. The point is, for
rasters (DEM's) you probably can and should use some other method.

Would using the GDAL bridge help (r.in.gdal), since it permits the import
of many raster formats - see
http://www.remotesensing.org/gdal/formats_list.html?

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no

Baylor University is currently experiencing E-mail problems. We cannot assure that your message will be delivered in a timely manner. You do not neeed to re-send your message, it has been safely recieved by our system for eventual delivery to the recipient. We intend to have our system fully restored by Monday, Jaunary 13.