[GRASS-user] Importing a SDTS/DLG files?

[Tom Russo]

On Fri, Dec 01, 2006 at 01:46:30PM +1300, we recorded a bogon-computron collision of the <hamish_nospam at yahoo.com> flavor, containing:
> Tom Russo wrote:
> > > SDTS files contain several tables with no geometry (OGR calls them
> > > "Layers") that probably confuse v.in.ogr, and also contain point,
> > > line, and polygon features.  My guess is that v.in.ogr doesn't quite
> > > grok which things it needs to ignore.
> > > 
[...]
> > > 
> > > I bet if you were to use a "layer=NO01,LE01,PC01" option to v.in.ogr
> > > your woes would go away.  In fact, when I try to import the very
> > > same SDTS file above, it worked fine and gave line, point, and
> > > polygon features; the vector map displays Just Fine.
> > 
> > That particular choice of "layers" is appropriate for SDTS files that
> > contain  only polylines (such as road layers), but not for anything
> > that contains  meaningful polygons --- if you tried to use this on,
> > say, a surface cover layer all the attributes of the polygons would be
> > missing because those are in the centroids from the NA "module" (which
> > is the SDTS terminology).  To  get polygons with attributes you'll
> > need to attach centroids to the polygons,  and those are in the NA
> > module.  You'll need to use the "type=" option to  v.in.ogr to read in
> > "layers" with the right types.  I'm not exactly sure how  to do that,
> > although I think I can guess:
> > 
> >   v.in.ogr dsn=<catd file> layer=NO01,LE01,PC01,NA01
> >   type=point,line,boundary,centroid output=...
> > 
> > If I read the v.in.ogr help correctly, that should import the NO01 
> > module/"layer" as points, the LE01 module/"layer" as polylines, the
> > PC01 "layer" as boundaries, and the NP01 "layer" as area centroids. 
> > But someone more knowledgable should step in and correct me.
> 
> 
> this sounds like the basis for a nice "v.in.sdts" script for GRASS 6.

It does, but now that I look over the v.in.ogr page and code again, I'm not
sure it's right, either.  According to v.in.ogr:

 type=string[,string,...]
    Optionaly change default input type:
    point -> import area centroids as points
    line -> import area boundaries as centroids
    boundary -> import lines as area boundaries
    centroid -> import points as centroids
    Options: point,line,boundary,centroid
    Default: 

The code seems to OR together bits for the different type-change options,
and they apply across all layers being imported.  It does not associate
types in the type list with layers in the layers list. 

So it seems that specifying:
   layer=l1,l2,l3 type=t1,t2,t3
does not associate type t1 with layer 1, type t2 with layer 2, etc., but rather
   layer=NO01,LE01,PC01,NA01 type=point,line,boundary,centroid
apparently tries to change any centroids found into points, any boundaries 
into lines, any lines into boundaries, and any centrioids into points, which 
seems nonsense.

Could someone clarify to me how exactly to import from an ogr dataset that
contains points, lines, boundaries and centroids in such a way that the 
feature type in the input is in fact the feature type imported into GRASS?

It certainly would be simple to do it piecemeal:
  v.in.ogr dsn=... layer=NO01 type=point output=some_point_map
  v.in.ogr dsn=... layer=PC01,NA01 type=boundary,centroid output=some_polyg_map
  v.in.ogr dsn=... layer=LE01 type=line output=some-line_map

and then patch 'em together to make a single vector map.  Seems a convoluted 
way of doing it, but I guess it would work.  And would probably make a 
reasonable starting point for a v.in.sdts script.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick