9.0.175.2

manifold-9.0.175.2-x64.zip

SHA256: 53b9694c16666f48d272fc2b99fcf53f8c874f283e18e8cf8e73a4cc651a7ad4

manifold-viewer-9.0.175.2-x64.zip

SHA256: 5edfa8acc594994499c9bc51301ea1e03aaddda959d71ea53cfb2d303848fe18

sql4arc-9.0.175.2-x64.zip

SHA256: 33fab154254e8097482fbaf13e9e376419b4e9057ea0806cd022fce73dd62e55

The new build for 9 contains improvements for vector editing and various fixes and improvements for dataports.

Changes

(Fix) Loading a malformed traverse file rejects a circle arc with no previous coordinates instead of producing garbage.

The Info pane allows editing traverse coordinates for vector values in the Coordinates tab. Editing a traverse coordinate repositions all further coordinates in the branch that contains it. Editing the first coordinate of a closed area branch alters both the first and last coordinates of that branch. Editing the last coordinate of a closed area branch does nothing. Edited angles and distances are accepted in the same format that they are displayed.

Editing a traverse coordinate in the Coordinates tab in the Info pane automatically converts between segment types: straight segment / circle arc / ellipse arc / spline arc is converted to straight segment / circle arc depending on the entered traverse command.

Editing a traverse coordinate keeps the insert coordinate if it belongs to a different branch. If the insert coordinate belongs to the edited branch, it is kept only if the branch is opened and the insert coordinate is at the end of it -- this allows entering new coordinates and quickly adjusting the traverse commands generated for them without having to switch modes.

The map window supports a new command for editing lines and areas: End Current Branch + Close Gap. The command attempts to close the current branch using the compass rule and then ends it. If the branch contains less than 4 coordinates, the gap is not closed. Curved segments are adjusted using approximate lengths.

The Info pane allows copying field names from the list in the Values tab.

The Info pane allows copying XYZ values and traverse commands from the list in the Coordinates tab.

The Info pane allows copying the contents of the list in the Coordinates tab using: Copy Coordinate List

The ArcGIS REST dataport set to use cache compresses stored IDs of vector objects (which can take quite a bit of space).

The ArcGIS REST dataport provides record counts for tables.

(Fix) Using a web image or a similar dataport with cache database other than a MAP file no longer sometimes leaks memory.

The GDAL dataport supports GDAL 3.1.x and 3.3.x.

The cache for web images supports tables with multiple tile fields, eg, for ECWP.

(Fix) Rendering SID data no longer sometimes produces black pixels in areas close to the image boundary.

(Fix) Rendering JPEG2000 data no longer sometimes produces black pixels in random locations (occurs only on specific zoom levels).

The ERDAS dataport now parses datum for coordinate systems marked as 'LOCAL'.

The GDAL / JPEG2000 / ECW / SID dataports check channel descriptions for a 4-channel image and set the image to either RGB or RGBA (was previously always set to RGBA).

(Fix) The ECW dataport no longer misreads transparency data. (A long-standing issue that made us originally switch to SID for JPEG2000 data.)

The JPEG2000 dataport parses coordinate system data stored as EPSG codes.

End of list.

The map window supports a new command for editing lines and areas: End Current Branch + Close Gap. The command attempts to close the current branch using the compass rule and then ends it.

What does the 'compass rule' ?

Do you really want to ruin economy only to save the planet?

The new command is for closing lines or areas in the context of drawing traverses. Suppose you're drawing a traverse that is the boundary of a parcel. Since it is a parcel, you know that the border of it must connect to the very beginning.

A common situation is that you faithfully follow instructions to draw the boundary, starting at a given point and proceeding in a given direction for the specified distance, then in a new direction for a specified distance and so on until you get to the end, where the end point does not coincide with the beginning.

Simply adjusting the last segment is assuming all errors were in the last segment. But that's not usually a real life situation, where small errors in measuring angles and distances were randomly distributed through all the prior segments.

The "compass rule" is a way to adjust all prior segments as well as the last segment so that slight changes are distributed through all the segments in order to close the figure.

It's a sophisticated rule, no simple matter to implement, and that it goes back to the 18th or 19th century shows the mathematical sophistication back then. See, for example, https://www.jerrymahun.com/index.php/home/open-access/topic-trav-comps/44-travcomps-chap-e?showall=1 and https://sites.google.com/site/civilengineeringwebsite/what-we-believe

Dimitri explained, but just to recap what this is about shortly: when you have a description of the boundary for a piece of land like "start at such and such lat/lon, face North, go 100 m, turn 30 degrees East, go 150 m, ..." (which is what the traverse is), after you go through all these instructions, the boundary frequently does not close exactly. The compass rule provides a way to close it, moving the end coordinate that you arrived at after the instructions to the start coordinate so that all other coordinates move as well with the shape of the boundary holding as close to the one in the description as possible.

Thx for the explanation to both of you. A very usefull command.

Do you really want to ruin economy only to save the planet?

Thanks so much for these changes! Being one of the agitators for editing traverses it is much appreciated. I won't have a chance to use it until later next week, but was able to try it for a few minutes before heading out the door.

