Folks,
Is anyone maintaining v.in.dxf? Are there any plans to update or upgrade
v.in.dxf, or to write a v.out.dxf?
Roger Miller
Lee Wilson and Associates
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Fri, 18 May 2001, Roger S. Miller wrote:
Is anyone maintaining v.in.dxf? Are there any plans to update or upgrade
v.in.dxf, or to write a v.out.dxf?
Roger,
v.in.dxf almost works. Let me clarify that: it may actually be working now
that I've built a new installation. I'll check that over the weekend.
The potential problem with v.out.dxf is for which version of AutoCAD it
should be targeted. Apparently ACAD/2K is quite different from earlier
versions.
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
From neteler Fri May 18 17:12:59 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id RAA21063; Fri, 18 May 2001 17:12:59 +0100
Date: Fri, 18 May 2001 17:12:59 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5@geog.uni-hannover.de
Subject: Re: [GRASS5] v.in,dxf
Message-ID: <20010518171259.S18058@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: Markus Neteler <neteler@geog.uni-hannover.de>,
grass5@geog.uni-hannover.de
References: <Pine.OS2.3.92.1010518084545.1521A-100000@dakota>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.OS2.3.92.1010518084545.1521A-100000@dakota>; from rgrmill@rt66.com on Fri, May 18, 2001 at 08:47:20AM -0600
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 472
Lines: 18
On Fri, May 18, 2001 at 08:47:20AM -0600, Roger S. Miller wrote:
Folks,
Is anyone maintaining v.in.dxf? Are there any plans to update or upgrade
v.in.dxf, or to write a v.out.dxf?
Roger,
be sure that you have the release branch. Michel Wurtz has been
merging v.in.dxf2 and v.in.dxf recently into v.in.dxf. It
should be in working condition.
To check out the release-branch, see:
http://www.geog.uni-hannover.de/grass/grasscvs.html
(bottom of page)
Markus
"Roger S. Miller" wrote:
Folks,
Is anyone maintaining v.in.dxf? Are there any plans to update or upgrade
v.in.dxf, or to write a v.out.dxf?Roger Miller
Lee Wilson and Associates
There are plans to create a generic vector import module for 5.1. This
will separate the functions of importing data from various sources and
writing it to GRASS. This has to deal a few problems at the moment. It
needs to be a piecemeal, or segmented approach, as import of very large
files is limited. A recent report was that a shapefile of 105 MB failed
to import. This requires some amount of development, quick hacks won't
do the job. But we won't have really satisfactory import/export features
till it's done.
It seems a good idea to do the same (in reverse) for output.
Regards
David
Rich Shepard wrote:
v.in.dxf almost works. Let me clarify that: it may actually be working now
that I've built a new installation. I'll check that over the weekend.
Rich, have you been working on the code? The version that was packed with
beta11 doesn't handle splines and that's really the only major problem I
had when I tried to import a DXF from ACAD/2k.
Markus, I took a quick look at the CVS release and from the comments it
doesn't appear that work is underway to add new capabilities. Mostly a
much-needed clean-up.
I recently needed to import a ACAD/2K dxf and nothing I had access to
would swallow it (including my apparently aging version of AC Lite). I've
been writing my own programs to read, process and write DXF for several
years, so I just adapted one of those programs to read splines and write
the equivalent lines.
I'm willing to give my spline routine to someone who might incorporate it
into v.in.dxf. My program works, but it isn't full featured and it is
just a simple cubic b-spline, so might not even be the right kind of
spline. The DXF files contain several codes that I don't interpret to
produce the lines.
In the course of doing that I found a GPLed C++ class library called DIME
(Dxf Import Manipulation and Export). I decided that it would probably be
better to incorporate DIME in any future coding I have to do rather than
continue my hacking, but I didn't do it right away because I didn't want
to move to C++. I haven't used DIME at all, yet.
Has anyone thought much about incorporate DIME into v.in.dxf/v.out.dxf ?
The potential problem with v.out.dxf is for which version of AutoCAD it
should be targeted. Apparently ACAD/2K is quite different from earlier
versions.
As far as I know, the main version difference that would effect v.out.dxf
is the difference between the old-style POLYLINE and the new-style
LWPOLYLINE used in ACAD/R14 and later. LWPOLYLINE would be a better
choice, as it's simpler, but the old POLYLINE format is the only one
that's sure to work with old software.
There are also revisions to the dxf header, so that my old AC lite program
won't even read through the header from the new 2k dxf. AC Lite was the
only app I had that reported a problem with the header.
David, is the problem of importing a dxf substantially different from
importing a shapefile? Even with the generic vector import capability,
won't there still be a place for something like DIME to handle the dxf
format?
Roger Miller
On Fri, 18 May 2001, Roger S. Miller wrote:
Rich, have you been working on the code?
Roger,
No. I was trying to get some data from MapInfo into GRASS. I tried .dxf,
.mif, .shp and .e00. Finally figured out that it was a corrupted GRASS
installation causing the problems.
The version that was packed with beta11 doesn't handle splines and that's
really the only major problem I had when I tried to import a DXF from
ACAD/2k.
Ah, yes! The ACAD from Hell. I had to migrate a GIS data base from MapInfo
to ACAD/2k. Well, with the help of local folks who have ACAD rel. 12 or 13
in their shops, I was able to provide both .dxf and .dwg files to my client.
(They gave me the MI files from another of their consultants.) While the
objects were visible, no lables could be found. We finally figured it was a
problem with ACAD/2k and let it go at that.
I'm willing to give my spline routine to someone who might incorporate it
into v.in.dxf. My program works, but it isn't full featured and it is
just a simple cubic b-spline, so might not even be the right kind of
spline. The DXF files contain several codes that I don't interpret to
produce the lines.
I would like to nominate David Gray as team leader/coordinator for the
data import efforts. He's done outstanding work on v.in.mif and v.in.shape
and is far ahead of me in comprehending computational geometry. Not that
David has to do all the work, but he'd be the ideal coordinator, IMO.
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
From neteler Fri May 18 18:34:47 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id SAA21951; Fri, 18 May 2001 18:34:47 +0100
Date: Fri, 18 May 2001 18:34:46 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5 developers list <grass5@geog.uni-hannover.de>
Message-ID: <20010518183446.D21673@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: Markus Neteler <neteler@geog.uni-hannover.de>,
grass5 developers list <grass5@geog.uni-hannover.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [GRASS5] Tagging 5.0.0pre1 tomorrow (sat, 19 May 2001)?
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
Reply-To: grass5@geog.uni-hannover.de
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 167
Lines: 7
Hi all,
as the Xdriver problems seem to be fixed, let's tag 5.0.0pre1
as soon as possible. If there are no objections, I would tag
by tomorrow, Sat 19th May.
Markus
"Roger S. Miller" wrote:
Rich Shepard wrote:
> v.in.dxf almost works. Let me clarify that: it may actually be working now
> that I've built a new installation. I'll check that over the weekend.Rich, have you been working on the code? The version that was packed with
beta11 doesn't handle splines and that's really the only major problem I
had when I tried to import a DXF from ACAD/2k.Markus, I took a quick look at the CVS release and from the comments it
doesn't appear that work is underway to add new capabilities. Mostly a
much-needed clean-up.I recently needed to import a ACAD/2K dxf and nothing I had access to
would swallow it (including my apparently aging version of AC Lite). I've
been writing my own programs to read, process and write DXF for several
years, so I just adapted one of those programs to read splines and write
the equivalent lines.I'm willing to give my spline routine to someone who might incorporate it
into v.in.dxf. My program works, but it isn't full featured and it is
just a simple cubic b-spline, so might not even be the right kind of
spline. The DXF files contain several codes that I don't interpret to
produce the lines.In the course of doing that I found a GPLed C++ class library called DIME
(Dxf Import Manipulation and Export). I decided that it would probably be
better to incorporate DIME in any future coding I have to do rather than
continue my hacking, but I didn't do it right away because I didn't want
to move to C++. I haven't used DIME at all, yet.Has anyone thought much about incorporate DIME into v.in.dxf/v.out.dxf ?
> The potential problem with v.out.dxf is for which version of AutoCAD it
> should be targeted. Apparently ACAD/2K is quite different from earlier
> versions.As far as I know, the main version difference that would effect v.out.dxf
is the difference between the old-style POLYLINE and the new-style
LWPOLYLINE used in ACAD/R14 and later. LWPOLYLINE would be a better
choice, as it's simpler, but the old POLYLINE format is the only one
that's sure to work with old software.There are also revisions to the dxf header, so that my old AC lite program
won't even read through the header from the new 2k dxf. AC Lite was the
only app I had that reported a problem with the header.David, is the problem of importing a dxf substantially different from
importing a shapefile? Even with the generic vector import capability,
won't there still be a place for something like DIME to handle the dxf
format?
No, it's substantially similar. But this is the reason why we should
separate out the two phases of the import - so that we don't have to
duplicate effort. The other advantage is that we can utilise suitable
3rd party libraries to handle their respective formats. Which is the
gist of what you are saying I think.
David
Roger Miller
_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5
On Fri, 18 May 2001, David D Gray wrote:
No, it's substantially similar. But this is the reason why we should
separate out the two phases of the import - so that we don't have to
duplicate effort. The other advantage is that we can utilise suitable
3rd party libraries to handle their respective formats. Which is the
gist of what you are saying I think.
Great, I think I'm on the same page with you :). Is there any sort of
timetable for that generic capability to be in place?
Roger Miller
"Roger S. Miller" wrote:
On Fri, 18 May 2001, David D Gray wrote:
> No, it's substantially similar. But this is the reason why we should
> separate out the two phases of the import - so that we don't have to
> duplicate effort. The other advantage is that we can utilise suitable
> 3rd party libraries to handle their respective formats. Which is the
> gist of what you are saying I think.Great, I think I'm on the same page with you :). Is there any sort of
timetable for that generic capability to be in place?Roger Miller
I see a time-table something like:
Work has started on the changes to the GRASS 5.1 level vector library.
This aims to address as quickly as possible the most glaring
deficiencies in the current vector libs. You've possibly seen the code
in the grass51 tree - we need to get a minimum but self-contained tree
working before there can be much co-operative effort on moving that
forward. Clearly the priority is to try and get 5.0 out the door first,
but it seems that will be on the way soon.
However I've been working on an importer, which at present has a
perl-based mif import as the front end, and this is essentially
complete, also is based on the current vector engine, so there is a form
that will be backward-compatible with 5.0 anyway. A first pass at a
generic line importer, based on techniques similar to those used in
v.in.shape/mif is also about ready to roll. (Both these will get
uploaded to the 5.1 tree at some point soon.) The part handling the
external routines is only a hack to get sufficient data in from the
external format to enable me to work on the important part which is the
routines for writing to the GRASS database. The good news is that the
import stage can easily be modified to import other ascii types, though
they are intended to be only temporary. A more final solution for a
unified front end would be the OGR library which Frank Warmerdam is
working to integrate with GRASS. Hopefully all of that would be in 5.1 -
but your guess is as good as mine as to when that will freeze.
The other `big issue' is segmentation. I don't think that will be ready
for 5.1 in general terms, but I hope to have a provisional technique in
place just for import/export, so that we can deal with _much_ larger
maps. Of course, the real reward of this eventually will be that
processing parameters (time, memory) rise more linearly with map size.
Regards
David
From neteler Sun May 20 19:17:15 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id TAA04807; Sun, 20 May 2001 19:17:15 +0100
Date: Sun, 20 May 2001 19:17:15 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5 developers list <grass5@geog.uni-hannover.de>
Message-ID: <20010520191715.A4751@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5 developers list <grass5@geog.uni-hannover.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [GRASS5] GRASS 5.0.0pre1 tagged and sources released!
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 1417
Lines: 44
Hi developers,
as there have been no objections I have tagged GRASS 5.0.0pre1
and subsequently released the sources onto the GRASS server.
release_grass500pre1_20_may_2001
To get the tag from CVS, either check out the full code:
cvs -z3 co -r "release_grass500pre1_20_may_2001" grass
or update your existing version:
cvs up -dP -r "release_grass500pre1_20_may_2001"
Before posting announcements, the binaries should be generated from the
(tagged) source code package:
http://www.geog.uni-hannover.de/grass/grass5/source/
(16.3MB)
Things to do (volunteers wanted, please post in "grass5" if you volunteer):
- generate binaries for
- Linux/x86,
- Solaris (SUN, x86),
- SGI,
- MacOS X (the MacOSX binaries should have "normal" 60MB size this
time...),
- winGRASS
as soon as possible. For details, how to generate such a binary release
package, see the instructions in source code:
documents/release_rules.txt
See there section "Create source and binary distributions"
Binaries can be uploaded here at
ftp 130.75.72.36
cd incoming
It is write only, no reading. Please notify me after upload.
- fix any severe bugs...
- stop 5.0.0 development (publish it) and start 5.1 asap.
From here a GREAT THANKS to all developers for their input! GRASS runs
pretty neat comparing to older times. So: Keep up the good work!
Regards
Markus
From neteler Sun May 20 19:38:11 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id TAA04969; Sun, 20 May 2001 19:38:11 +0100
Date: Sun, 20 May 2001 19:38:11 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5@geog.uni-hannover.de
Subject: auto-flush was: Re: [GRASS5] Tagging 5.0.0pre1 tomorrow (sat, 19 May 2001)?
Message-ID: <20010520193811.B4950@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5@geog.uni-hannover.de
References: <20010518183446.D21673@hgeo02.geog.uni-hannover.de> <15109.27491.403046.272334@cerise.nosuchdomain.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15109.27491.403046.272334@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Fri, May 18, 2001 at 07:35:15PM +0100
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 458
Lines: 14
On Fri, May 18, 2001 at 07:35:15PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> as the Xdriver problems seem to be fixed, let's tag 5.0.0pre1
> as soon as possible. If there are no objections, I would tag
> by tomorrow, Sat 19th May.In which case, I'll start implementing the auto-flush.
Thanks for the auto-flush, Glynn. It runs well on Linux (both GNOME and
KDE) and Solaris2.6. So it is shipping with the new version.
Markus
On Fri, 18 May 2001, David D Gray wrote:
No, it's substantially similar. But this is the reason why we should
separate out the two phases of the import - so that we don't have to
duplicate effort. The other advantage is that we can utilise suitable
3rd party libraries to handle their respective formats. Which is the
gist of what you are saying I think.
I'll probably look stupid, but what is the second phase of the import ?
The process of importing vector is mainly a stream (with some exceptions
when reading the imput file). If not, you will need a temporary storage
format (on disk, because storing everything in core memory will allways
limit the size of the imput file)
--
Michel WURTZ - DIG - Maison de la télédétection
500, rue J.F. Breton
34093 MONTPELLIER Cedex 5
Michel Wurtz wrote:
On Fri, 18 May 2001, David D Gray wrote:
>
> No, it's substantially similar. But this is the reason why we should
> separate out the two phases of the import - so that we don't have to
> duplicate effort. The other advantage is that we can utilise suitable
> 3rd party libraries to handle their respective formats. Which is the
> gist of what you are saying I think.
>I'll probably look stupid, but what is the second phase of the import ?
The process of importing vector is mainly a stream (with some exceptions
when reading the imput file). If not, you will need a temporary storage
format (on disk, because storing everything in core memory will allways
limit the size of the imput file)
It's only a direct import if the original format supports component
arcs. Many formats record the data as whole polygons, so must be 'split'
to arcs before writing to dig files, so some kind of intermediate is
necessary.
The first stage is substantially diffferent for different formats. Also
there is often pre-processing or different fields to be read. A Mapinfo
import has to record the Pen and Brush attributes (or will if we are
going down the road of incorporating these). More significantly, you
have to `deconstruct' the topology of a set of components in a shapefile
as a shape can be compound. So stage 1 reads the original format,
pre-processes the data and deals with spatial and data attributes. Stage
two imports the linework as arcs regardless of the original format, from
a common intermediate.
Of course this isn't necessarily a time separation. It's just a logical
or programmatic separation. Some stages may be carried out in parallel
as lines are imported or they may be sequential.
David
On Mon, 21 May 2001, David D Gray wrote:
Michel Wurtz wrote:
>
> I'll probably look stupid, but what is the second phase of the import ?
> The process of importing vector is mainly a stream (with some exceptions
> when reading the imput file). If not, you will need a temporary storage
> format (on disk, because storing everything in core memory will allways
> limit the size of the imput file)
>It's only a direct import if the original format supports component
arcs. Many formats record the data as whole polygons, so must be 'split'
to arcs before writing to dig files, so some kind of intermediate is
necessary.The first stage is substantially diffferent for different formats. Also
there is often pre-processing or different fields to be read. A Mapinfo
import has to record the Pen and Brush attributes (or will if we are
going down the road of incorporating these). More significantly, you
have to `deconstruct' the topology of a set of components in a shapefile
as a shape can be compound. So stage 1 reads the original format,
pre-processes the data and deals with spatial and data attributes. Stage
two imports the linework as arcs regardless of the original format, from
a common intermediate.
I find this a little confusing for the case of a dxf import. DXF files
contain no topology, but they do contain a large number of different kinds
of drawn objects, none of which are polygons and none of which interpret
to GRASS polylines without some computation.
I nearly asked the same question that Michael asked, but held off. Before
reading your answer I had envisioned a five step process.
1) Read the vector data from it's native format
2) Recalculate the lines specified in the native format to GRASS
polylines, and store the raw data.
3) Check each object against objects already imported and remove
non-unique object
4) Build GRASS database support files
5) Write the GRASS database
In this breakdown the first 2 steps would be specific to the format and
would result in a raw database, probably resident in temp files. The last
three steps could be part of a generic import capability. The generic
part of the process would start with the information stored in the temp
files and result in a final imported database.
In the case of a DXF file, this is OK, but the same procedure applied to a
format that included topology would result in the loss of the original
topology. I presumed that a topology would be rebuilt with a new
v.support.
David, is an "arc" in your usage similar to a polyline? I found the term
initially a little confusing. Autocad uses the same term to refer to a
section of a circle specified with a center, a radius and beginning and
ending azimuths.
Roger Miller
"Roger S. Miller" wrote:
On Mon, 21 May 2001, David D Gray wrote:
> Michel Wurtz wrote:
> >
> > I'll probably look stupid, but what is the second phase of the import ?
> > The process of importing vector is mainly a stream (with some exceptions
> > when reading the imput file). If not, you will need a temporary storage
> > format (on disk, because storing everything in core memory will allways
> > limit the size of the imput file)
> >
>
> It's only a direct import if the original format supports component
> arcs. Many formats record the data as whole polygons, so must be 'split'
> to arcs before writing to dig files, so some kind of intermediate is
> necessary.
>
> The first stage is substantially diffferent for different formats. Also
> there is often pre-processing or different fields to be read. A Mapinfo
> import has to record the Pen and Brush attributes (or will if we are
> going down the road of incorporating these). More significantly, you
> have to `deconstruct' the topology of a set of components in a shapefile
> as a shape can be compound. So stage 1 reads the original format,
> pre-processes the data and deals with spatial and data attributes. Stage
> two imports the linework as arcs regardless of the original format, from
> a common intermediate.I find this a little confusing for the case of a dxf import. DXF files
contain no topology, but they do contain a large number of different kinds
of drawn objects, none of which are polygons and none of which interpret
to GRASS polylines without some computation.
The form of the original points is not important - it only requires that
the position of each vertex be given and that there is some way of
knowing how they are linked. The problem with importing DXF as polygons
is that usually (as you point out) they don't represent a polygon
coverage - that's not generally what CAD is for. If it is being used for
that purpose however, then the import would assume that it is in a
suitably correct form, or near enough to be corrected. So if you import
a layer from a DXF with the instruction to build it as an area coverage,
GRASS will try to do that and assume that any lines that do not conform
to the required topology are errors.
I nearly asked the same question that Michael asked, but held off. Before
reading your answer I had envisioned a five step process.1) Read the vector data from it's native format
2) Recalculate the lines specified in the native format to GRASS
polylines, and store the raw data.
3) Check each object against objects already imported and remove
non-unique object
4) Build GRASS database support files
5) Write the GRASS database
Here Stages 2 - 5 correspond to my second phase. 2 is - because the same
procedure is used to process linework from arbitrary but adequately
defined lines to the GRASS area boundaries. 1 contains most of the
procedures unique to a particular import type.
In this breakdown the first 2 steps would be specific to the format and
would result in a raw database, probably resident in temp files. The last
three steps could be part of a generic import capability. The generic
part of the process would start with the information stored in the temp
files and result in a final imported database.In the case of a DXF file, this is OK, but the same procedure applied to a
format that included topology would result in the loss of the original
topology. I presumed that a topology would be rebuilt with a new
v.support.
This is a point, if we are importing actual topolgy, then there should
be a way of transferring the details from the original file to the GRASS
topo file. What formats are affected? Arc/Info binary/e00, DLG, SDTS
that I can think of. I don't know much about these modules, I assumed
they already do this OK. Perhaps these should remain in their own
development branches for now - only updated for 5.1 changes. The generic
module would cover shapefile, Mapinfo, DXF and A/I ungenerate at least.
David, is an "arc" in your usage similar to a polyline? I found the term
initially a little confusing. Autocad uses the same term to refer to a
section of a circle specified with a center, a radius and beginning and
ending azimuths.
Well, `arc' is a confusing term. It is sometimes referred to a line
segment, and, as in the phrase `arc-node' , sometimes has to be
interpreted as a polyline, and also it's usual geometric meaning of a
curve segment. But polyline is also ambiguous. In the context I mean
here, I mean a single non-overlapping, non-crossing and
non-self-crossing line segment that constitutes the boundary of an area
between two nodes (or pseudonodes) in an area coverage that is a
correctly formed 2-dimensional manifold (... rare as hens' teeth these
days... 
)
David
David D Gray wrote:
It's only a direct import if the original format supports component
arcs. Many formats record the data as whole polygons, so must be 'split'
to arcs before writing to dig files, so some kind of intermediate is
necessary.The first stage is substantially diffferent for different formats. Also
there is often pre-processing or different fields to be read. A Mapinfo
import has to record the Pen and Brush attributes (or will if we are
going down the road of incorporating these). More significantly, you
have to `deconstruct' the topology of a set of components in a shapefile
as a shape can be compound. So stage 1 reads the original format,
pre-processes the data and deals with spatial and data attributes. Stage
two imports the linework as arcs regardless of the original format, from
a common intermediate.Of course this isn't necessarily a time separation. It's just a logical
or programmatic separation. Some stages may be carried out in parallel
as lines are imported or they may be sequential.David
Is it second stage more than v.spag + v.rmdup (if working correctly)?
I would prefer two import stages separated into modules because second
stage proces may be used for other (non import) tasks also
(clening patched maps for example).
Cleaning proces will be always problem for dirty maps and so may be
useful to have possibility to compare map before and after cleaning proces
to find problems and occasionally edit by hand.
Radim
Radim Blazek wrote:
David D Gray wrote:
>
> It's only a direct import if the original format supports component
> arcs. Many formats record the data as whole polygons, so must be 'split'
> to arcs before writing to dig files, so some kind of intermediate is
> necessary.
>
> The first stage is substantially diffferent for different formats. Also
> there is often pre-processing or different fields to be read. A Mapinfo
> import has to record the Pen and Brush attributes (or will if we are
> going down the road of incorporating these). More significantly, you
> have to `deconstruct' the topology of a set of components in a shapefile
> as a shape can be compound. So stage 1 reads the original format,
> pre-processes the data and deals with spatial and data attributes. Stage
> two imports the linework as arcs regardless of the original format, from
> a common intermediate.
>
> Of course this isn't necessarily a time separation. It's just a logical
> or programmatic separation. Some stages may be carried out in parallel
> as lines are imported or they may be sequential.
>
> DavidIs it second stage more than v.spag + v.rmdup (if working correctly)?
The second stage works by loading the vertices into a structure that is
a kind of network, with some of the properties of a graph, and some of a
keyed database. The points can be loaded for the whole map, for a
specified segment or for a region based on a spatial query (the last two
not available yet). Then cleaning of various kinds can be done by
standard routines that we develop. ie. elliminate line-crossing if this
is not allowed, and remove duplicate and colinear tracks. So it provides
the functionality of v.spag and v.rmdup, but does it in a more
consistent way, and does much more.
I would prefer two import stages separated into modules because second
stage proces may be used for other (non import) tasks also
(clening patched maps for example).
We can also use this for carrying out the functions of things like
v.cutter and v.patch, and implement v.rmdup and v.spag this way.
Cleaning proces will be always problem for dirty maps and so may be
useful to have possibility to compare map before and after cleaning proces
to find problems and occasionally edit by hand.
I briefly included an option in v.in.shape for storing lines the import
registered as `bad' in some way, in an auxiliary line-only map called
<mapname>_rej, but it needed more work so is currently disabled. But
something along these lines is not too difficulkt to do.
David
"Roger S. Miller" wrote:
[...]
This is a considerable problem with DXF files. The only "entities" I
know of that actually define each vertex are the LINE -- a straight line
defined by two points -- and POINT entities.POLYLINE and LWPOLYLINE entities will often define all of the necessary
vertices, but they can include curved segments (called bumps) that are
specified with a "bump factor" and two vertices. The application that
interprets the DXF has to supply the actual vertices that form the
curved segment. I've never come a cross a polygon entity, but both
POLYLINE and LWPOLYLINE entities can be closed to form polygons.
This seems like relating the density of points along a line to curvature
where this has to be autogenerated from some parameterised line.
Other entities similarly don't define the necessary vertices. A CIRCLE
is defined with a center and a radius, and an ARC is defined with
center, radius and beginning and ending azimuths. Maybe the worst of
all, a SPLINE is defined with a set of control points, and the actual
curve passes near (not usually through) the control points.
In each case, we could have an algorithm for generating a series of
coordinates of a true polyline from the parameters given. These would
have to relate the assigned positions to 1) the curvature as we move
along the line, and 2) the map scale as specified in PERMANENT. Maps at
different scales need different resolutions of curvature.
> Here Stages 2 - 5 correspond to my second phase. 2 is - because the same
> procedure is used to process linework from arbitrary but adequately
> defined lines to the GRASS area boundaries. 1 contains most of the
> procedures unique to a particular import type.I think with a DXF the idea is that the rendering software defines the
actual vertices in the drawn objects at the time the entity is
rendered. Spacing between the vertices is selected to match the scale
of the drawing and the resolution of the device they're being drawn on.
When the entities are imported into GRASS the importing software must
somehow calculate the vertices to provide sufficient resolution for most
purposes. That's why I figured conversion to a consistent internal raw
data format would be part of the format-specific code, rather part of
the generic import capability.
There are really three stages of line data.
1) the original, that can be anything.
2) polylines that have been assembled from the interpretation of the
spatial data in the original.
3) the polylines in the dig (vector) file that are in a correct coverage
format, but not yet indexed (built).
So the specific first-phase would need to handle the 1->2 import, and
the 2->3 import would be the generic stage. The lines in the
intermediate (2) stage would have the correct positions and links, but
can be chopped any way, and may be duplicated. For example, at one
extreme, they could be whole polygons, and here each vertex and link
would occur precisely twice, apart from a possible universal boundary.
At the other extreme, they could just be a list of the simple links,
which would occur once and the associated vertices 2 or more times. So
2->3 import really does some processing, it's not just a stream
converter. All this assumes the import stuff is `clean', the 2->3 import
should attempt some correction of common errors, such as degenerate
polygons of the type:
------X-----------------------------------X-------------
---------------X-------------------
in I hope an obvious convention.
<snip>
> This is a point, if we are importing actual topolgy, then there should
> be a way of transferring the details from the original file to the GRASS
> topo file. What formats are affected? Arc/Info binary/e00, DLG, SDTS
> that I can think of. I don't know much about these modules, I assumed
> they already do this OK. Perhaps these should remain in their own
> development branches for now - only updated for 5.1 changes. The generic
> module would cover shapefile, Mapinfo, DXF and A/I ungenerate at least.I understand that SDTS can contain considerable complexity, but isn't
DLG a pretty simple format?
I've seen the DLG Optional format Level 3 spec. It seems much like A/I
binary/e00 in terms of the information given.
It appears that the problem of importing a DXF may be substantially
different from that of importing data from the GIS applications.
Perhaps it won't fit the same generic model?
The first stage is pretty unique, but the second phase will be the same
as shapefile, mif etc. as these also must be deconstructed and
re-assembled. But import of the true topo formats could be more direct
(or could be deconstructed and rebuilt, if the original data couldn't be
trusted).
David
From neteler Tue May 22 19:22:29 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id TAA23268; Tue, 22 May 2001 19:22:29 +0100
Date: Tue, 22 May 2001 19:22:28 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5 developers list <grass5@geog.uni-hannover.de>
Message-ID: <20010522192228.B23204@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5 developers list <grass5@geog.uni-hannover.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [GRASS5] Volunteers for 5.0.0pre1 wanted
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 193
Lines: 10
Dear subscribers,
still we need volunteers for the GRASS 5.0.0pr1 binaries 
All positions available except SGI (being done by Justin).
It's not too difficult.
Thanks in advance,
Markus
David D Gray wrote:
There are really three stages of line data.
1) the original, that can be anything.
2) polylines that have been assembled from the interpretation of the
spatial data in the original.
3) the polylines in the dig (vector) file that are in a correct coverage
format, but not yet indexed (built).So the specific first-phase would need to handle the 1->2 import, and
the 2->3 import would be the generic stage.
Then it seems that the front-end developers can get to work on the new
packages as soon has you have defined the format for this intermediate
line type.
Roger Miller
"Roger S. Miller" wrote:
David D Gray wrote:
> There are really three stages of line data.
>
> 1) the original, that can be anything.
> 2) polylines that have been assembled from the interpretation of the
> spatial data in the original.
> 3) the polylines in the dig (vector) file that are in a correct coverage
> format, but not yet indexed (built).
>
> So the specific first-phase would need to handle the 1->2 import, and
> the 2->3 import would be the generic stage.Then it seems that the front-end developers can get to work on the new
packages as soon has you have defined the format for this intermediate
line type.Roger Miller
I think so. I will soon make a proposal about formats and requirements
for the lines, for both monolithic and segmented imports. There are also
some suggestions about how to get the area points out for various
formats.
David