Dwight wrote:
Is there a straightforward way to encode a survey description of a
parcel in a text file that can then be imported into GRASS as a
vector? The type of description I am talking about looks something
like this (where the numbers are degrees/.minutes/seconds)...
"Beginning at [a defined point], thence running North 40-35-00 East
1,125.90 feet to a point, thence turning and running South
01-01-13 West 288.89 feet to a point, thence turning and running
South 58-18-45 West 179.33 feet to a point, [...] , thence turning
and running South 83-41-12 West 36.69 feet to the point of
beginning."
Markus Neteler wrote:
m.cogo comes to mind:
http://grass.osgeo.org/grass64/manuals/html64_user/m.cogo.html
for turning this into to true coordinates, then perhaps v.in.ascii.
Hamish wrote:
note that m.cogo is written for the funny land deed surveying
convention
used in the United States, not True (nautical) compass bearings as you
might expect. rather it is a first-person perspective bearing
system. from
the help page:
"For those unfamiliar with the notation for bearings: Picture
yourself in
the center of a circle. The first hemispere notation tell you
whether you
should face north or south. Then you read the angle and either turn
that
many degrees to the east or west, depending on the second hemisphere
notation. Finally, you move <distance> units in that direction to
get to
the next station."
but that looks like what Dwight is dealing with, so m.cogo is still
the
right tool ..?
Yes it is funny, and yes it is what I am dealing with (pulled from US
deed descriptions).
Dwight wrote:
Fantastic!
I can bring the survey description in as a series of points
by piping the output of m.cogo to v.in.ascii, as described
in the manual.
Hamish wrote:
great. so the lines it created look realistic then?
Yes, they do (the biggest challenge is figuring out the appropriate
starting coordinates in map units).
Dwight wrote:
However, I had some difficulty running the shell script to import as
a vector line map (I am running William Kyngesburye's 6.4RC6-3 on Mac
OS X Leopard). It fails (as does the v.in.lines script) because 'tac'
is not available on Mac OS.
Hamish wrote:
ah,
Dwight wrote:
I found a 2 year old defect report (Ticket #181) that
discusses this problem in some detail. As described there, I
replaced the tac command with 'tail -r', which worked. What
is the status of a general fix for v.in.mapgen, v.in.lines
and v.in.garmin? If it will be awhile, it would be nice to
include the 'tail -r' tip for Mac OS users on the m.cogo
manual page. Also, a m.cogo | v.in.lines piping example
would be useful for non-Mac OS users.
Hamish wrote:
comment added in bug trac'er, maybe we can just extend the grocat
helper app already GRASS's $GISBASE/etc/ to do reversing as well?
Dwight wrote:
One other thing that I have not been able to figure out is
how to automatically close the line vector into a polygon to
create an area for the parcel. Given the small number of
vectors involved it is easy enough to manually edit each
vector to close it, add a centroid, and convert lines to
boundaries. However, is there a good way to accomplish the
closing automatically?
Hamish wrote:
try v.type to convert lines to boundaries, then run v.centroids to add
a centroid to each closed area. hopefully there are no area overlaps
to
clean up.
The problem is that m.cogo does not add a point at the starting
coordinates, so the first point generated is the position *after* the
first angle/distance combination (it adds n rather than n+1 points).
Because it describes a closed polygon, the last point is almost
exactly on top of the starting coordinates (in my test example both x
and y are off by less than 0.002 ft after following a perimeter of
2,386.41 ft). However, there is only a single point there, so there is
nothing to snap.
The script connects the first point to the second, etc., but what
should be the first line segment (from the starting coordinates to the
first point) does not get drawn.
What I don't know how to do is to add a point at the starting
coordinates in the pipe sent to v.in.ascii.
For reference, here is the script from the m.cogo manual, modified to
work on Mac OS (replacing 'tac' with 'tail -r').
m.cogo -l in=cogo.dat coor=985186,766306 | tail -r | awk '
BEGIN { FS=" " ; R=0 }
$1~/\d*\.\d*/ { printf(" %.8f %.8f\n", $1, $2) ; ++R }
END { printf("L %d\n", R) }' | tail -r | \
v.in.ascii -n format=standard out=cogo_line
Thanks, -Dwight
Dwight wrote:
If so, is this something that could
be added as an option in m.cogo (or perhaps a v.in.areas
wrapper script that automatically takes care of all of the
steps to close and generate areas)? Or perhaps even a
general v.in.cogo script that imports a cogo.dat formatted
file with options for bringing it in as points, a line, or
an area.
Hamish wrote:
An interesting idea; you would need a 'v.clean tool=snap' step with a
low threshold to make sure that the circuit closed on itself. I am not
sure if the snap tool is safe for lat/lon or not. (??)
probably it is a fairly easy script for someone to write and a no-
brainer
if they had to process lots of land parcels.
and it looks like it would also be pretty easy to add a -b flag to
v.in.lines to import as boundaries instead of lines. An -a flag to
run v.centroids as well could happen, but would suffer from unclosed
boundaries/snapping problem unless the data was pre-cleaned.
file a wish in the trac'er for this if you like,
Hamish
[yahoo mail is driving me nuts]
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
