9.0.180.4

manifold-9.0.180.4.zip

SHA256: eeb8ba59114023f95ae91120a1d27ab6d708a6e14d5ab96906782b84f9f61ee6

manifold-viewer-9.0.180.4.zip

SHA256: 77d3772058b96cbeae640482993b0a531c618a8ed2cab5a057f881afb016689c

sql4arc-9.0.180.4.zip

SHA256: 7633e4dbce46f4aec89494e3a57793d5c0e42a9f8284aa63df2b66b7a627ae81

Changes

The HTTP server supports the new -urlbase:xxx command-line option to specify URL base. The default is '/'. The option is useful when the HTTP server is used together with a general-purpose web server.

(Fix) Zooming using the cursor in the Javascript control disables panning until zooming finishes.

Zooming using the cursor in the Javascript control zooms around the location under the initial cursor position, similarly to how this is done in the map window.

New HTTP endpoint:

• /version - returns server version + server start date and time in plain text.

(Fix) Exporting DBF / SHP no longer fails on large negative integer values (-1 billion or lower).

(Fix) Reading vector data using GDAL no longer sometimes misapplies the rectangle in the spatial filter if it is specified (happens when showing data coming from a live GDAL data source on a map).

The GDAL dataport supports GDAL 3.4.x.

The GDAL dataport supports GDAL 3.5.x and 64-bit raster data.

The GDAL dataport supports GDAL 3.6.x.

The GDAL dataport supports GDAL 3.7.x and signed 8-bit raster data. (GDAL 3.7.x also allows reading raster geodatabases, which cannot be read using the regular GDB dataport which relies on the ESRI FileGDB SDK.)

The GeomNormalize / GeomToShapes / GeomToShapesEsri query functions keep Z values instead of discarding them.

Exporting areas with Z values to SHP no longer discards Z values.

(Fix) Exporting areas with Z values to GDB no longer fails.

End of list.

The GeomNormalize / GeomToShapes / GeomToShapesEsri query functions keep Z values instead of discarding them.

That’s a bit huge. Does it mean that normalization also tests for and resolves negligible differences in the Z axis? Or only that it still ignores but now preserves existing values? (Yes I could test rather than ask, lazy old me.)

Z values are not used to tell whether the points coincide / lines intersect or not, if that's what you mean. Because the output of the functions still has to be XY-correct, not XYZ-correct so to speak (some XYZ-correct geometry might not be XY-correct, XY-correctness is a stricter criteria). When there are Z conflicts, eg, when there are two points with the same XY but different Z, after normalization that XY location will pick one of the available Zs and discard the other.

That is what I mean, thank you yes.

I will think about the statement in parenthesis--I don't think I quite understand it yet (or whether I agree).

The position stated in the last sentence is going to cause foreseeable problems--to the extent that to me it seems misguided and wrong both in principle and in practice. I hope it can be reconsidered.

Think of a drawing depicting a pipe network, a road network, an electricity distribution network, for that matter a silicon wafer.

In any of those cases (and others) it is perfectly legitimate (and not very rare) for two nodes to exactly coincide in the XY plane (within epsilon), while carrying different Z values (different heights).

Collapsing those Z values would be a degradation or destruction of valid user data.

User data is the user's business. It is not for Manifold to destroy or corrupt it in the name of supposed purity.

We agree, of course, that if everything is fully 3d, then there might be locations with the same XY and different Z even within the same geometry object (a road crosses itself at a different height level, for example). But we are not trying to be fully 3d just yet.

We have been solving a simpler task - given 3d geometry, how do we export it to formats that require some of the geometry to be normalized in terms of XY. Specifically, when we are exporting to ESRI formats such as SHP or GDB, areas have to be normalized in terms of XY - and that normalization has to follow ESRI's rules, not OGC rules - else other products might reject the geometry. Given an area with Zs, we were facing an unpleasant choice - (a) discard Zs and normalize the area, losing data, or (b) export the area without normalization and risk it not being read at all. The change allows us to do (c) normalize the area without Zs, losing different Zs at the same XY locations - which we think is better than either (a) or (b). Over time this can be improved further.

Is there a difference between (a) and (c)? Does one offer more options for future development? Or does one option close the door on future developments?

In any case, there is no excellent choice. Seems like you need to decide and move on.

Many decades ago I had a software project going and one option seemed like the right one. Later other users wanted to bring their hardware in to our project. After fussing with it for a couple years, it became clear that we should have gone the other way even as it seemed like a waste of time to get that picky for one hardware application.

There is a difference between (a) and (c), yes - in practice (c) very rarely loses anything. If and when we go full 3d, we can change (c) to a true 3d normalization (which would quite likely involve 3d tesselation) and export the results to GDB / SHP with a warning that such areas might be rejected by non-3d clients.