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