Subscribe to this thread
Home - General / All posts - M9 Metes and Bounds Issue
710 post(s)
#29-Oct-19 17:54

What am I doing wrong? Here's the txt file I'm using to read into M9

#detail 1 from Oak Hollow 1 Scan sw

#beginning at the w corner of lot 3



SP 1988341.7738294473 13782687.052906185

eP 1988341.7738294473 13782687.052906185

DD n65-35-1e 271.47

DD n72-45-1e 154.23

DD n72-45-1e 15

DD n43-28-1e 67.13

TC D 95-26-2 A 35 R

TC D 47-7-2 A 137.57 L

DD s88-12-59e 123.45

TC D 154-21-57 A 161.65 L

DD s27-25-14w 810.47

DD n51-31-16w 252.56

DD n46-35-24w 192.83

DD n36-6-11e 195

DD n49-58-59w 287

The resulting metes and bounds in Manifold 9 are attached (won't link back for some reason)

The curves described in the txt file are TC tangent curves. The curves described in Manifold are NC non-tangent curves. Also the curves in the txt are right, left, left, while the curves in Manifold are right, right, right. I tried using the curve radius with the R code, but Manifold seemed to have taken that to mean something else.

I'm thinking I have the syntax wrong in the txt file, but I don't see what the problem is. The curve data I'm given in the original drawing is also attached.

Curve data for Manifold 9 Test.tif
Metes and Bounds in Manifold - error.jpg

710 post(s)
#29-Oct-19 20:23

In reply to myself on this, I just got back from lunch and noticed I needed to make a change from 65 degrees to 63 degrees in the first DD line. I made that change and replotted, and the result is completely different. I'm not sure why, but the results are still not perfect at the third curve. I'm still looking at this...


9,223 post(s)
#29-Oct-19 21:00

I have no help to offer but am bewildered by the complexity you have to deal with.

You are dealing with a broken, limping survey system, in the second-largest state (I think) in the most powerful nation in the world (I think).

Any idea why you have to deal with this? Why is it not a political issue? OK, it would be totally boring to most people. But by the same token, why isn't it just fixed?


9,144 post(s)
#30-Oct-19 09:27

This is exactly the process of fixing it - taking data described in arcane language and putting it into a digital form so that it can be used easier. :-)

710 post(s)
#30-Oct-19 13:31

This is the only system I've ever seen. Well I have seen townships in the Texas Panhandle with descriptions like N2NW4 to indicate the north half of the northwest quarter of a square township. Townships are supposed to run north-south-east-west, but they are tapered by the non parallel lines of longitude. Being lost in this forest of trees, is there another forest whereby you could describe fairly complicated parcel shapes? The picture of the final shape is attached. How would that be described by a modern survey?

Oak Hollow Lot 3.jpg

Mike Pelletier

1,729 post(s)
#30-Oct-19 14:25

Have you seen our president lately? :-)

My understanding is the distance and bearing descriptions are the root of more simplified survey systems or legal descriptions. In the US we also use subdivision plats (dchall8's example) as described here. Perhaps that is more similar to New Zealand once it is put in a GIS?

We also use an inefficient system of private insurance to deal with discrepancies in comparison to a more efficient means of control by a benevolent government. The US has bigger problems to fix first :-)

We have some subdivisions where lots are circles and the space between is common land. It requires only one survey pin in the center to mark the property. Like most things it works well if everyone gets along.

drtees90 post(s)
#30-Oct-19 15:54

This "limping survey system" is just one of the many peculiarities we deal with in the US. We use Empirical units of measurement instead of metric because "it would cause economic hardship" to change over. The government uses an older datum (NGVD 29) instead of more modern and accurate datums (e.g., NAVD 88) because it would "cost too much to fix." Why not just change the systems? Because (for the time being), the old systems still work and the political will to change them does not exist.

To quote Winston Churchill; "You can count on the Americans to do the right thing after exhausting all other possibilities."


9,144 post(s)
#30-Oct-19 09:22

I checked the file and we switch TC to NC because of computation tolerances being set too tight. We think the direction of the segment before the arc and the direction of the arc at the start are too different for the arc to be called tangent - and they *are* slightly different because floating-point math is not exact, but we should treat them as being same enough and form a TC.

We'll adjust the tolerances, this is going to be the output:




SP 1988341.7738294473 13782687.052906185

DD N65-35-0.999999564993459E 271.47000000035655

DD N72-45-0.9999997867851107E 154.22999999993885

DD N72-45-0.9999950677695324E 15.00000000016074

DD N43-28-1.0000009668272014E 67.12999999981264

TC D 95-26-2.000002332592885 A 35.000000000140815 R

TC D 47-7-1.999996700299107 A 137.56999999948562 L

DD S88-12-59.00000068547115E 123.45000000005155

