9.0.172.6

Here is a new build.

manifold-9.0.172.6-x64.zip

SHA256: e0d5cbe5fbf4f104a96dbcde4271e67c0857c655c0bb678167e3dcc449cc7939

manifold-viewer-9.0.172.6-x64.zip

SHA256: 8742e05807fadd464232739fafa5411b51e2db5229fb0180e924341806397719

This build is the first in the two-build series with the new preview feature for Select and Transform panes that we have been working on for so long. It contains the core of the feature (changes to panes, separate query generation paths for the preview queries, new supporting machinery in the query engine for the preview queries) and allows using previews in a table window. The second build in the series is going to be released next week and will allow using previews in a map window.

Next builds: preview #2 -> public -> registration / vector editing series.

Preview

The Select and Transform panes include the Preview button which shows the preview of the operation. In the current build, previews are limited to a table window, the next build will allow using previews in a map window.

The preview for a transform operation in a table window shows a virtual preview field on top of the regular fields. The name of the preview field is set to the name of the transform template. The preview values are computed dynamically as you scroll the table. The preview field cannot be scrolled out and is always visible.

The preview for a select operation in a table window shows a virtual preview field on top of the regular fields, but reduces the preview field to its caption. The values in the preview field as not shown directly as 'true' / 'false' and instead change the background color of the records: white = the record is currently unselected and will stay unselected, red = the record is currently selected and will become unselected, blue = the record is currently unselected and will become selected, red-blue = the record is currently selected and will stay selected, gray = the selection value is being computed. The name of the preview field is set to the name of the select template. The preview values are computed dynamically as you scroll the table.

The preview field can be hidden using the Hide Preview command in the context menu.

The preview field for a transform can be temporarily collapsed to its caption or expanded back to caption and values using the Values command in the context menu (works as a toggle), or by clicking on the arrow icon on the right side of the caption.

The preview field can be resized by dragging either of the borders. Dragging the border of a preview field snaps it to a border between regular fields, with some tolerance.

The preview field can be dragged around using either the caption or the body with the values. Dropping the preview field onto a regular field makes the preview field start at the left border of the target field. Dropping the preview field close to the right border of the last shown field makes the preview field start at that border.

The preview for a transform operation that puts the result into an existing field indicates that field in a table window using a bullet icon.

The preview for a transform operation that produces geometry / tile / binary values in a table window reduces the preview field to its caption and shows a tooltip reporting that the preview is unavailable. (Operations that produce geometry or tile values should be previewed in a map window. Operations that produce binary values will not be previewed because checking whether a particular binary value is the one you wanted to produce is impractical without highly specialized UI.)

Previewing the result of a select or transform operation and then changing the parameters for the operation in the relevant pane does not update the preview automatically. To update the preview, click the Preview button again. Previews for select and transform operations override each other. Performing a select or transform operation removes the preview from the active window.

Switching between windows does not remove previews. (It is possible to have multiple previews in multiple different windows shown simultaneously.)

Other

Renamed transform parameters: 'cuts' -> 'parts', 'Cut with:' -> 'Split with:', 'Cut with selection only' -> 'Split with selection only', 'coordinates with step' -> 'line coordinates'.

Renamed query function: GeomToCuts -> GeomToParts.

Renamed query functions: GeomSplitToConvex / Par -> GeomToConvex / Par.

New query function: GeomPartLine - computes part of the line between two specified distances. If the begin distance is larger than the end distance, the returned part goes in the direction opposite to that of the line.

New query function: GeomToPartsLineSequence - splits the line into parts between specified distances. If the begin distance is larger than the end distance, the returned parts go in the direction opposite to that of the line. The result table includes minimum and maximum distance for each part.

The Split transform template for geometry values allows splitting lines into 'line parts'.

The rules for world file extensions are changed to: (a) take the original extension and add W, (b) take the first letter, take the last letter and add W, for compatibility with other products.

The Reshape transform template for geometry values rotates geometry values clockwise. (The GeomRotate query function keeps rotating geometry values counterclockwise, the template merely changes the sign of the parameter value.)

The Copy transform template for geometry values support copying 'rectangle' to an x4 field.

