9.0.172.5

Here is a new build.

manifold-9.0.172.5-x64.zip

SHA256: bade7c98522df4ba422c838e66e854ecb73305f51cef032697565a7adce97774

manifold-viewer-9.0.172.5-x64.zip

SHA256: b9f9e04d54e92f81a9b36846d51188ef338c0fe9ab686c514f2503cd40ffa935

Select Templates

(Geometry fields) Search - supports a new part: radius = the radius of the minimum enclosing circle, useful for ranking geometry values by size.

(Text field) Search - supports new parts: url scheme / url host / url port / url user / url password / url path / url extra parts.

Transform Templates

(Geometry fields) Overlay - performs a topology overlay on a pair of drawings: identity / intersect / union / update. The result drawing includes fields from the source drawing (with same names) as well as fields from the overlay drawing (with names altered according to the specified pattern, by default 'Overlay {name}'). Both drawings can be restricted to the selection.

(Tile fields) Viewshed - computes viewsheds: visible area from all / visible area from any / visible count / visible level from all / visible level from any. Z values for view sources can be taken from a numeric field or directly from geometry values (the default). If Z values are taken from a numeric field, they can be counted relative to the raster (on by default). There are options to specify refraction (the default is 0.13), minimum / maximum angle (the defaults are -90 / 90, angles are always in degrees), radius (the default is 0 = no limit), and whether or not to use datum curvature (the default is not to use). View sources can be restricted to the selection.

(Geometry fields) Split - supports a new split into operation: cuts = splits geometry values into parts using areas or lines in a different drawing. Both drawings can be restricted to the selection.

(Geometry fields) Copy - supports a new part: radius = the radius of the minimum enclosing circle, useful for ranking geometry values by size.

(Geometry fields) Compose - composes a geometry value: point / point with z / circle / rectangle / segment / triangle.

(Date fields) Compose - composes a date value from year / month / day.

(Date fields) Arithmetic - performs an arithmetic operation: add time / subtract time / time after / time before. Add time / subtract time add the specified amount of time units (day / week / hour / minute / second / millisecond) to the original date and return a new date value. Time after / time before measure the difference between the original date and the second date and return a numeric value in time units.

(Numeric vector fields) Compose - composes a vector value: new / rearrange values. New composes a new vector from numeric values. Rearrange values rearranges values in the existing vector, setting a specific value to '(none)' clears it to 0.

(Tile fields) Compose - composes a tile value: new / rearrange channels. New composes a new tile from numeric values or single-channel tiles. Rearrange channels rearranges channel values in the existing tile, setting a specific channel to '(none)' clears it to 0.

(Text fields) Compose - composes a text value: geojson / gml / wkt / url / url from base and relative.

(Text fields) Copy - supports new parts: json named value / json array value / gml geometry / gml coordinate system / geojson geometry / geojson coordinate system / wkt geometry / url scheme / url host / url port / url user / url password / url path / url extra parts.

(Numeric fields) Limit - limits a numeric value: limit both / limit minimum / limit maximum.

(Tile fields) Limit - limits values of a specific channel in a tile: limit both / limit minimum / limit maximum.

Queries

GeomOverlayTopologyXxx functions for union / update overlays allow the source drawing to be empty and compose the result from the overlay drawing.

GeomOverlayTopologyXxx functions for identity / union / update overlays allow the overlay drawing to be empty and compose the result from the source drawing.

TileViewshedMakeXxx functions take an additional parameter for the channel to use.

TileViewshedXxx functions take an additional parameter for the Z field to use. If the name of the Z field is a blank string, the functions use Z data stored in geometry values.

TileViewshedTilesXxx functions return an indexed table to allow joins.

New functions: TileViewshedArea / Par - compute visible area for a single observer.

New function: GeomToCuts - splits a geometry value into cuts with an area or line.

TileFlowDirAccumXxx functions take an additional parameter for the channel to use.

New function: GeomRadius - computes the minimum enclosing circle for a geometry value and returns its radius.

New function: GeomRadiusGeo - maps a lat/lon geometry value to meters using the scale near its center, computes the minimum enclosing circle and returns its radius.

