[GRASS-user] Survey descriptions to GRASS vector

[Hamish]

> > 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.

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 ..?


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.

great. so the lines it created look realistic then?

> 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.

ah,

> 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.

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?

 
> 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?

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.

> 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.

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]