It would be nice if traverses could be the default instead of coordinates. Perhaps have the last used option become the new default. Also, looks like in order to draw a new coordinate, we have add a dummy vertex on the map and then edit it in the info pane. It would be nice to just enter new data directly in the info pane and watch it draw on the map.

The compass rule closure is a big help.

Question regarding grid (projection) to ground conversion. Typically we will be entering distances and angles for utilities and property lines that were measured on the ground. When placed into the projection without adjustments error is introduced. We can use the transform to scale and rotate, although it would be nice to enter those values first and have them apply while entering the distances and angles. Question is what about the Vincenty algorithm used by the Path tool? If that was applied to the entering of distance and angles would it be a relatively accurate means to adjust for the projection without having to know the scale factor and rotation angle for a particular location in the particular projection being used?

I have not been much help to you, Mike. Before I retired I was doing about 6 traverses a day still using M8, so I would have seen the issues and helped you get this done.

I have also seen metes and bounds descriptions that did not close by more than a mile. Usually I was able to figure out a typo that fixed the problem, but sometimes the surveyors just forgot to write down the calls.

We will allow entering a traverse command for a new (insert) coordinate and we will remember the last used mode for the Coordinates tab of the Info pane for the duration of the session.

Regarding adjusting entered numbers - if you have traverses plus scaling coefficients, you can put scaling coefficients into the projection and enter traverses exactly as they are provided. Then, after you go through all your traverses, you can change the projection of the drawing to get rid of the scaling coefficients. I suppose we could use Vincenty's formulae to auto-adjust for such scaling on the fly (ie, you'd supply a measurement unit for distances effectively saying "by the way, my distances are in meters, so whenever I say DD xx 100, that's 100 meters away, so place the next coordinate in such a place that the distance from its lat/lon to the current lat/lon computed by Vincenty's formulae is 100 meters"), but that would likely be much less accurate than scaling to the constant factors. Because errors for different segments will drift a little.

Thanks for the possible workaround but it doesn't help with adjusting angles and it isn't as accurate as you said. Attached is a map file that contains a clipped version of grid of points with pre-calculated scale and rotation factors for my area of locale. This was created by reading up on the projection and applying formulas to the points. I pick a point close to where I'm doing a traverse and apply the adjustments to the drawing after it is finished using the transform pane.

Using the Path tool on the 1000 ft line I drew in the map project , we can see the scale and rotation error introduced by the projection vs drawing that line on the ground. The Vincenty algorithm seems to scale nicely for the projection but doesn't help with scale needed for elevation. The rotation angle isn't accurate and no idea why.

ESRI has a box for scale and rotation factors that then apply to the traverse as it is being drawn. That is a good solution, I think. However, the total solution should allow a way to label ground distance as they were entered without the adjustments for the projection. ESRI does that by converting each segment of the traverse to a record with fields storing the info. This maybe the right solution, but the best would allow no loss of info so that the effort of entering the traverse isn't lost while allowing labeling ground distances.

Thanks for your interest in this.

Attachments:
Vincenty vs Projection factors.mxb

Mike, are the grid points used as a point of beginning monument for the traverse with the surveyor defining the offset to the location of the beginning of the subject property?

In my part of Texas there are monuments in the ground, but they are rarely referred to. I suspect that is because they move around with the shifting sands, but it seems easier to pick a spot nearby the property and start from there. Usually the starting point is the concreted steel pin commonly used as the common corner between the subject property and the adjacent property. That depends on the county and the age of the survey, as you know. Older ones might start at the dead oak tree marked with a V.

As for closing the last point, if it doesn't close by a mile, then it makes a difference. If it doesn't close by inches, feet, or a couple tens of feet, I'm not that concerned. If I saw an error which would affect a neighboring property, I would bring it to the attention of the surveyor and get clarification. In any case it was not my responsibility to force close the field notes from a surveyor. My job was to inform "my" appraisers of the boundaries so they could determine which building improvements sat on which parcels. Thankfully it was very easy to overlay the county parcel map onto Google Earth and show the appraisers what to look for.

Appreciate your perspective and thoughts on this. The grid points are simply a way for me to pre-calculate a relatively appropriate scale factor and rotation angle for the Colorado Central State Plane projection so that the ground distances supplied by the surveyor are not badly distorted by the projection. Basically I found the formulas for the rotation angle and scale factors from literature on the projection, created a grid of points, and then used the formulas to calculate the values based on the lat/long of each grid point. So I just use the values from the closest grid point the traverse I'm working with.

Not being a surveyor, I just want a way to get relatively close with minimal effort. Wish we had some surveyors active on the forum right now

Hi Adam, while inadvertently linking an ecw file with the save cache turned on I came across a behavior in cutting edge 175.2 (that persists in 175.3) that I didn't notice before. After linking the file and trying to open it the table seems to be caching the file but the image is blank.

After repeating the same procedure (linking the same ecw file with save cache turned on) with Manifold 175.0 and cutting edge 175.1 the file opens normally. Usually, I don't link ecw files with the save cache turned on but I believe this might be worth mentioning here. Is this an expected behavior?