New function: CoordMeasureRadius - computes the radius of a geometry value using specified measure.

New function: StringJsonArrayValue - parses a JSON array and returns the value with the specified index, as a string.

New constants: INT8MIN / INT8MAX / UINT8MAX / INT16MIN / INT16MAX / UINT16MAX / INT32MIN / INT32MAX / UINT32MAX / FLOAT32MIN / FLOAT32MAX / FLOAT64MIN / FLOAT64MAX - minimum and maximum values for various numeric types. There are no constants for INT64 / UINT64 because computations in queries are performed predominantly in FLOAT64 which is not big enough to store these constants.

Other

CUDA support is updated to CUDA 11, the GPGPU.DAT file includes modules compiled for compute capability 6.0 (TITAN and upper-level GeForce GTX, see CUDA GPUs).

SQLite is updated to 3.32.3, V8 to 8.4.371.23, ICU to 67.1.0.0, Visual C++ runtime libraries to 14.27.29016.0.

Geocoding servers of different types for the same provider are merged together. Creating a data source for a geocoding server allows editing URLs for all services supported by the server.

Geocoding server for Here is updated to support the latest version of the API (v7).

Geocoding servers for Bing / Google / Here / MapBox / MapQuest / Yandex support search services (Search / Search Circle / Search Rectangle) that allow locating features near a lat/lon location with a filter string (typically used to limit results to restaurants, ATMs or something similar, the syntax depends on the server).

(Fix) Reading GDB data forces coordinate systems with no axes specified explicitly to XY even if the corresponding EPSG coordinate system is YX.

Parameter reports in template queries are cleaned to report date values without #...#, numeric vector values without CAST, UUID values without CAST, expressions without extra parens, field names without [...], channel choices without translation ('channel X' instead of 'X'), result choices without translation ('(same field)' instead of the field name).

End of list.

The new GeomToCuts looks helpful with what I'm doing now! Any chance you could write a quick query to show how it works?

Ah, see now that it is in a Transform as well. That allows seeing it in a query. Good. Was hoping though that it could be used to update the selected geom with newly cut transforms rather that creating a new table. Same with the Merge transform. Maybe with a query?

Here's a project with a drawing area, another drawing with a line used to cut the area. The query cuts the area but the portion of the query (at the end) that removes the original area won't delete the original area. Any ideas?

Attachments:
cutter.map

You can use something like this:

--SQL9

-- code generated by Transform pane

FUNCTION SplitFunc(@geom GEOM, @split GEOM) TABLE AS (

  SELECT [value] FROM CALL GeomToCuts(@geom, @split, 0)

) END;

VALUE @system NVARCHAR = ComponentFieldCoordSystem([Drawing Table], 'Geom');

VALUE @systemCut NVARCHAR = ComponentCoordSystem([cut]);

VALUE @conv TABLE = CALL CoordConverterMake(@system, @systemCut);

VALUE @cut GEOM = (

  SELECT GeomMergeLines(GeomConvertToLine(CoordConvert(@conv, [Geom])))

  FROM CALL Selection([cut], TRUE) WHERE NOT GeomIsPoint([Geom])

);

-- replacement code

  -- split geometry into parts, put result into table named 'temp'

SELECT SPLIT CALL SplitFunc([Geom], @cut) INTO [temp]

FROM CALL Selection([Drawing Table], TRUE) THREADS SystemCpuCount();

  -- delete original geometry

DELETE FROM CALL Selection([Drawing Table], TRUE);

  -- insert parts from 'temp'

INSERT INTO [Drawing Table] ([Geom])

SELECT [value] FROM [temp];

  -- delete 'temp'

DROP TABLE [temp];

The query still tries to cut the selected areas with the selected lines, I left it as it was - so before you run it, select some areas and lines.

As regards doing this automatically, we do consider adding this as an option. We will first allow splitting and merging for editing tools and then revisit the transforms.

Thanks Adam but on first run it fails with "Cannot delete record". Second and each additional run, it fails with "Cannot add record". No changes show up in the Drawing.

Also, appreciate the consideration on making transforms add/delete records where possible.

You probably didn't select any areas.

I altered the query to work on all objects, try it:

--SQL9