TC D 154-21-56.99998805438554 A 161.64999999023084 L

DD S27-25-14.000000016869762W 810.4699999996755

DD N51-31-16.0000002345123W 252.55999999979232

DD N46-35-23.999999260968252W 192.83000000061344

DD N36-6-10.999999747328957E 195.0000000002921

DD N86-39-15.268711621306466W 163.96865069915947

We'll try to provide controls to round the distances / angles in general to clean it up a bit.

On curves, the curves in the file are right-left-left, and the same appears to be the case in both the coordinate list in the Record pane as well as in the window - even without adjusted tolerances.

One more thing. The first TC in the file is TC D 95-26-2 A 35 R. Looking into the attached TIFF, this is curve E, correct? If so, should not A be 41.04, the value in the last column? Other two curves seem to be fine.

Thanks for the report.

710 post(s)
#30-Oct-19 14:08

Thank you all for continuing on with this. Yes, my original post was full of typos from the original drawing. In my partial defense, the original drawing was hand lettered by an architect with questionable skills (drawing posted below).

Here is what the output should look like.

Note the overlap of lines at the point of beginning at the west corner of the parcel. That is par for the course here. On older drawings, and especially when curves are involved, the field notes don't close. With no curves and using modern radio GPS, the notes close within 1 inch, but otherwise, I'm thrilled if I can get a foot of discrepancy.

Here is the txt file that seemed to work to make that shape.



SP 1988341.7738294473 13782687.052906185

#eP 1988341.7738294473 13782687.052906185

DD n63-35-1e 271.47

DD n72-49-1e 154.23

DD n72-49-1e 15

DD n43-28-1e 67.13

#curve e

TC D 95-26-2 A 41.64 R

#curve f

TC D 47-7-2 A 137.57 L

DD s88-12-59e 123.49

#curve h

NC c 112 D 154-21-57 c s76-30-0e L

DD s27-25-14w 810.47

DD n51-32-16w 252.56

DD n46-36-24w 192.83

DD n36-6-11e 145

DD n49-58-59w 287

For curve h what I did was cumbersome but effective. I used the Tracker tool to measure the chord distance (112) and angle (s76-30e) across the cul de sac. Then I used those in the text. Of course then I was relying on the accuracy of the previous GIS guy whom I am trying to correct. Just for grins (ahem, Tim ;-)) here is the original detail I'm working from to plot this lot. Normally I would plot an entire block of lots in one text file, but I'm just learning this ESRI style and need to start slow, clearly.

What I would like to do is walk through the txt file copying calls from the plat and leaving placeholders for the curves. Then I would go to the curve table to fill in the curve details. The problem is for the non tangent curve, I don't see enough information in the table to plot the curve. Furthermore just looking at the table I'm not sure I could tell whether a curve was tangent or not. Often in a written description, the surveyor will include chord distance and direction. Those fit the ESRI format.

By the way, Adam, how did you copy the coordinates in the Record tab? Ctrl-c doesn't work for me on that.

Oak Hollow Lot 3 Plat.jpg
Oak Hollow Lot 3.jpg


9,144 post(s)
#30-Oct-19 14:13

By the way, Adam, how did you copy the coordinates in the Record tab? Ctrl-c doesn't work for me on that.

I just saved the file (running the code with the proto-fix for the tolerance issue) and posted what got saved.

But we'll allow copying from the coordinate list, too. :-)

