On Aug 26, 2010, at 12:03 PM, Dwight Needels wrote:

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

I found a simple solution to adding the starting coordinates as a point when using m.cogo. I added the following as a first line in the cogo.dat file (which moves nowhere before adding the first point).

P001 N 00:00:00 E 0.00

I would still be interested in knowing if there is an easy way to insert the starting point at the beginning of the data piped to v.in.ascii or to close an open polygon after the fact by connecting the two end points.

Thanks, -Dwight

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Reply via email to