This is the second time in two days I have had to post an apology and retraction for hasty questions. I apologize for testing everyone's patience. Thanks Markus; I was composing this message when I saw your post. I mistook a centroid of a polygon too small to plot at the current resolution as the centroid of the surrounding hollow area. My mistake; sorry.
It does raise a question, however, of what the conditions are that cause d.what.vect to return a feature type of "Boundary" rather than "Area" when querying a map. Is it simply proximity to the boundary, and can that behavior be suppressed in preference to always returning the data associated with the centroid?
Thanks, Dave
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David W. Roberts office 406-994-4548
Department of Ecology email droberts@montana.edu
Montana State University
Bozeman, MT 59717-3460
This is the second time in two days I have had to post an apology and
retraction for hasty questions. I apologize for testing everyone's
patience. Thanks Markus; I was composing this message when I saw your post.
I mistook a centroid of a polygon too small to plot at the current
resolution as the centroid of the surrounding hollow area. My mistake;
sorry.
No sweat. Even though I am one of the maintainers of the vector
libraries, I wanted to be sure and looked up the actual behaviour in
the source code to make sure that a centroid is really only attached
to an area this centroid falls within.
It does raise a question, however, of what the conditions are that cause
d.what.vect to return a feature type of "Boundary" rather than "Area" when
querying a map.
d.what.vect and v.what search for points and centroids first. If none
is found, they continue and search for lines, boundaries and faces. If
none is found, they continue and search for areas. This search order
causes any centroid or boundary to be returned if found, and not the
corresponding area. Currently there is no way to select the feature
type (point, centroid, line, boundary, area, face) to be searched.
This option could be added for v.what in 7.0 if desired.
I think it would indeed be handy if a switch was added to v.what and
d.what.vect in GRASS 7. In the meantime it might be handy to write a v.pip command for GRASS 6. I have written a point-in-polygon routine for other software (including R), but I would have to really study the file structures of GRASS vectors to attempt that in GRASS. If any GRASS programmers are interested let me know and perhaps we could work it out as an add-on.
Thanks, Dave R
Markus Metz wrote:
Dave Roberts wrote:
It does raise a question, however, of what the conditions are that cause
d.what.vect to return a feature type of "Boundary" rather than "Area" when
querying a map.
d.what.vect and v.what search for points and centroids first. If none
is found, they continue and search for lines, boundaries and faces. If
none is found, they continue and search for areas. This search order
causes any centroid or boundary to be returned if found, and not the
corresponding area. Currently there is no way to select the feature
type (point, centroid, line, boundary, area, face) to be searched.
This option could be added for v.what in 7.0 if desired.
was added to v.what and
d.what.vect in GRASS 7. In the meantime it might be
handy to write a v.pip command for GRASS 6. I have
written a point-in-polygon routine for other software
(including R), but I would have to really study the file
structures of GRASS vectors to attempt that in
GRASS. If any GRASS programmers are
interested let me know and perhaps we could work it out as
an add-on.
point in polygon is a standard function in the vector library for
years.
will find and report the cat number of the polygon that points lie within, and I can use that in a database operation which is extremely handy. So, I have done that, and now the area cat for each point is available in the database. That works for points in a point vector feature.
Using d.what.vect or v.what, however, I cannot control whether the function reports a boundary or centroid. This makes it hard to
replicate the behavior of v.distance for a few points on the fly.
Is there some way to access the existing point-in-polygon routine from an existing GRASS function to simulate what I'm after?
Looking at the progammer's manual, writing something like v.pip (= to d.what.vect reporting always area cat) appears to be a bit more than I want to bite off at present.
Perhaps one approach would be
d.where > file
(edit file as necessary for separator)
v.in.ascii in=file out=points fs=whatever
v.distance from=points to=area dmax=0 upload=cat column=areacat
That works but seems like a lot of work for what I'm after.
Thanks much, Dave
Hamish wrote:
Dave wrote:
I think it would indeed be handy if a switch
was added to v.what and
d.what.vect in GRASS 7. In the meantime it might be
handy to write a v.pip command for GRASS 6. I have
written a point-in-polygon routine for other software
(including R), but I would have to really study the file
structures of GRASS vectors to attempt that in
GRASS. If any GRASS programmers are
interested let me know and perhaps we could work it out as
an add-on.
point in polygon is a standard function in the vector library for
years.