-- code generated by Transform pane

FUNCTION SplitFunc(@geom GEOM, @split GEOM) TABLE AS (

  SELECT [value] FROM CALL GeomToCuts(@geom, @split, 0)

) END;

VALUE @system NVARCHAR = ComponentFieldCoordSystem([Drawing Table], 'Geom');

VALUE @systemCut NVARCHAR = ComponentCoordSystem([cut]);

VALUE @conv TABLE = CALL CoordConverterMake(@system, @systemCut);

VALUE @cut GEOM = (

  SELECT GeomMergeLines(GeomConvertToLine(CoordConvert(@conv, [Geom])))

  FROM [cut] WHERE NOT GeomIsPoint([Geom])

);

-- replacement code

  -- split geometry into parts, put result into table named 'temp'

SELECT SPLIT CALL SplitFunc([Geom], @cut) INTO [temp]

FROM [Drawing Table] THREADS SystemCpuCount();

  -- delete original geometry

DELETE FROM [Drawing Table];

  -- insert parts from 'temp'

INSERT INTO [Drawing Table] ([Geom])

SELECT [value] FROM [temp];

  -- delete 'temp'

DROP TABLE [temp];

You can just open the MAP file and run this text, the area should get split into two.

Hmm. Same problem. Also, before I did have the area selected.

I'm running the latest portable version, with all options set to default.

Before any run, [Drawing Table] must not be empty, and there must not already be a table named [temp].

Can you check?

Thanks Tim. Removing the Temp table solved the problem for the second query. The one that doesn't use selected objects. It doesn't help Adam's first query and yes there are drawing objects to cut. No matter, I can live without the selection method for now.

In the first version, it requires a selection in both the target drawing and the cutting drawing.

Is that it?

It would be nice to add a couple of little inline script functions to a command sequence like this. One could test mfd_root for the existence of a given component (viz. a table named [temp]) and delete it if it exists; another could return a table representing just the selection in a drawing/table if there is a selection, otherwise the whole table.

Those would be easy to reuse. A nice exercise.

Wish it was that easy but no I selected both. I assume then it is working for you?

Yes. Works for me with a fresh version of your file, using 9.0.172.5. No problems at all.

What the heck. Doesn't work on my laptop either. By selecting, I mean Ctrl click on the objects.

Maybe it just works south of the equator :-)

" Was hoping though that it could be used to update the selected geom with newly cut transforms rather that creating a new table "

That's always an issue with transforms that create a different number of result objects than the number of input objects, and not in a 1:1 correspondence. When you create a different number of result objects you change the number of records in a table. There are many possible ways to handle that, but one of the least confusing is to simply create a new table, and then to make it easy to use that new table by automatically creating a new drawing for it.

Example: Start with a drawing that has one area. That's a table with one record, and one geom. OK, now split the area into two areas. You now have two records and two geoms. If you put the results back into the same geom, what you create is a single multibranched area object, which is not usually what people want to do with a split.

Example: Start with a drawing that has hundreds of areas for the state of Maine, one for the contiguous mainland and hundreds more for islands and various cut-off peninsulas. That's a table with hundreds of records and geoms, one for each object. Merge : areas (dissolve) them into one object. You now have one record, and geom, for Maine.

You could, of course, arrange all such transforms that increase the number of objects to not create separate objects but to create separate branches. All such transforms could allow you to save the result into the same field, a "split into branches" in place. But then when you want to separate those branches out into separate objects you're back to creating a new table. It just kicks the can down the road to the next step.

