On Fri, Dec 01, 2006 at 01:46:30PM +1300, we recorded a bogon-computron collision of the <hamish_nospam@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