Regarding the non-tangent curve H, you do need an additional angle, indeed. The lengths in the curve table in the TIFF are not enough. :-(

710 post(s)
#31-Oct-19 16:54

This ability is going to up the game when drawing neighborhoods with curved roads. Our newest subdivisions have lots of curves which were a bit of a pain to follow without a French curve tool built in. The best way to do that was to georegister a drawing and click along the curved lines.

I just checked our newest neighborhood drawings, and the chord data is given either in table form or noted inline on the drawings. The modern surveyor's field notes also include the chord data. I have spoken to a surveyor about the chord information, and he likes the old way, but the state board of surveyors is apparently insisting on chord data. Now it is possible to be automated all the way through whether it's a tangent or non tangent curve - at least on the more recent maps and deeds. I wonder if someone at ESRI could have lobbied the state to change????

236 post(s)
#02-Nov-19 19:51

Coming from a surveying background I will add a few opinions.

Depending on the age of that plat, one inch of misclosure for the traverse around the boundary is more than acceptable. Getting the adjoining properties to close this well will probably present the same problems.

It really starts to get interesting when property is valued by the square foot or square inch.

One thousandth of an acre is 43.56 square feet, or the size of a closet. Most plats that I have worked on display acreage to one hundredth of an acre.

I would have serious doubts that the subdivision was surveyed with something more capable than a theodolite and top mounted distance meter.

There is no way to tell based upon visible information what the basis bearing for the survey was, and it would not surprise me at all if the survey of the subdivision used a local coordinate system rather than a State plane system.

Carrying coordinates out to something which is immeasurable in the field will simply add to your frustration.

Input your starting coordinates to a thousandth of a foot, let the calculations take care of the rest.

Least count precision for commonly used opto-electrical measurement instruments currently available is one thousandth of a foot, or 1 millimeter, and second of angle, depending on the measurement unit in use.

Accuracy of said measurements is another matter.

GPS is another story, and given the canopy coverage of the above property, I would have a difficult time setting property pins on that property using survey grade GPS with a clear conscience without numerous redundant observations at different times of the day with different constellation geometry. Those pins would be at best within 0.10 feet of the design coordinates.

Something else to consider, the plat depicts ground distances, not grid distances, unless specifically stated on the plat. If the calculation routines incorporate scale factor for each point along the traverse, your traverse will not close. I will not add the confusion of also incorporating reduction to sea level to the mix to determine a combined factor for the calculations.

Curve calculations using radius distance and delta angle are in my opinion the simplest for most people, however the chord distance and bearing method offers several advantages, especially with regards to non-tangent curves. The curve tables I generate include all of the curve data, and this is now common.

The area above or below the chord is more easily calculated when all of the data is readily available.

In the past, curves were treated as a series of short chords within the GIS packages I used.

This introduced discrepancies in area calculations when comparing area by coordinate values generated by GIS software versus Surveying software.

This is one of the reasons why you may see Platted acreage values and GIS acreage values in the county GIS parcel data.

The P.L.S.S. (Public Land Survey System) can be truly confusing.

However at the time of its design (You can credit Thomas Jefferson) it was the best solution available, and it still works. Yes you can find significant errors in monument locations, but it gives the surveyor clues and evidence where to search.

It does not lend itself to State plane coordinate based solutions unless field work to locate existing monuments is done. I know surveyors who still will use optical instruments, and steel tapes to retrace the work of surveyors who initially set the monuments.

The B.L.M. Manual of Instructions (2009) is a required reference for those wishing to understand how public lands are, and possibly were subdivided. There are numerous versions of the Manual, and when new policies are adopted, the Manual is updated, and published. It can be very important to use the Manual which was in existence at the time of the original survey. However, for the most part, it is fairly consistent.

The gap between Land Surveying, and GIS/Mapping is getting narrower all of the time, but I do not believe that we will ever see a complete merging of the two here in the United States. Too many different types of surveying, descriptions, measurement units, and equipment used along the way to get to where we are today.

I maybe a little negative about this, but we have a long history of battling amongst ourselves.

Maybe 2022 will create a change which will help, but I have my doubts, and I hear a great deal of resistance to the proposed changes.

Just Remember, You are unique, just like everybody else!

jsperr74 post(s)
#05-Nov-19 15:44

Spot on jbgramm -- I'm going to share this with the engineers in my office who are always complaining about the GIS mapping not matching what they find in the field.

jsperr74 post(s)
#05-Nov-19 15:55

For those following along and using the forum discussions as Manifold 9 learning exercises, I offer the following notes:

The area of interest is Bandera County, Texas -98.9360 29.6465 (long / lat)

I believe the projection for the COGO drawing is EPSG 3674 -- NAD83 Texas South Central ftUS


5,994 post(s)
#08-Nov-19 02:37

SP 1988341.7738294473 13782687.052906185

I've been playing around with this to explore the wonderful world of traverses (oddly captivating once you get into it...) and have been unable to figure out what coordinate system your starting point (SP) is in. What are those coordinates?

I've tried Lat/Lon, Pseudo Mercator, EPSG 3674, and EPSG 32040 (Texas South Central State Plane).

Also, how did you determine the location of the starting point? Is there a property pin / monument there?


5,994 post(s)
#08-Nov-19 06:42

After thinking about it a bit... it's better to leave the real starting point obfuscated. I realize parcel data like owner, address, valuation, etc, is public and online in Texas (to a somewhat unsettling degree), but still... I think it's better to discuss technical examples without a direct tie to the actual parcel.

But, without saying the actual location, how did you choose the starting point? I've visited that parcel on the county's web site and also on Google, and the alignment is slightly shifted from the point you chose. I have no experience in this and am just curious what is the usual practice.

710 post(s)
#11-Nov-19 20:44

The original starting point was selected as the western point of the parcel as previously drawn. The spot was selected entirely to practice my skill at using the ESRI traverse format. To get the XY values for that point, I Alt-clicked the area of the parcel as drawn in the layer, selected the westernmost point of the parcel in the map which also marks the point in the coordinates tab, quadruple clicked on the X value to highlight, copy, and paste into the text file. Did the same process for the Y coordinate. Whether or not that is the most accurate starting point is immaterial. The final lines were shifted and slightly rotated to align with both Google Earth and with adjacent parcels. I have found that almost no surveyor lines, no matter how recent, exactly align with the Google Earth background. More often than not, a rotation of 0.5 degrees +/-, will align the two. As the Earth's magnetic field changes, it seems the surveyor's compass points move around by as much as 10 degrees since the 1850s. There is one surveyor in the county whose surveys are as much as 16 degrees out of true. I'm not sure how he does that. It's almost like he copies the data from the previous survey drawing and assumes north is up without looking for the North Arrow. That's rare but so are the survey drawings in which north is not up.

To do this in M8, I would have used the Plot Traverse add-in. Since it does not handle curve data, I would have started at the end of the cul-de-sac and marched around clockwise following all the linear traverses. When I reached the beginning of curve e, I would have backtracked two calls and proceeded around the interior area. At the end of that is another straight segment leading to the other curve in the cul-de-sac. At this point I have the end point and beginning of the cul-de-sac. Then I shift to the layer with the parcel areas in it to draw the chord across. Since I have the curve data from the drawing, I would use the chord across the cul-de-sac to place the appropriately sized circle into another layer such that it touches both sides of the chord, and used the Clip with subtract transform to create the curve around the cul-de-sac. Curves e and f would have been done the same way. Knowing the radius of e and f I can slide a circle up to the point of tangency, copy and paste that circle into my active parcels layer, select the circle and the real parcel, give them both the same parcel number, and then use the Union transform to create the perfect curve around e to f. For curve f I would have drawn the chord across from the tangent end of curve e to the corner point along the road. Then used the circle in another layer and Clip with subtract transform across the chord. Fortunately going through this process is not an every day thing, but it is an every week thing.

The video is great. The comment about handwriting is exactly correct, especially in the case of this surveyor. I initially misread several of the calls in his drawing. You may call it fun and easy to do, but it's sometimes tedious to get it right. In the rare event when the new line does not fit with Earth or the adjacent parcels, troubleshooting starts with getting the text file correct according to the source data. Sometimes I find that a distance or direction must be corrected to make the lines close. When that happens, I annotate the text file to show what I changed from the source.

oddly captivating once you get into it...)

