9.0.176.1

manifold-9.0.176.1-x64.zip

SHA256: 4712f83b225deaeab9802588cbc10f3a42fed581b42f4b2ea8da44dfb5c5a092

manifold-viewer-9.0.176.1-x64.zip

SHA256: afb2481fd5da30bd300dd80feba8d16ebf0705fcfdf8b0c83fe41f492f8bc9d8

sql4arc-9.0.176.1-x64.zip

SHA256: 05e205ffcbf3fb8d49195e77610cca3455204d2f2be5b2da1bce200f011c6363

(We are back from winter holidays! Big plans!)

Changes

The Layers pane allows showing and editing scale limits (zoom ranges) for map layers using the new commands: Show Farthest (Max) Scale / Show Closest (Min) Scale. The map window honors layer scale limits: layers whose limits do not include the current window scale are hidden and do not participate in interactive operations -- editing / picking / selecting / snapping.

(The layout window does not currently honor layer scale limits neither on screen nor during printing. Both these things are coming in the next build.)

The Layers pane shortens the display of max / min scales for map layers to: 1:xx / 1:xxk / 1:xxm / 1:xxb -- and then 1:xxe+xx for very large values -- for readability.

Exporting data to a GDB automatically truncates text values to the maximum allowed length.

(Regarding limits on the size of text values. In Manifold 9, the maximum size of text values is 2 GB. This is a pretty big value that is nearly never reached in practice. Many other data sources, however, have much stricter limits, so there is a question of what to do when we have to write text values to such a data source and some of the values are over the limit. After discussions, we settled on the following rules: (a) attempting to set an overly long value during an interactive edit should fail and complain that the value is too long, (b) attempting to set an overly long value using INSERT or UPDATE in a query, or their equivalents in a script should also fail and complain that the value is too long, however, (c) attempting to export data with one or more values above the limit should not fail and should automatically truncate the values to the maximum allowed length. The rationale for export behaving differently from other writes is that if we make the export also fail and complain, the very next steps performed by the user will quite likely be reducing the length of text values *in the original data* just so that they are under the limit imposed by the data source they want to export to. It feels much better to just let the export trim text values as needed as they are being written, while keeping the original data intact.)

Exporting data to a GDB that resulted in the truncation of text values reports the names of fields containing truncated values as well as the total number of truncated values in the log.

Exporting data to a SHP automatically truncates text values to the maximum allowed length and reports truncations in the log.

Exporting data to a DBF automatically truncates text values to the maximum allowed length and reports truncations in the log.

Exporting data to a KML / KMZ exports values of fields for drawing records as allowed by KML 2.2. Binary fields (geoms / tiles / varbinary) are not exported. Name / Description fields are no longer special-cased and are exported as regular fields.

Exporting data to a KML / KMZ exports labels bound to an area as bound to a point located in the inner centroid of the area, labels bound to a line as bound to a point in the middle of the line (half-length through the line), and labels bound to a multipoint as bound to the first point of the multipoint, to let Google products show such labels.

Reading data from a KML / KMZ reads field values.

End of list.

<Disregard> I am having some trouble finding the zoom scale settings in the Layer pane. How is the command executed?

Found it by Layers pane / Filter button.

Excellent!! I can now make a few derived layers for major/minor contour lines and zoom away!

Next question. Is this associated with that one instance with the layer or is this component-wide setting? i.e. does the constrained layer in a different map have to reset the values? (a la Opacity)

-Oeaulong.

Next question. Is this associated with that one instance with the layer or is this component-wide setting? i.e. does the constrained layer in a different map have to reset the values? (a la Opacity)

Just tried it to see (took 15 seconds to create a map with the same layers to see...) and those settings are per map. That makes sense, as the same components might be used in many different maps. If you want to recycle the settings used in a map, just copy the map and start with the copy.

Note also that the settings are just JSON text in the properties of a map, for example:

{ "Entity": "[pois]", "ScaleMax": 15000, "Z": 3 }

You can recycle them by just copying and pasting the "ScaleMax": 18000, part of the property for that item from the Properties dialog for the map.

Thank you Dimitri.

Both view ranges and kml related additions are very nice!

Just something about zoom ranges. Would it be maybe useful for them to be also associated to folder and not only to drawing/label/image components? So that folder ranges would optionally control individual component range. As I am thinking it: There would be a folder range and a component range. Each component would have as a range "any"/its own specific, or "by folder".

Maybe there would be something I ignore, so, is there some reason for not implementing that functionality?

Zoom ranges on folders is a good idea. I wish I'd thought of it!

You could just have the folder zoom range take priority over a component's zoom range, for any layers within the folder.

is there some reason for not implementing that functionality?

Nothing that I can think of, other than where such a thing fits as a priority with about 30,000 other good ideas, or whether it might fit into an unused engineering slot. :-) Make sure to suggest it!

Allowing to put scale limits onto a folder and applying these limits recursively could work, sure. But then again, the same is true for opacity, it can be combined as well. Or for pick / snap restrictions. We haven't been putting any of these things onto folders because we were not sure how many of them would make sense to put - so far it looks like everything we are adding makes sense for folders just as well as it does for layers, so maybe we should allow folders to have everything.

by mentioning the multiplicity of possibilities for activating such a principle of inheritance of folder properties to be applied to Adam's layers highlights, in my opinion, the apparent interest of such a principle and its ultimately limited utility.

Indeed, everything depends on the use made of folders. Firstly, folders could be used to arrange layers by theme (water, roads, etc.) but since the order of the layers in the folders and of the folders themselves directly impacts the map it is useless as elements of the same theme appear at different levels in the layers. You can sort by transparency but again the order implied by the folders undermines this.

In summary, as long as the folders are associated with the layer order, any other functionality (transparency, zoom, etc.) of the folders will rarely be useful in my experience.

But I would love to be wrong because philosophically the folder approach is interesting.

Agreed. Generally, the more flexibility we are given the better, but I'm not seeing many practical uses for this right away. On the other hand, there probably are some.

Really appreciate the export changes and the scale limits. Thanks for these! Render zoom (as in ver. 8) would be good too but perhaps is being planned for a future update of the Style pane.

BTW I love the new search function on the homepage of the online manual.

I would love it even more, if the box would be filled the the selection in an active query builder when called from manifold menu ... and if the same function could be added to the API automatically filled with the selection in a script. That would be perfect to include the documentation of the chosen language in this search.

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