[GRASS-user] Survey descriptions to GRASS vector

[Dwight Needels]

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