Would it be possible to create transforms that operate in place on the same table, adding and deleting records? Sure. But that raises very many issues that, depending on your preferences and on the details of what you are doing (a hundred objects in a map project? A billion objects in the remote DBMS that's chock full of triggers, constraints, and dependent queries your IT department guards with zealous righteousness?), might be simple to resolve or might require intricate interfaces.

Given that Manifold prefers to present a single interface that always works, instead of a hundred special case interfaces, to date the resolution has been to simply create a new table when the results create a different number of objects.

That's going to have to change sooner rather than later, because right after the current campaign of new UI and new select/transform capabilities wraps up, will appear features like more extensive interactive editing where splitting objects in place within the same drawing, and merging two areas into one in place, will be part of the show. That will mark one of those crossings into new territories, like crossing a stream called the Rubicon that back in the day was so small nobody today even knows where it was, that may appear to be a small step but which involves the resolution of some very big issues.

I'd expect that for simple cases simple default rules will be possible, and it could be that we'll see examples of some operations that are available in simple cases which won't be available, or which will be significantly different, in complex settings.

To be clear my thinking was that the transform should be able to add or delete records in the table, rather than say creating multi-branched objects. This option would get used often I would think. Creating a new table is doable but a lot more steps. On the other hand, I'd much prefer Mfd press on to other things, especially if transforms could be readily made into queries that can do the job.

The new build manifold-9.0.172.5-x64 is great!

Would it be possible to preserve the orientation of the cut line please?

I am attaching the inconsistent line direction after using Cuts.

Thank you!

Attachments:
Cuts Results.jpg

This problem is still existing in M8 also as send to tech@Manifold. But it will have to be solved because cutting road network with the direction based on the digitization sequence might inject inconsistencies in the network for road optimization.

+1 for this suggestion

We will do this in the future, yes. We have this in the set of planned enhancements to geometry functions.

That will be much appreciated.

Would it be possible as well to be able to cut lines with points please?

Thank you Adam!

We'll look into adding this.

Thank you Adam!

Would it be possible to consider renaming the new GeomToCuts function as either GeomToParts or GeomToSlices?

While 'cut' certainly can refer to the result of a cutting operation (as for meat, hairstyles, a deck of cards, fabric, a shady deal, or a wound), it is mainly the action or means. 'Part' and 'slice' are more general for the result of division, and probably less brutal here. ('Share' would be wrong because we are not setting proportions explicitly.)

For the same reason, naming the transform operator 'cuts' is entirely apt. That is what they do.

It's hard to find a word that does not a) have an unwanted connotation or b) is so generic it does not usefully name the result.

"Slice" has too many meanings in database and data access. "Part" also tends to be used for the obvious constituent parts of an object, often as a synonym for "branch," like the islands or holes of an area, and it doesn't obviously mean the result of a cutting operation.

In this particular case, the word should mean the result of a completely arbitrary division, and it can't be something already in use, like "segment." Ideally, it should be a short word. Words like "portion," and "fragment" come to mind. But "portion" tends to be about food, and "fragment" has some unwanted connotations about possibly being an incomplete apportioning.

"Cut" is at least neutral (could be a cut of fabric, a road cut, a cut in video editing, or a cut of meat). It's short, it doesn't have other meanings in GIS, and it is a reasonable word to use to describe either the majority result of something or a leftover shard.

I'm personally not in any way tied to the word, but I can't think of anything better.

‘Part’ could be used in any of the other ways you mention, yes, but as far as SQL9 is concerned, it isn’t.

‘Cut’ is not neutral. As a noun it is ugly. (That may be why it is not often used in this sense. By the way the senses you mention for video editing and for roading are not really this sense, they are the act or means. For roading the result is a cutting.)

‘Segment’ would be not quite correct, ‘section’ literally correct but perhaps too often used.

Please reconsider simple ‘part’. Unless you have another more important use for that word.

‘GeomToCuts’ is really not a happy term. Please just don’t!

To be very obvious:

‘I cut/slice/divide/tear/break this into two parts.’ That is the most natural expression. Or to be slightly more mathematical, assuming something having linear extent, into sections. (Segments at a pinch.)

‘I divide this into two cuts.’ That is simply not good English, with the only exception of meat. (And then it means something more than simply parts—it means cuts, such as flank versus brisket.)

Not geometry. (You can cut geometry, or make cuts in or through geometry, but you can’t divide geometry, or most other things, into cuts. Wrong word.)

"That is simply not good English," Well, we're back to whether something is good English or an acceptable Americanism. :-) And even that is a higher standard than technical pseudo-English.

I don't particularly like "cuts" as a noun either, but it is a noun, and not just for meat. In the US, for example, the noun is "road cuts" and not "road cuttings". There's also a "hair cut", although I agree with you that as in the case of meat there is an implied sense of some sort of specific style to it.

"Parts" would be ideal if it wasn't claimed by ESRI's strong binding of "part" to "branch", where multibranched areas are called "multipart polygons". ESRI explicitly uses the word to mean "branch", as in differentiating "singlepart polygons" from "multipart polygons." So if you call the thing "part" you'll have millions of people who have been trained in ESRI thinking you mean splitting into branches.

So, sure, if it wasn't for the incontrovertibly significant influence of ESRI-speak, I'd choose "part" over "cut" in a heartbeat. As it is, it's not such a clear call.

My own feeling is that it is up to the Manifold community. What most people want is the way it should go, as this is an easy thing to change, especially in the next couple of weeks.

Some other options: division, subdivision, split, partition, piece, portion

GeomToPieces seems good (nearly as good as GeomToParts, which Dimitri explains may collide with ESRI usage).

Another approach might be to give up the 'To' naming pattern for this case, and use a verb not a noun. GeomDivide or (why not?) GeomCut seem perfectly good to me.

GeomCutToPieces gets my vote haha

https://github.com/mdsumner

We discussed and we will likely rename this to 'parts'. GeomToParts, Split into: parts, Split with:, Split with selection only. The conflict with 'multipart geometry' as used in ESRI products is unfortunate, but we think 'parts' is still the best here.

Thanks for the notes.

I take it from some posts that Manifold 9 currently cannot georeference images, but work is ongoing to implement it. Any idea when this might surface in the cutting edge version?

That's up for the next series of builds after the current select/transform/previews get wrapped, so soon. My guess is about a month.

What's Next

We are working on the preview for selects and transforms and on various small improvements to the UI, many inspired by forum feedback.

We are looking to issue the public build in two weeks, give or take. We might have an intermediate cutting edge build before that.

The build is mostly localization-ready. There are a couple of strings that are going to change, but nothing major.

Enjoy!

Status

We are planning to issue 172.6 in about a week. The main focus is on previews for the new panes, plus we are going to have a number of improvements all around.

Status Update

We have not yet been able to complete works on the previews. The main challenge with the previews is how to make the template produce a useful result without performing the transform in full. We use a variety of techniques to do this. After changes to the Select and Transform panes we have to adjust or rewrite most of this code and some of the changes have been quite tricky. We are also aiming to provide previews for a number of templates that have not had any previews before, this adds work as well. On the good side, we have already added a number of features to the previews that will make them noticeably better than they were before - they are faster (can now use multiple threads, couldn't before), you have more control over them, eg, they only appear if you explicitly call for them (no wasting time computing something you might not need) and they no longer update themselves as you edit parameter values (no wasting time re-computing something that isn't final), etc. It isn't just about previews either, we have already added a couple of features unrelated to the previews and we will likely add a couple more. :-)

We think we will be ready to issue 172.6 near the end of this week, at most right after the weekends. If there will be any significant changes to these plans, we will communicate them.

I think it is amazing that previews ever work. And not only that, but that they also seem to work. (Like justice.) Even when there is screeds and screeds of complex data!

If in following builds they are sometimes slow, everyone will assume that is for a good reason. Especially if preview is switched off by default. That is a welcome addition in itself, yes.

First, the possible. Then...

This is probably not a useful suggestion, but I imagine people would be happy to have previews slowly roll out over time if it meant sooner implementation of other improvements that are next in line.

We hear both you and Tim. After this series of builds we are going to try a different way of making big changes so that we can continue having cutting edge builds with other features as we are making these changes.

We do not like when the time between cutting edge builds grows to 3-4 weeks or higher, we think it should be 1-2 weeks on average. This provides more opportunities for listening to the feedback and re-adjusting priorities.

Status Update

The previews are gradually getting better, however as the feature is maturing there are some growing pains. For example, we thought that the recent addition of the auto-style for images was all that was needed to produce meaningful previews for raster transforms. The reality turned out to be more complex and while having an option to use the auto-style for the produced raster helps a lot, we need to add several other things of comparable complexity to make raster previews good. There are a couple of similar issues with vectors.

We are going to fix these issues and then release the build. Our best estimate for the build date is a week from now. We agree though that however helpful the previews could be, they should not stall other features that we planned to add, so we will wrap it up. In the future, we will try a different way of doing big reworks like that, so that cutting edge builds do not have to halt and can continue at a reasonable pace with more room for feedback and incremental improvements.

Apologies for the delay.

Any update on the next release?

Yes it seems strange.

In these times we all worry about each other's health acutely.

No health issues, just lots and lots (and lots more...) details for new things. All that takes time, testing, tweaks, more time, just to get to where a cutting edge build is ready to present.

To take a simple example, consider how the new capabilities in the transform pane might affect previews in something as simple as tables. The old transform pane put results into the target destination field, which had the focus when you clicked on the transform pane. Click on a different window to move the focus and all context was lost. That was a huge simplification, because there never was any possibility of multiple different previews attached to different contexts.

The new transform pane can save results into a wider variety of result destinations, like the same field, a different field in the same table, into a new field (which it can create for you on the fly), and into a new field in a new table. What used to be a simple, limited possibility for previews is now a possibility for previews into a new column that didn't even exist in the table before. To preview that you need something like a virtual table.

Add to that persistence, where if you change focus to the select pane or to another window the transform context for the former window persists and does not get lost. Should a preview that was commanded also persist? I think so. But that means any changes you make in the Style pane should also be consistent with what is being previewed if, say, the preview has to do with a window in which Style operates.

I think there's about 30 different flavors of dialogs that can do stuff while a transform pane is holding context, and doing a preview, that have to be considered. There are also several different scenarios for previews that tend to be common across many templates, a variety of different data types and window types and component types (labels, for example...) and so on, all of which are different dimensions of variability, which in combination open up very many permutation possibilities.

Consider the many permutations and, even with extensive modularization and abstraction, you end up with a few hundred different cases that all need to work correctly, and which must continue working even when a variety of threads might be changing the data on the fly, affecting the level of detailization and the results of what abstraction algorithms pick out to visualize at different zoom levels, etc.

Most of that isn't rocket science but just a very large number of things that must be done to get the seamless, efficient, and reasonably representative (ie, accurate) previews we'd like to have, in as many situations as possible. There are also very many decisions that must be made as to how new capabilities can be managed in a UI that is as intuitive, quick, and convenient as possible, and it all has to be built in a way that won't need rebuilding as planned new capabilities appear through this next year.

My guess based on alpha testing is we're not far, probably about a week, to the next cutting edge build. That's a guess on my part since I don't want to surface anybody from deep recursion in engineering tasks to ask.

I'm glad and thankful that everyone is safe.

As far as previews are concerned, I think it is clear that they became too much of a thing, internally.

Some users will love them, no users need them, I will just want to turn them off.

A salutary example perhaps of mission creep/death by entropy affecting the very best in the business. No one is immune.

If you always use SQL and never use the Transform pane, or the Select pane, then sure, it makes sense you don't care about previews.

But most people do use both the Transform pane and Select pane, and for them previews are useful. A big effect is how previews can help avoid errors, like transforming an adjacent field instead of the one you intended, forgetting to limit a transform to the selection, and so on.

Doing GIS is expensive for organizations, and undetected errors within workflow can be very expensive. Anything that can reasonably be done to help avoid errors, especially something which doesn't get in the way, delay anything or alter workflow that you'd be doing anyway, is a a big help.

Previews can also help beginners (and experts) to learn what operations do, and to zero into desired parameters, like the right size for a buffer, by interactively trying different parameters and seeing what the preview does.

I second this view on previews. Especially when it comes to funcions I use only occasionally like regular expressions I love the table preview even if its only for a starting point with the frame and this special syntax of the query that I will extend manually.

Politics is the art of making the impossible unavoidable

I always agree with Klaus, though sometimes only afterwards.

I get it that previews are a bit like being able to use (Shift-)Alt-Enter on a section of trial SQL.

From a design perspective, these things fit together snugly.

Yes, RegExp is a particularly apt example.

[added] I rarely disagree with Dimitri. Not here. I like being shown to be wrong.

Or it could be that Manifold is finally subject to a takeover bid, and development has been temporarily halted.

I really hope not. Attractive as the company must undoubtedly be, Manifold's open independence is golden.

It's sort of the opposite situation, more development, not less. :-) The key sentence in my prior post:

it all has to be built in a way that won't need rebuilding as planned new capabilities appear through this next year.

Work on previews is just the tip of an iceberg of infrastructure that must support planned capabilities. With georegistration of images, for example, you want to be able to see a dynamic preview what will happen, based on what options you pick and values you specify in what, really, is just another type of transform.

Interesting discussions. I like that you have a clear plan and communicate openly about unexpected difficulties. I originally asked about the feature georegistration. I am happy that it seems to be "around the corner", I am not happy that it is delayed by the previews, but that's life. Please plough on, and thanks in advance for occasional updates about the expected release date!

I, for one, will keep the faith and trust the Manifold development team to release it when it is ready. Many of us waited patiently for years for Manifold 9 to be developed and released while we continued to do good work with Manifold 8. We've been spoiled by the power and speed of 9 and we want the whole ball of wax, but sometimes there are bumps in the road that take considerable time and effort to overcome.

I believe they will get there in short order -- and I would like to say thank you the entire development team for their unwavering commitment to developing this technical masterpiece of software.

I agree!

Me too.

Two months is not very much. The communication fell off for a while, but that is completely understandable. If you don't have an answer, it's better not to give one.

Time for a status update.

We are deeply sorry for the delay. We agree it has been way too long since the last build.

The reason the delay has been this awful is completely mundane. To put it bluntly, we were trying to make previews for selects and transforms perfect and perfection kept escaping us while seemingly staying within reach after each iteration. It was a matter of chasing a very high quality bar for a complex feature with each step making the feature better, but uncovering new things to improve upon. We should have planned this better.

We are wrapping up and will release the build later this week before the end of the month.

After this build, we are going to do all big changes in a slightly different way that should theoretically allow us to never stall cutting edge builds and instead delay the features that are being worked on while still having them available for internal testing within the build.

Apologies for the delay again and we will have the build later this week.

That's very exciting! Thanks Adam.

🚀

https://github.com/mdsumner

Great news! I'm sure the wait is highly justifiable when trying to make the best work possible. Keep up with the amazing work with new Manifold builds!

I am envisioning the activity in the room (if you even have a room in today's health environment). As soon as Derek get something working, then Janey gets an "aha!" moment and shouts, "now that that works, I can do THIS! I can knock that out before going home tonight!!" [two sleeps later] Janey is still trying to perfect her thing but promises it will be finished tonight. Meanwhile she's brainstorming with the rest of the crew about all the initiatives her thing will open the door to. Janey's thing turns out better than expected which launches another round of, "aha!" moments.

[Removed]

I don't think an apology is warranted here, but perhaps an explanation.

I landed on David's post above as an opportunity to lament the apparent lack of women in the Manifold community. (With no doubt excessive irony.)

I gather that this is not the case behind the scenes. I hope it can likewise change on the forum and in public generally. We need more visible women, I think.

I appreciate that the facetiousness of my deleted post was undoubtedly misjudged.

What I was trying to say, and am still trying to say, is that it is high time for Manifold to present a face to the world that is less than 100% male.

If anyone needs a reason (other than humanity being ~50% female), it's to encourage girls into GIS and programming. Affirmative action is OK.

I made a joke of it before (and a clumsy, poor one), but I really think it's important. Can we have some women please?

Now I want to see the deleted the post!

Let's discus a women's quota for postings.

Old white men like myself have to shut-up until there is at last 25% postings coming by women.

Politics is the art of making the impossible unavoidable

Don't know why but I'm always surprised on the ESRI website at the number of women contributors.

Now that I think back, in 2014 I worked with an oil company out of Houston that was building a cadre of surveyors who would jump on the ArcGIS bandwagon instead of CAD drawings. I was tutoring one of those surveyors and got invited to Houston for a meeting to show where they were headed. The team heading the initiative was the previous year's MS in GIS graduating class from Penn State and mostly women.

In 2015 a big river management agency came to talk to our local river management agency about a wide area project they were working. More than half their GIS team was young women.

The little group in our county working on emergency services addressing consists of two women.