After a few tens of thousands of them, the charm wears off.


5,994 post(s)
#12-Nov-19 05:39

To get the XY values for that point,

For future reference, a quick way to do this is to use the tracker tool. Launch the tracker and click on the point of interest. Next, right click and choose Copy Location (Projected). That copies the X, Y values in the projected coordinate system into the clipboard. You can then paste them directly into the traverse file (they are in the right order as copied).

jsperr74 post(s)
#09-Nov-19 20:27

Deleted my own post -- answered in the new video.


5,994 post(s)
#08-Nov-19 13:26

Couldn't resist... this was so much fun and so easy to do, it just had to be a new video. Thanks for contributing a great example!


611 post(s)
#13-Nov-19 00:20


1) where is the official documentation url about the meaning and howto use all the the reserved word to create the traverse text content find in *.txt files ? the manifold doc speak about " industry-standard ESRI traverse files" so i think the syntax has create been first create by ESRI. Does is the officical documentation link ? or does traverse is part of international or national standard ? like ?

2) Does bezier curve is supported in traverse content ?

3)Does COGO tool and traverse is the "same" ?

4) Does an SQL manifold function convert manifold geom to traverse text syntax ? ( how is define the start point ? begin of wkt = geom )

It make me think a lot how to code Flash (actionscript) or SVG path . I study a lot SVG ( Upper =ABSOLUTE , lower=relative coordinate) and documentation specification is locate at less actionscript .

with some time i think will have the answer .... if i dig a little ..Myself

really like the video that avoid me to test by myself. I learn every day new things ...great



5,994 post(s)
#13-Nov-19 06:41

where is the official documentation url about the meaning and howto use all the the reserved word to create the traverse text content find in *.txt files

See the Record pane topic where traverses are discussed. That discussion includes links to ESRI pages.

) Does bezier curve is supported in traverse content ?

ESRI traverse format supports only circle arcs, not ellipse arcs or spline arcs.

3)Does COGO tool and traverse is the "same" ?

I think so, but that's a question for ESRI. :-) In different ESRI products they appear to have used different words for the same thing over the years.

Does an SQL manifold function convert manifold geom to traverse text syntax ?

I don't see anything like that so far in recent builds (might have missed something... lot to unpack). I suppose a function like that might be useful for programmatic creation / export of ESRI traverse files from Manifold objects.


611 post(s)
#13-Nov-19 23:08

thank's a lot

the ( new/ update ! ) record chapter contain a lot of informations !!!


Manifold User Community Use Agreement Copyright (C) 2007-2019 Manifold Software Limited. All rights reserved.