Tue, Jul 2 2002
21:03:12
|
|
Request created by guest
|
|
Subject: m.in.e00 segmentation faults
Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: 5.0pre4
I've been trying to import some fairly large binary arc export files. Files
with only point coverages produced a segmentation fault with "action=all" (which
is the default.) but succeeded with "action=vector." Using m.in.e00 to import
a very large (300+ MB) file with polygon coverage produced a segmentation fault
immediately after writing the last dig_cats file. "action=analyse" revealed
no problems. With a smaller (70+ MB) file with a polygon coverage m.in.e00 created
all of the dig_cats files but ran very slowly trying to import the vector map.
It ran for approximately 4 hours and was about 80% done before the OS killed
the process.
Importing a point coverage produced a site file with locations and numeric codes
identifying the sites, but brought in no other attribute values, which made the
site files nearly useless.
Roger Miller
rgrmill@rt66.com
|
|
Wed, Jul 3 2002
09:14:30
|
|
Mail sent by mw@teledetection.fr
|
|
Return-Path |
<mw@teledetection.fr>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Sender |
mw@lct1.teledetection.fr
|
Message-ID |
<3D22B268.46244124@teledetection.fr>
|
Date |
Wed, 03 Jul 2002 08:14:32 +0000
|
From |
Michel Wurtz <mw@teledetection.fr>
|
Organization |
DIG/Cemagref
|
X-Mailer |
Mozilla 4.7 [en] (X11; I; Linux 2.2.17 i686)
|
X-Accept-Language |
fr-FR, en
|
MIME-Version |
1.0
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #1170] (grass) m.in.e00 segmentation faults
|
References |
<20020702190313.37BA6139C8@lists.intevation.de>
|
Content-Type |
text/plain; charset=iso-8859-1
|
Content-Transfer-Encoding |
quoted-printable
|
X-Spam-Status |
No, hits=0.0 required=5.0 tests= version=2.20
|
X-Spam-Level |
|
Request Tracker wrote:
> =
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3D1170
> -----------------------------------------------------------------------=
--
> =
> Subject: m.in.e00 segmentation faults
> =
> Platform: GNU/Linux/i386
> grass obtained from: Trento Italy site
> grass binary for platform: Compiled from Sources
> GRASS Version: 5.0pre4
> =
> I've been trying to import some fairly large binary arc export files.
> Files with only point coverages produced a segmentation fault with
> "action=3Dall" (which is the default.) but succeeded with "action=3Dvec=
tor."
Generaly, segmentation faults are the consequence of a bugged e00 file
(m.in.e00 is especialy confused with some bad info table description).
But some bugs have been corrected in the latest release (and in CVS).
If you compiled from source, you may get the latest version of m.in.e00
with the CVS Web Interface and try again.
> Using m.in.e00 to import a very large (300+ MB) file with polygon cover=
age
> produced a segmentation fault immediately after writing the last dig_ca=
ts
> file. "action=3Danalyse" revealed no problems.
Unfortunately, I don't have such big e00 file at hand. If you know a sit=
e
where I can download one, send me the url (I have a fast internet connect=
ion).
> With a smaller (70+ MB)
> file with a polygon coverage m.in.e00 created all of the dig_cats files=
> but ran very slowly trying to import the vector map. It ran for
> approximately 4 hours and was about 80% done before the OS killed the
> process.
Writing the dig_cat file (adding each entry) takes an exponential time
(I guess that each time you add a new record, the library function
test it against any other previous entries). This is done just after
creating them, so I suspect that is the reason why it takes so much
time... and never finished. The only solution I'm thinking of is to
write directly the cat files, without the use of the grass library,
since there cannot be duplicate entries in e00. I hope also that this
problem will be solved in the new vector format (Grass 5.1).
> Importing a point coverage produced a site file with locations and nume=
ric
> codes identifying the sites, but brought in no other attribute values,
> which made the site files nearly useless.
Yes, but you may also have some dig_cats file for the other attributes,
as if you have imported a line file... (It's a "feature" that I want to
correct soon)
--
Michel WURTZ - DIG - Maison de la t=E9l=E9d=E9tection
500, rue J.F. Breton
34093 MONTPELLIER Cedex 5
|
|
Wed, Jul 3 2002
12:00:22
|
|
Mail sent by egm2@jps.net
|
|
Return-Path |
<egm2@jps.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 3 Jul 2002 03:02:26 -0700
|
From |
"Eric G. Miller" <egm2@jps.net>
|
To |
Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #1170] (grass) m.in.e00 segmentation faults
|
Message-ID |
<20020703100226.GA14567@calico.local>
|
Mail-Followup-To |
Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
|
References |
<20020702190313.37BA6139C8@lists.intevation.de> <3D22B268.46244124@teledetection.fr>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
In-Reply-To |
<3D22B268.46244124@teledetection.fr>
|
User-Agent |
Mutt/1.4i
|
Sender |
"Eric G. Miller" <egm2@jps.net>
|
X-Spam-Status |
No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
|
X-Spam-Level |
|
On Wed, Jul 03, 2002 at 08:14:32AM +0000, Michel Wurtz wrote:
> Writing the dig_cat file (adding each entry) takes an exponential time
> (I guess that each time you add a new record, the library function
> test it against any other previous entries). This is done just after
> creating them, so I suspect that is the reason why it takes so much
> time... and never finished. The only solution I'm thinking of is to
> write directly the cat files, without the use of the grass library,
> since there cannot be duplicate entries in e00. I hope also that this
> problem will be solved in the new vector format (Grass 5.1).
Yes, that could be a huge bottleneck. I was comparing insertion sorts
vs. insert and then merge sorts on linked lists, and found dramatic time
differences as the list got larger. The merge sort after inserting 1.5
million ints took about 30 secs. on my aged machine while I gave up on the
insertion sort after around 20 or 30 minutes... Making the results
unique only requires one additional pass through the data after sorting.
You could bypass the API (even though I dislike recommending it) in the
creation of the category list(s), and just use it to write the files.
A better solution would be to add a bulk category update routine to
the library.
--
Eric G. Miller <egm2@jps.net>
|
|
Tue, Jul 16 2002
22:06:46
|
|
Priority changed to 30 by bernhard
|
|
Tue, Jul 16 2002
22:07:12
|
|
Mail sent by bernhard
|
|
Can you recheck the behaviour for pre5? |
|
Tue, Apr 4 2006
13:26:15
|
|
Comments added by guest
|
|
I want mp3 player. What will advise? |
|
Tue, Apr 11 2006
05:55:34
|
|
Comments added by guest
|
|
Hi
To write the letter, it is necessary ... |
|
Mon, Jul 17 2006
17:42:13
|
|
Area changed to grass5.4 by mneteler
|
|
Fri, Dec 1 2006
07:46:25
|
|
Status changed to resolved by hbowman
|
|
Fri, Dec 1 2006
07:46:25
|
|
Comments added by hbowman
|
|
GRASS 5 is no longer being actively developed. In GRASS 6 there is a
functional replacement (v.in.e00) which uses completely different code.
So tagging this bug "won't fix" and relegating it to the archives...
Hamish
|
|