sf attribute-geometry-relationship

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

sf attribute-geometry-relationship

chris english-2
Dear Members,

After joining discrete line segments (groups of rows) into a multiline (a
row) as a kind of summary, I was wondering how i might extend sf
st_geometry()/st_agr() to report an array that would couple my segments
with their columner attribute geometry relationships (somewhat like a
subtotal applied to each line segment component of the multiline).

I ask as I note the dplyr verbs, which both encourage and daunt, but
suggest with the right incantation I might get there; the fact that the sf
result should be a WKT, which leads me to think vector rather than array,
which suggests I won't get there.

My wish for an array is that I don't, won't know in advance how many
segments, their valance (one, another, or yet another kind of attribute),
their order, & etc except as is found in the column that described their
creation as line segment (and may eventually be determined nearly real
time), which makes meuse seem both very stable and ex post facto in
comparison.

Thanking you in advance for your thoughts on this matter that I hope is
sufficiently clear.

Chris

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: sf attribute-geometry-relationship

Michael Sumner-2
Hi Chris,

where do you start here, is it a table of segments, with four columns for
the two x/y start and end coordinates, and other columns. Or is it a table
of ordered pairs of rows, or a table of grouped paths of coordinates?

If I read correctly, you can't bend simple features into what you want
here. You'll end up with another object to index the first, but no
structures in the standard or in sf to store the information. You can infer
it with st_intersection and st_relate, but then there's nowhere to put data
on the primitives or vertices.

 You can bend igraph (and the future tidygraph) for this purpose though,
and if you explore the dozens of "tracking" packages on CRAN you'll find
many similar examples. If you look at rgl you'll see primitives in "mesh3d"
with its transpose arrays of homogeneous coordinates with an index array,
but there's no classed version for segments - these are dealt with in more
raw form as pairs of indexes. rgl is no good for this since while it does
have primitive-level data (aesthetics) it only has "structural indexing",
i.e. you cannot easily subset or combine data sets without complex
re-indexing, and igraph is not enough because it doesn't have higher
groupings (like paths, arcs, rings, or features and their ever higher
analogs).

I now routinely turn these more general data structures into a set of
tables, unique coordinates indexed by primitives (segments in your case),
with group tables - including the special case of  "features". I'm still
figuring out the best component tools to work with these, but the crossover
with igraph and dplyr verbs is now clear and I'll follow the design in
tidygraph for where it goes next.

If you have a table of segments, it's easy enough to split that as two
tables. If you have implicit pairs as a path, it needs first to be
re-arranged to ensure the right attributes go to the right entity. If you
have an example data set I can illustrate, but you'll have to put up with
dev code.

Cheers, Mike.




On Thu, 9 Mar 2017 at 13:54 chris english <[hidden email]>
wrote:

> Dear Members,
>
> After joining discrete line segments (groups of rows) into a multiline (a
> row) as a kind of summary, I was wondering how i might extend sf
> st_geometry()/st_agr() to report an array that would couple my segments
> with their columner attribute geometry relationships (somewhat like a
> subtotal applied to each line segment component of the multiline).
>
> I ask as I note the dplyr verbs, which both encourage and daunt, but
> suggest with the right incantation I might get there; the fact that the sf
> result should be a WKT, which leads me to think vector rather than array,
> which suggests I won't get there.
>
> My wish for an array is that I don't, won't know in advance how many
> segments, their valance (one, another, or yet another kind of attribute),
> their order, & etc except as is found in the column that described their
> creation as line segment (and may eventually be determined nearly real
> time), which makes meuse seem both very stable and ex post facto in
> comparison.
>
> Thanking you in advance for your thoughts on this matter that I hope is
> sufficiently clear.
>
> Chris
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
--
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Loading...