The ArcGIS REST dataport supports ArcGIS servers with vector data. Downloaded vector data can be cached in the parent data source via the 'Save cached data between sessions' option.

(Example server that powers the dashboard for COVID-19 data from JHU: https://services1.arcgis.com/0MSEUqKaxRlEPj5g/arcgis/rest/services/ncov_cases/FeatureServer )

The GDB dataport attaches EPSG codes to coordinate systems with equivalent WKID codes, to allow using grid-based and other EPSG coordinate transforms when re-projecting components with these systems.

The WMS dataport detects server errors that aren't flagged as errors and reports them in the log window.

The WMS dataport performs additional filtering of layer coordinate systems to better work with servers that report unsupported coordinate systems in bounding box data.

Dataports for SQL Server / Oracle / DB2 / MDB wrap batch insert, batch delete and batch update operations into transactions for robustness and performance. (Dataports for other databases were already doing this, the change completes the feature for all dataports for databases.)

Dataports for all databases automatically break big transactions for batch operations into manageable portions. (Without this, most databases just fail with an overflow error after the amount of data about to be committed exceeds a certain limit. The limit is frequently not a terribly big one either, in the range of 15-20,000 records or 50-100 MB of record data, far too low for GIS.)

The SQL Server dataport supports the newest ODBC driver for SQL Server available from Microsoft (v17). (In particular, the dataport recognizes custom types for geometry / geography / XML fields reported by the driver.)

The MDB dataport automatically corrects names of newly inserted tables to fit into the limits imposed by MDB (no leading spaces, no double quotations, no periods, etc).

(Fix) Computing viewsheds for all observers (visible area from all / visible level from all) no longer sometimes fails to handle tiles without observers.

End of list.

There was a little hiccup with the preview #2 build, it will come out later this week.

Any update?

What is the worst thing that can happen?

After a hiccup? .

How soon?

Patience, friends, patience.

I've been working with alpha test versions and I have to say that as much as I like lots of regular builds, there's no replacing what you get in the way of total quality, convenience, reliable workflow, and insight that come from deeply worked, totally fast and smooth interfaces.

Based on magical things like yesterday's alpha build, I think the time invested has been worth every minute, both for immediate results and to support steadily increasing wonderfulness throughout 2021.

See what comes out later this week, and then decide on the pluses and minuses.

Could you give us an idea when the next public build might be released?

Just did. :-)

<edit>

Repeated Dimitri's words

I imagine ranger.sean was not asking about the next Cutting Edge build (public, yes) but about the next Public (or installable) build. Adam had given a couple of statements about that, but they might be périmées.

So, 9.0.173.0, using usual convention.

Yep, as per Tim's post my question was about timing for the next stable release.

The guidance provided by Adam with the 172.6 cutting edge build indicated that a public build would follow.

Apologies if I misunderstood Adam's post or confused matters by using the wrong term.

No need for apologies of any kind, as this is a forum for asking questions in situations that presumably lack clarity.

Using accepted terminology helps clarity, so we should review what that is to be all on the same page:

From the Product Downloads page and the Installations topic, Manifold has two types of builds: Cutting Edge and Official. If you want specifically to differentiate between those, use those terms. If you ask using other terms, like "stable" and "public" that's not differentiating between the two.

Because both Cutting Edge builds and Official builds are "stable," asking about the next stable build is just asking about whatever will be the next build. Cutting Edge builds have bug fixes that the last Official build does not have, so "stable" doesn't mean "Official" only.

It's a similar deal with "public" applying to both as well. It's not a special term like "Cutting Edge" or "Official." It's just a plain word with the usual English meaning, as something issued for anybody, that is, the general public, to download.

That's in contrast to a build not available to the general public, for example, an internal engineering build, a special test build sent out to somebody who has reported a bug, or an alpha build distributed to a limited number of testers.

One more thing: keep in mind the forum is a place for informal discussions between users. It's good we get informal guidance from adamw from time to time, but the way to get more of that is encouraging relaxed communication without him having to weigh every word. Take what he posts and run with that, letting each new build speak for itself.

Pluses: software that worked well on Monday continues to shine on Friday.

Minuses:

• The forum looks almost dead.
• Manifold has recently lost credibility.

None of us wants these things. What can we do to reverse direction?

eh?

Manifold is absolutely kicking ass as far as I'm concerned, 10+ years go they said "we got parallel", on the back of "we already have 64-bit (when it was out, like day 1)", and along they way they said "real parallel is f hard, and no one barely can do it ...".

What Manifold says is accurate. What credibility is lost? They get shit-talk in various high profile communities, but I've learnt to (not ignore) just take with a grain of salt what those crowds say. Anyone who doesn't actually investigate $95 software, I treat them always with suspicion (or extreme care when it's obviously needed some folks don't have 95 dollars ... etc).

Manifold built a database engine very much of its era, and now they've come back to play and build a spatial thingy - what's the credibility problem?

https://github.com/mdsumner

Manifold is indeed doing excellent work. I'm a big fan. The shortcomings are sometimes getting predictions about future capabilities off by many times over and the software is missing basic GIS tools. Perhaps both will be addressed if they can start having multiple improvement fronts going at once as Adam suggested will happen after they get through the preview effort.

that's just software haha ask when it'll be ready, double it, double it again ... then wait

https://github.com/mdsumner

As far as I'm concerned I'm not yet up-to-date with my translation of the last build. Playing around with the API we have now makes for an instructive waiting.

Politics is the art of making the impossible unavoidable

The last update was more UI change than feature addition. That means unlearning the old way and learning the new. Nobody wants that, but we did sign up to help out with a product in development. Changing the UI in beta is better than the ESRI approach of changing the production UI simply for the sake of reselling a perfectly fine product to existing customers who now need more courses and trips to Redlands.

I think the addition of features, and the associated video demo, tends to generate more forum discussion as the realization of what the Radian machine can do becomes more apparent.

As Mike mentions, people who won't spend the $95 to learn what they're talking about don't deserve much attention. I have similar things to say about another hobby I'm involved in. Spend fifty cents, one time, to try the new way that works every time, or continue to spend $75 per year and get poor results. They would rather declare the new way to be frivolous. It's about marketing. ESRI has thousands of foot soldier sales associates knocking on doors.

Hard to know where to reply here, but to all of you...

I respect your opinions more than my own, and as always am pleased to be wrong.

After the 172.7 release I am certainly not worried about the product or its future. The wait got long, but there it all is (more to say in other threads). Dimitri was absolutely right in his encouragement. The Preview feature set is in effect a totally new, orthogonal pipeline, combining UI and data supply in a way that I had never seen (although no doubt I don’t get out as much as I should).

I am a bit worried about the vital signs of the forum. They have not been great for a while.

As well as the natural momentum that will follow on this release, can we perhaps make an effort to share more of what we actually do with 9, and to ask peer-level questions? I think we should. I have done badly at this lately (mainly for non-Manifold reasons). I will try hard to take my hint.

On a personal note, in a country so strongly tied to ESRI/ArcGIS procedures and extensions (and its vendors), more than 15 years ago, Manifold was indeed a bean of light that enabled me to pursue my goals while offering a very compelling and efficient way of doing things. After so much time working with M8 I got used to a powerful set of tools within a UI that answered almost all my GIS needs and tasks.

Like dchall8 noted, learning and getting used to the new UI takes time and of course I'd be thrilled to have all the M8 capabilities available in M9 quickly, but, ultimatelly, brilliance comes at a cost and the latest builds have always justified the wait. My experience with M9, and specially the latest builds, is that the speed and power of this software are unparalleled (no pun intended) and both the manual and the forum work as an endless source of help and clarification. I'd like to definitely see a more active forum, but based in my own experience I completely understand that keeping a regular participation is sometimes hard. On this note, I really comend Tim's effort as well as all of the other frequent participants in this forum. In a few struggles to get the job done, I can remember the time when in one way or another way, one of your posts guided me in the right way. I thank you all for that.

For now, Like Klaus, I'm still getting used to all the updates (and changes regarding "designations" of similar operations over the previous builds) to make a new portuguese translation available.

After playing around with the latest build (9.0.172.7), the preview worked like nothing I experienced before in GIS. Stoked to see what lies ahead!