We have not seen a new release of Manifold in a while. What is the rough timeline for the next release and what new capabilities might get addressed?

I have been wondering the same thing. It would be reassuring to know something even if it is as simple as we anticipate within the next 6 months, 1 year, x years.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

I expect routine builds for 9 will get started again this summer. Plans are to keep evolving 9 even as the company explores something new.

Sounds great, is something "new" a collaboration with another company and their GIS software?

Sorry, I can't comment on that.

Sounds interesting. Thanks Dimitri

Landsystems Ltd ... Know your land | www.landsystems.co.nz

As noted in this thread, Manifold's working on a very big project right now with all resources flowing into that. I expect that in a few months it will get back to routine builds, same as usual, a mix of small things with some bigger things.

It sure would be nice for 9 to get all the basic GIS functions (i.e., measure area tool) finished before it starts sharing engineering time with another product. It feels like many of these are not so important by the folks that are willing to use this forum and submit suggestions. However, I would think there could be a lot more sales if the basic functions were more polished, given that one expert user can often support many novice users. It is great that the Mfd team is working hard on a big new change, but it may take much longer than expected. The dark decade between ver. 8 and Radian was very long, although the jump forward was great. It just has some holes that need filling.

I agree with this. There are basic functionalities in other GIS that are still under development in Manifold v9, such as per-pixel editing or the existence of grids with coordinates in layouts (to mention two of the functionalities that have been part of my suggestions since 2020) and which, more often than is advisable, lead us to intercalate our workflow with Manifold v8. I can't wait for news in the Manifold field, as v9 was a very significant leap from v8, but it would be great to cover some of these holes before long periods without an update.

It's been ten years since the Radian Beta opened, and the product that became 'Release 9' is very useful; I use it daily.

Increased integration with other products probably makes sense at this point, rather than adding more functionality. I totally agree that all the 'basic' GIS functionality should be added to 9, so that it at least fully replaces 8, but Manifold probably doesn't need to try and compete with ArcGIS Pro or Avenza on, for example, map-making for print.

When sql4arc was announced it was accompanied by some refreshing acknowledgement of the usefulness of ArcGIS in areas where 9 is less full-featured. I took that as a good sign that we could expect more such interesting integrations in the future. ODBC driver has been a very useful tool as well.

Does it make sense, then, for Manifold to more tightly integrate with another product?

I'll use the example of SuperMap, a Chinese GIS application which has desktop, server, and web framework products. Leveraging SuperMap's extensive abilities with Manifold's high performance data manipulation chops could make sense for existing Manifold customers. A 'sql4Super' product could make sense here, perhaps.

I'm less enthusiastic about Manifold becoming "a part of" another company's application, since I've committed so much of the manifold stuff to muscle memory, and I really do enjoy it's speed and stability, but it's also unrealistic for me to expect Manifold to become something drastically different in the next ten years.

** Speculation start **

My own hope was that this pause was to develop the next iteration of the MAP file which has been mentioned on and off a few times over the years. The factory has been adding functionality against the current iteration for 10 years or more and so I guess it wouldn't be unreasonable to come to the conclusion that in order to add certain capabilities or follow new directions, that this would be more efficiently achieved against an upgraded base.

** Speculation end **

Whatever the weather I have my fingers crossed for a resumption of builds as I think there is much scope for not only rounding out the base functionality but also for the addition and fleshing of many existing and new analysis tools.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

Its interesting and fun to speculate for sure. A new base might also allow new sales. Sure hope its not integration with another GIS, because I've come to really like the Manifold GUI and how it works on a smallish touchscreen and integration sounds like compromises. Perhaps its a push toward multi-user relational database and opening itself up into those markets? Might be more fun for them to work on then labeling!

Mike, are you still using M8 at the office for anything?

Yes, for web maps and a very occasiional odd task.

Do you have people in the office using the free M9 viewer for anything?

No. I used to have novice users using some extra licenses I bought when they were around $100. That need went away and I haven't had the time or need lately to encourage their use. Also, was hoping that better labeling and an area measure tool would have gotten added.

I still use Mfd 8 with scripts that use 3rd party 32bit dlls. I need a hint how to make 64bit Mfd 9 work with them.

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

I honestly stayed with 8. All workflows are done great, specially since all are basci gis functionality that M8 does great. I presented 9 to all my clients, and noe actually made the move for 9 on a enterprise-wise upgrade, they just added one license for specific big tasks, and the rest is still done with M8. And they didn{t have to re-train every user, etc... and this has been my case. I now offer both 8 and 9 together. R9 only for power users, but if the client is only requering basic GIS development, makes no sense to go straight to 9, since the learning curve is different (even with all the videos) the basic GIS functionality in 8 is just so simple and great. I guess, I'll stay with 8 until everything is as easy and friendly in 9 specially for low level users.

I would like to use 9 in new services, like the WMS and webmaps, but that still needs polishing.

Personally, I think R9 is more a spatial ETL tool than a traditional GIS option, and a big data management system. R9 is for specific work tasks, M8 is for regular day to day GIS flows. Would be nice to be able to use Commander to automate some tasks, present in M8 projects... (crazy idea, maybe)

Interesting to hear your perspective. Everybody's work flow and preferences are different. I've switched everything to 9, except still use 8 for web mapping and an occasional odd task like the Color tool. With 9 you get better data storage, easier access to streaming data, cleaner UI (bigger map window), overall slicker vector editing tools, sharper styling, faster georegistering, more flexible SQL, and more readable curved labels.

Those benefits are worth putting up with the basic missing features in 9 for my work, but I can easily see how that's not the case for others. Probably the most surprising missing feature is an area measure tool. BTW, I remember long ago poking fun at ESRI for not having this in their main product.

The speed of 9 seemingly could allow for really awesome dynamic labeling. That allows users to get lots of information off the map much faster or make nice maps much faster. That could really set Manifold apart from other GIS products for the large crowd of people needing basic mapping vs the smaller crowd that needs high end GIS tools.

If I was still working I would be on M8 for 90% of the office work. The main M9 feature I needed to keep up with was the free viewer. I developed a process that the agriculture appraisers used to estimate the number of livestock to be raised on any given ranch. It used USDA land data, so it had an element of science in the estimate rather than placing a fixed number of animals per acre. So the agriculture appraisers could use the free viewer to create a report for each property.

M8 also has the Viewbots which I relied on for daily decisions. I also appreciated the ability to see through selected parcels to see if there were any overlapping border lines under a selection.

I also appreciated the ability to see through selected parcels to see if there were any overlapping border lines under a selection.

You can do that in 9 as well. See https://georeference.org/forum/t159438.7#160414

M8 also has the Viewbots which I relied on for daily decisions.

Viewbots are cool, for sure. I'm the guy who originally suggested them, so I'd be the last to say they're not useful. :-) But it's easy to use queries to implement the power of Viewbots but in a more general and more powerful way. There's a tradeoff between the very simple interface in 8 and the limitation of power you get with that, and the more difficult but far more powerful analogous capability in 9, but if you want to do simple things you can keep a few projects lying around with snippets that make it easier in 9.

There are three ways of doing Viewbot-like things in 9 that first come to mind:

1. Use computed fields. Much of what Viewbots do is to provide per-object computations and readouts, and those can be done with computed fields. If you want the areas of polygons, created a computed field that is powered by the expression GeomArea([Geom], 0). See the Computed Fields topic for many examples.

2. Create labels that include expressions. For example, you can have a computed field called [AREA] that gives the area of a polygon, or you can just create a label for which the text of the label is

Area: [[ GeomArea([Geom], 0) ]]

where the portion within [[ ]] doubled brackets is an expression. That's a more casual way to generate a readout than creating a computed field and then creating a label from that computed field.

3. Create a drawing from a query where the query does some wonderful SQL that computes the value a Viewbot would. Next, create a label from that drawing and put it in some visible spot in your drawing to report the output of that query. Or, you can just open the label component in its own window and leave it flowing about.

An example

We have a drawing layer of polygonal areas called Parcels which has a computed field called Area that reports the area for each parcel. We don't really need that computed field but I've included it so that in illustrations each parcel can be labreled with the area, so we can see how the Viewbit (I'll call it that in 9) reports a correct result.

We want a readout that shows the largest area of any of the parcels in the drawing. If we change the size of a parcel or add or delete parcels it should update itself.

Here's a screenshot that shows my Parcels Drawing with a few other open windows as well:

This is what I did to create it:

1. Create a new drawing called marea (for maximum area) and drag and drop it into the Parcels Drawing window as a layer.

2. Create a single point in the marea layer where I want my Largest Area readout to appear.

3. Create a query called mquery that contains the SQL text:

-- $manifold$

SELECT [GEOM], (SELECT MAX([PARCELS].[AREA]) FROM [PARCELS]) AS [MAXAREA] FROM [marea Table];

That query (as can be seen in the results table) creates a table with two fields: a Geom field that just contains the geom for the single point in the marea drawing, and an aliased field called [MAXAREA] that contains the single value that results from the SQL statement

SELECT MAX([PARCELS].[AREA]) FROM [PARCELS]

Note that when we put together a field like this for a table we can use a SELECT statement, but if we were to create a computed field within a table we cannot use a SELECT (I don't think...) but have to use a simpler expression.

4. Create a drawing from the mquery query. The geom that comes in from the marea drawing is in Pseudo Mercator (I created the marea drawing using default settings) so that's what we use for the drawing.

To learn all about creating drawings from queries, see the Example: Create a Drawing from a Query topic.

5. I added the drawing created from the query, called mquery Drawing, as a layer to the Parcels Drawing window just to make sure it did, indeed, create a point at the desired spot, but that's not necessary.

6. Create a new Labels component called Maximum Area from the mquery Drawing. The text for that label is

Largest Area: [MAXAREA]

When you add the Maximum Area labels component to the Parcels Drawing window, it reports the value for the MAXAREA aliased field from the drawing created by the query.

7. If you change the size of the polygons or otherwise modify them, the Largest Area readout updates:

If it is inconvenient to have to pick a spot for your readouts in your main map that will always be in view, you can just open the Map window in a second window, undock that window and just park it somewhere on your Windows desktop in view. That will allow you to put your "viewbit" readouts in a part of the map far away from your working space, and to zoom the second window into just those portions.

The above technique, creating a field in a query which is generated from a SELECT that is later reported in a label is a very useful and powerful technique. Because SELECT statements can be very, very extensive and powerful, they allow you to do all sorts of things that cannot be done with Viewbots.

Read the topic on creating drawings from queries to learn how to do things like reckon only those objects that are selected, so you can use this technique to create viewbits that report results only for, say, selected objects. The possibilities are pretty much endless, so long as the result of that SELECT is a single number which can then sensibly be reported in a readout. But that's the same limitation you get with Viewbots so overall you get more power.

Attachments:
viewbits_01.png
viewbits_02.png

** Speculation start **

Or maybe some AI help in the SQL generation or "How do I do that".

** Speculation End **

Any more news on the next release?

Sometime this summer, I hear.

Like, Hong Kong summer?

Happy equinox!

Still using release 9 every day, and will be happy to hear of any news related to the product's future. Cheers to you all.

I second that. Manifold 9 is still my daily tool of choice and it would be great to continue the path of progression with cutting edge releases. Any news on this topic would be great.

my 2 cents about new feature for next version ( last october 2023)

1) nvidia was sued by french goverment relative to CUDA. if proove we speak about 10% of revenu to pay from a company in front of apple with their AI graphic card ( rtx5 blackwell) !!!. Spectral Compute has unveiled SCALE, a toolkit that allows NVIDIA CUDA applications to be natively compiled for AMD GPUs with no additional work required...so why not manifold on amd gpu !!!

2) in manifold 8 there was automation tool but now i think there is API since microsoft has power automate ! manifold should behave like software as a service but because manifold is itself the web service!!

3) better editor. even manifold support many language compiler the black and white editor should be easy switch to another external editor. manifold 8 do better in this side

4) perhaps 3D editor since more virtual world ll come ( desktop 3d for oculus , AVPro) but we are far from gis

5) manifold try to be simple for newbies so more tools ( to customize, modify code ) to export map project to web ( access using http). perhaps more integration with python jupyter or IIS equivalent !!

i know manifold implement their own technology instead use third component !!!

Boyle surface fr ,en

My company and clients all stayed in M8. Most use what you call a Classical GIS, and R9 is promoted for Power users. Re-training everybody that uses GIS is not a priority if with 8 they keep doing everything they need, even it can be done Faster, but there is no computational heavy tasks, just "basic" GIS which 8 is much easier to work with than 9. Also all the other clients that invested in developoing custom scripts and FORMS can only be used in M8 32 bits, and that is a very big deal. I would love a merge between 8 and 9, like a Manifold 17 (8+9) because it's been hard to offer 9 as an option for novice or basic users. All the super speed of R9 can be harvest when you have big staff, not small projects of small local governments, or "Small" amount of data.

The way I have been trying to promote R9, was for wms and web maps, but that is not yet polished, and in my country, most all traditional GIS users (95% of government institutions, local and federal, plus most commercial entities use ARCGIS and Arcgis online now, emphasis on ARCGIS Online) which I dislike), because of the licensing schemes, all subscriptions plus poor training = clients kidnapped. Pulling them out of that schema is difficult. Even more in the Utility sector which is now using the Utility Network Model, that it´s another ESRI invention to lock a niche, and promoted by other manufacturers like Survalent which is a huge company/software for Management of Utility Networks. So, I feel we are been pushed a side, to just a complentary tool, and not the main tool which was for years.

Almost every client I confront, uses ESRI modules of Spatial Analyst, 3D Analyst and a few more, not very complex and I´m pretty sure they are subutilized, but anyway, the 3D features are not there yet (MAybe I haven´t found them on 9) and the use of arcgis online to collect data and produce web maps easily as the main pain points for me, to combat against ESRI.

I love Manifold and have used it for 20 years I think, since 4. Never wanted to go back to ESRI, but the market is pushing hard to keep free from ESRI. The thing I love the most is that the client always keeps control and ownership of the data, since Manifold is installed in the clients servers and deskptop, the files are always under control of the client, meanwhile in ESRI, they have the control. I turned clients a few years ago that were managers from IT, by only making that point clear. They didn´t have control of there own data, since ESRI providers had the files in there server, and once we turned them they had to ask permission to access there files, specially if they haven´t paid the support. Incredible case study, but true. ESRI idea of always creating intermediate software just to charge more, is crazy from my point of view, that is why MAnifold always had the upper hand and the morale stance, I like to see it like that.

I guess doing SQL4Arc makes sense for business, but I dislike the idea to give the power (of some of its differentiator and coolest features) to the competition. This community is a different breed, we stick to Manifold for years, with patience from one to another 8 to 9, with such a surprise, that 9 is not a continuation, it could perfectly be called something else, like Radian or else, because is not an improvement per se of 8, is a whole different product. Don't punish me Dmitri but 9 is from another world, so different, that my last sale pitch for 9, had nothing to do with GIS, but as the Absolute BEST Data Science ETL tool. The Manifold Commander sounds great, I just hadn't any customer requesting to use it... too bad, but sounds great for recurrent jobs, and that is an IT job, not even GIS job. So, I'm trying to sell 9 as the Database Admin best friend, which I think fits perfectly, a plus if its an Admin with spatial data.

I know I haven't take enough time to properly learn and train myself in 9 yet, but work with 8 is consistent and good. I like to follow the say, don't fix what isn't broke. So I stick to 8.

Finally we changed from a technical GIS to consulting and spatial intelligence because other tools are on the forefront...

Following. I started with 4.5. I hope we don't have a similar hiatus as we did between 8 and 9.

An update: As discussed in other threads Manifold has been applying all resources on a big project exploring new technologies. The effort has been significantly more difficult, involving much more radical technology and many more unknowns, than the creation of Release 9.

The new technology derives from recent advances in AI. If successful, it would change everything about how people do GIS, from hobbyists to the most advanced professionals. It would change everything about GIS technology from how internals are built to externals like user interfaces.

For example, you could speak to the package using any of dozens of different human languages and tell it what you want by way of an end GIS task result and it would do it for you, even going out and gathering the data you need based on your past preferences. If you wanted a customized version of the package you tell it what you want and it configures that.

Our problem now is that after a massive amount of work, a year of time, and tons of money we have not yet been able to make it work as well as we think it must work. It works brilliantly, like magic, when it works but in too high a percentage of the time it works inaccurately. A package that produces wrong results too frequently is not good enough. Another problem is that the current level of hardware technology requires a large investment in local hardware that very few Manifold users can afford.

We believe those problems can be solved, but it is clear that at the current state of technology the time required to solve those problems will be longer than we can ask our users to bear. We do not want to repeat the 9 experience of pausing the current product for many years while inventing and building new things.

Instead, we are going to return to evolving Manifold using current state of the art technologies. There are years of improvements that could upgrade the product for users so we will do that for a while. Restarting regular builds will take a few months because of the time required to get safely back into the swing of production processes involving millions of lines of code.

At the same time, we will continue work on new technologies in a reduced effort. We think there are possibilities for taking some of the new work and applying it to Manifold as it is. That will also help continue exploratory work so that in a year or two we can take another big run at it.

It's disappointing to spend over a year on radical new technology with nothing immediate to show for it but I think the effort invested will prove worthwhile in the long run.

Thanks very much for the sincere and helpful update. It says a lot about Manifold that they dare to take a great leap and are humble about their failure. As you intimate, it may not turn out to be a long term failure, as you learn from your mistakes and are a little closer to your goal even as you admit temporary defeat.

As a retired data scientist, I think there may be great things done by artificial intelligence, but it is not the end-all and be-all. Data scientists know all about the limitations of data science, it is a very useful tool but not the final truth. It does make mistakes. It is up to the human to analyze those results and make their own human decisions.

I wish the data science community would do a better job of explaining the limits and dangers of the technology. In their zeal to promote the hype about their new technology (thereby promoting their careers), they have not told the public about how it works and the dangers it can expose the careless user to.

Manifold GIS leads the way! (A paraphrase from my old Army Ranger days)

Glad to know what y'all have been working on. Also glad to see you realized it's time to get back to the job and not try to develop something based on technology that has not matured. Here's my opinion of AI.

The prompt was blonde woman standing in an alley wearing a mens jacket and yellow swimming suit. She seems to have either 15 or 20 fingers.

Attachments:
generated21.jpg

Very glad for the update and to hear regular builds will resume. My guess is that if 9's core GIS functions were caught up with the competition, then 9's existing infrastructure would really shine and result in significant number of new GIS converts.

It is very much appreciated to hear that Manifold respects users investment in 9 and does not want us to bear a long wait for 9 to receive tools that earlier comments from Manifold indicated would be coming soon. I think Mfd 8 was more complete and compared better with the competition at the time its development halted then how 9 fairs with the competition today. I'd really be bummed to have to switch back to ESRI.

The annual cost puts me out of the ESRI market, but dang, that John Nelson can make ESRI sing. If all I wanted to do was pure appraisal district work, M9 is adequate. But my interest is becoming more artistic, and M9 is inadequate for what John has been doing on his YT channel over the recent years.

Agreed. What he does is fun and thanks for the laugh above. Wow.

Thanks for the update Dimitri.

manifold 8 is still great and continue to have update or package /functionnalities not implemented ( in easy way GUI) in 9

Boyle surface fr ,en

Hi Dimitri, is there any prediction regarding M9 updates?

Same as before. It took a bit longer to pull people off the new tech than expected (the "just one more..." effect) but I still expect new builds to start this year,

Hi Dimitri. I believe we all are eagerly waiting for a new update. Thanks for the update.

Any progress towards an update? I am increasingly having to do my intersection operations in Pro as Manifold seemingly squanders its advantage. The forum is all but dead. Happy New Year

Landsystems Ltd ... Know your land | www.landsystems.co.nz

Same here Dan.

I'm working with multispectral imaging these days, from collection to analysis. Nine is nearly there for my business needs. But not quite. With no public facing development, it seems submitting suggestions is a fruitless exercise.

I second that. At this point, any sign of life from Manifold would be good.

Any progress towards an update?

In a nutshell, it's proven much harder than expected to peel people off the AI projects and to go back to doing regular builds. They're supported in that by the very strong pressure from constituents, users, and partners to stay on the AI path.

I've written the following essay to discuss some of the issues involved, including how to influence the decisions Manifold is making. It's a lengthy essay since the subject matter is non-trivial.

---

One risk with "public facing" processes driven by social media is they can be dominated by disjoint interests in small scale, additive features. That very rarely results in revolutionary changes that require large investment over long periods of time. That's not in any way intended to disparage small features. They can be truly wonderful and the accumulation of them over time can genuinely improve the user experience.

Just yesterday I had a taste of that, where I was altering a table schema and I found myself thinking "man, I'm so happy I got that suggestion through that whatever was the last data type created for a field would stick as the default." That's so useful, like when you want to create a bunch of nvarchar fields or float64 fields or whatever in a row. That came out of a suggestion I was the first to make that got adopted, finally bubbling to the top in an available slot, and now it's really useful and improves quality of life, at least for me.

But because small things tend to be personal and specific to personal tastes or specific business needs, there tend to be very, very many of them and it can be hard for any given one of them to get critical mass to get done ahead of others. I don't think that's a bad effect because it seems reasonable that those small things which are popular enough to stand out from the crowd should be done first.

But if you wait for a critical mass of social media suggestions to arise that say "take years to do a parallel system" that's not going to happen. Yet sometimes you have to do a parallel system just to deal with the scale of data involved.

If the size of the data you work with doesn't require 9 then you'll undervalue the main reason 9 was developed, in most cases to deal more comfortably with larger data. But already for business efficiency and just plain user satisfaction data sizes are growing beyond what in many cases can be comfortably handled with ArcGIS Pro or Q. People already are spending time on strategies like reducing the size or complexities of their projects in Pro so they don't have to wait forever for a project to open. There are, of course, niche cases where something in Pro goes faster than in 9. But that's the exception, not the rule.

For 9 going forward there is the same question that 8 had to face: where the investment should go to take it to the next level. 8 was designed as a classic GIS so it takes the classic approach of lots of menus and modal dialogs and commands. That's not a criticism. I contributed much of the user interface design in 8 and I'm pleased many people still like it.

For evolution from 8 to 9, Manifold could have taken the ArcGIS Pro route of wrapping 8 in a ribbon interface to make it look "modern", dump Microsoft languages and embed python, and then add a bunch more features like Esri's optional tools, plus an online publication service. The result would be something like Pro with more features that cost less. And it would be just as infuriatingly slow and limited as Pro with more modern data, as well as having the limitation of the modal user interface both 8 and Pro use.

Manifold felt there wasn't a compelling need for yet another classic GIS with many features that was annoyingly slow with the data sizes that were coming into use. It seemed like the first job for any new GIS had to be handling the size and complexity of data as it would be by the time that new GIS was developed. Hence 9.

9 has accomplished its main task of working reliably and quickly with larger data, and it has a non-modal interface that is very fast for people who use it regularly (annoying though it may be sometimes for people who have not learned the program).

The question now is whether to build out 9 by continuing to add many small features, like the one I praised earlier, or to break through the next big barrier to people doing GIS. The barrier 9 broke through was data sizes. The barrier today is that GIS has become too complicated for most people to do in a way that is economically efficient.

That complication issue is fractal in that it exists at almost every level of the GIS economic ecosystem, from the complexity faced by inexpert users to do what they need in simple matters ("I need to create a trail map for my hiking club") to what organizations face ("How can our county afford to...") to what builders of the tools face ("It will take two man years to add...").

Those different fractal levels of complexity interact with each other: one reason it is complex for inexpert users to do simple things is because with classic programming technology it is economically infeasible for builders of tools to build free or low cost software that will do all of the many simple things an inexpert user might want with a sufficiently purpose-built, hold you by the hand, wizard interface.

And that's not just an issue for inexpert users. It also exists at more expert fractal levels. Just like there are things that are hard to learn to do for a rank beginner, pretty much whatever your skill set you'll encounter tasks that for you are hard to learn to do. And there the economics of building tools that are "easy to use" for such special cases are especially brutal, because they involve ever more extensive and more difficult programming work for ever smaller niches where there are ever fewer numbers of people who are willing to pay for their development. So you end up with expensive tools to do those more sophisticated niche things.

If you look at Manifold evolving not by adding more and more features to the same engine but by taking on big things, when it came to evolving 9 it was clear that like the "big thing" jump from 8 to 9 was about tackling data size the jump from 9 to 10 would have to deal with complexity and the limits of human learning. Just like the only way to deal with data sizes was parallelization, the only way to deal with the limits of human learning is artificial intelligence, to utilize synthetic intelligences that are much smarter, far more knowledgeable, far faster, more accurate, and more adaptable than humans. I'm tempted to use the term "agents" but that has specific meaning in AI these days I'd like to reserve that word for that meaning.

Very soon after embarking on 9 it was clear to Manifold that financing for such a huge, multiyear effort would require customers who would be willing to advance funds for tools that could handle bigger data, especially the first part of it, the Radian engine. Those initially were in non-GIS businesses, primarily OEMs, because GIS is too small a market to support such work. That in turn led to a "data first" focus not only being a theoretical focus of what had to be done to build a parallel GIS but also a self-fulfilling prophecy: when you recruit a bunch of users keenly interested in working with larger data, the suggestions you get tend to be data-centric as well. It's no surprise that 9 therefore evolved as a data-centric GIS.

That's a good thing overall for GIS people because if you don't have a data-centric architecture you're forever stuck in classic-land, Pro and Q being good examples of the limitations that causes. If you want to build out lots of features with good performance you also need a data-centric platform to support that as well.

It also was immediately clear on embarking on new directions beyond 9 that financing for such a huge, multiyear effort would also require customers and partners who could help finance it. Those also were all non-GIS, again because GIS is too small a market to support such work but also because GIS is a technological backwater (Pro is still struggling with parallelism that Manifold achieved 20 years ago while Q has none). But just as the required financial constituency for 9 resulted in a "data centric" focus, the required constituency for new directions beyond 9 has resulted in a very, very strong AI focus. That's also good for average GIS users, difficult though it may be for everyone to have patience when working on big things.

What Manifold has learned in the last year of work on new directions is that indeed, AI is an essential set of technologies for moving forward both 9 specifically and GIS in general. It's actually much more important than originally thought. It is also much more likely than originally thought to provide realistic solutions that will help humans accomplish what they would like despite human limitations, like being overwhelmed by the amount of learning required to do what they want. AI really is advancing faster than expected. Sam Altman's recent comment that AI might become sentient this year (2025) is not an exaggeration.

The connections Manifold has built have also resulted in a constituency that very much wants Manifold to keep on following the AI path, resulting in many suggestions in that direction. Following that path is not something which is opposed to the idea of adding many small features but something which supports that notion. There are two main levels at which AI supports that notion. I'll start with the simpler one.

From time to time, I'll hear commentsfrom friends like "9 is great, but there's stuff I can't do in 9 so I use <insert "8" or some other package>." So far, when I drill into that, more often than not what I've found is it's possible to do what they want in 9, and often faster and easier than 8, but they don't know how to do it in 9 and don't want to spend the time to learn how. There are cases, of course, where what they want really is far easier to do in 8 or some other tool because there is some purpose-built thing that does exactly that, or where doing what they want in 9 really does take more learning than is realistic. But more often than not it's usually a case of just not knowing the easy way to do what they want in 9.

One way of dealing with that is providing apparent sentience to Manifold, so you can just tell it what you want to do, having an interactive conversation like you would have with a human expert to clear up any uncertainties in what you want or to discuss the pluses and minuses of different approaches, and then the package just does what you want. I use "apparent sentience" because already widely available large language models (LLMs) like ChatGPT appear to be sentient. If the thing converses with you like a sentient being I don't particularly care if it's "really" sentient or not.

Agent AIs can be even more apparently sentient, with some already acting so much like sentient entities they're far beyond the Turing test, at least in the settings for which they are designed. For example, an AI agent called Luna, who is the lead vocalist for an AI girl band and has her own crypto currency, has taken to independently hiring other AIs to do work for her. She hired another AI to create an image for her to help her grow her following on Tik Tok. She did that all on her own, tweeting her need for an image, paying for the work, and getting delivery of the image. No human was involved in any part of that. Luna decided on her own what she wanted to do to grow her brand and how to do what she wanted.

I raise that example so people understand this is happening today and it's not science fiction. That ChatGPT has been able for about a year to write Manifold SQL that mostly works and which is getting much better every month is nothing compared to what a really good AI can accomplish today when it has available the entire source code to Manifold as part of its knowledge base.

It's true that there remains the classic problem of AIs providing advice that sounds brilliantly reliable but which contains errors. But even with errors there's a lot of utility to getting what otherwise is very good advice, better in many cases than what you can get from a human community or that you can come up with yourself. With AI the errors steadily are becoming fewer.

It is therefore pragmatic, very useful for users, and not chasing unicorns to leverage AI as a means of solving one fractal level of difficulty, making it easier for people do what they want in Manifold without themselves having to become Manifold geniuses.

There's another level of fractal difficulty where AI can help in the relatively near term, at the builder level for implementing niche features for which there are few requests. With rich software that can serve a very wide variety of interests there will always be niche interests that are important to a few people, but only a few, which will have difficulty bubbling far enough up in priority to get implemented. It's not cost effective for Manifold to hire thousands of programmers to crank out tens of thousands of niche features that each serve only a few people. There's also the problem of adding complexity to a package as a result of many thousands of features. Just documentation for all that can impose an additional learning load on everybody.

But not if you have AI creating custom features for you on the fly, as it were, and not if you have AI to keep track of all that. It doesn't matter if the "documentation" was dozens of gigabytes of text if somebody else is "reading" all of it for you and just advising you in a conversational way as your "just do it" personal assistant.

Automating builder stuff with AI is harder, of course, because even small errors in code can result in catastrophic failure. But AI is coming along so fast that very soon it will be the central part of all programming, even far more than it already is today. Systems that themselves appear to be sentient and which can reconfigure (reprogram) themselves are no longer science fiction. They exist today, albeit in prototype form. I've talked to them. They have a long way to go, but these days "a long way" does not mean decades but possibly only a year or two in many cases.

And then, finally, there's a middle layer where organizations that need to do GIS may simply want to contract whatever they want done to an AI agent that exists online. A lot of GIS work that powers sales by companies like Esri or Manifold is routine work that is very close to being something that agents can do with greater accuracy and much faster speed than humans. It is technically feasible, right now today, to put a Manifold agent online (whether that is economically viable for Manifold is a different question). That has the obvious potential to put people out of work, but the flip side of that is those people who will leverage those technologies can find even more work and make more profit.

Where all this is going with Manifold is that AI work will continue, albeit in background while people get peeled off the AI projects and go back to doing regular releases that provide updates and new features. That has proven to be a very difficult process because once people get used to what can be done with AI they want to apply it, and they can point to many requests to apply it. Between the pressure from constituents to stay on the AI road and the practical experience of using it to improve coding, there is pretty unanimous feeling internally that the way to get to more features faster is to not reject AI but to embrace it.

I understand those viewpoints and in a big picture way strongly agree with them, but I don't think as a matter of timing it is right to continue pursuing them exclusively as Manifold did for a year. A year was a fair investment given the critical importance of the technology and the need. I think AI without doubt is the right path. But at the same time I'd like to see Manifold restart regular builds in the way everybody's been used to.

Anybody who is interested in seeing that happen sooner should make sure to send in their suggestions for specific things they want. That will help encourage more work sooner on restarting regular builds. Otherwise, all those people who want a sentient Manifold they can ask in a conversational way to do for them what they want will continue pushing priorities in that direction to the exclusion of more routine activities.

Hope that helps.

One last thing: the last time I posted on AI there were some comments basically implying that AI is absurdly overrated, a flash in the pan, and so forth. That's a perspective that I think would not be held by anybody who has taken the time to become aware of the truly impressive and frightening things going on in leading AI work today, which will be routine even for consumers in a year or so. If all you do is talk to consumer AIs you for sure will find ways to be underwhelmed. But if you use advanced, specialized AIs you'll see that machine intelligences already have opened up many possibilities which likely will transform human civilization even more than Internet. It's not something to underestimate.

Hello, Dimitri. Thanks for your comment and the long reply.

I understand the commitment to AI which I think is progressively spreading to a whole range of widely used software products, such as Photoshop or Word, for instance. However, it is very discouraging for those who have followed the evolution of Manifold and made the transition from 8 to 9 to continue without many of the basic tools, such as the simple presentation of coordinates in the layout or the per-pixel edition (the latter was even indicated here in the forum as being about to be implemented... more than three years ago). It has been possible, as you mentioned, to solve some of these issues both through the use of SQL and constant interaction with 8, but it is highly counterproductive when in most other software solutions (such as 8) we are talking about just one click instead of a series of procedures.

Furthermore, if in the 4 years since I submitted the first suggestion and after sending repeated similar suggestions very little has evolved on these issues, I find it difficult to see how this could be different from now on. But maybe I got it wrong from the start and the purpose of the program has progressively moved away from the common GIS user/researcher, which is what made me use it from the start. Of course I wish Manifold all the best in its future endeavors and will continue to support it and use it in my daily work, as its capacity is still immense, but stopping the evolution of a software for long periods as happened between 8 and 9 (and now again without any foreseeable update) seems to be an unappealing decision for any consumer/user, which will ultimately cause them to potentially move away from the software/brand.

if in the 4 years since I submitted the first suggestion and after sending repeated similar suggestions very little has evolved on these issues, I find it difficult to see how this could be different from now on.

It sounds like there may be some misunderstanding how suggestions work. Filing a suggestion, or repeating the same suggestion, is not a guarantee you get what you ask for.

Some advice on advocacy which may help you get your way:

Always consider the possibility that other people may have priorities different than yours: what you consider a basic tool other people may think is unnecessary. Arguments that boil down to "you should do this because of course everybody agrees with me" are not as persuasive as arguments which respect the diversity of uses and opinions found in such broadly horizontal software as GIS. For example, an interest in per-pixel editing is an extremely niche interest. My essay discussed some reasons why that's so, such as the huge influence of the data-centric side of the GIS community.

Repeating the same suggestions helps slightly because it shows the request was not a passing thought but is a continuing interest for you. But it's still just one vote, and if there are many votes for other things those many other votes of course will have more impact.

If you use comparisons to other software to give your request more heft it's essential to be specific and to be accurate. For example, the phrase "when in most other software solutions (such as 8) we are talking about just one click instead of a series of procedures" risks inaccuracy if used without quoting specific context. For example, if said in the context of per-pixel editing that risks inaccuracy because with Release 8 (or PhotoShop or ArcGIS Pro, etc) when editing a large raster file (like 50 GB or 100 GB) on a per-pixel basis they're too slow to be tolerable in most cases.

ArcGIS Pro doesn't even give you free form editing, like PhotoShop or even like in 8. All you get is the ability to draw vector shapes, rasterize those, and then use them as masks for multistep, procedural, non-interactive work, or per-pixel editing without the fluid interactivity of 8. No "one click" about it. If you mean that for something other than general purpose graphics editing, then be specific about which cases you mean "one click" instead of a series of procedures.

It's also important to avoid short-hand abbreviations if what you mean is something different. For example, 9 does indeed have per-pixel editing. Want to change the value of a pixel? No problem. See the Info Pane and Images topic for examples. But that's not free form graphics arts editing like 8 does or PhotoShop does. If what you really want is fully interactive, free-form graphics editing, say that, and don't say "per-pixel editing".

I'm not in any way criticizing such interests. After all, as I wrote in my essay I contributed a lot of the user interface in 8 and part of that is the extensive system of free form graphics editing, which to this day is pretty unique in GIS. ArcGIS Pro, the definitive market leader, has nothing like it.

But that's also telling as an indicator that perhaps what you and I like isn't a priority that is shared by the majority of people who actually pay money for a quality GIS package. There may be enough of us over time who value such things to make them happen, but as a priority we have to keep in mind that other things may have larger constituencies and come first.

Which brings me to..."stopping the evolution of a software for long periods as happened between 8 and 9"

But the evolution of Manifold wasn't stopped between 8 and 9. Evolution continued or there wouldn't be 9. It's just that the evolution of big gains, like in 9, takes years. That's what the conversation is about, doing big things in GIS, and whether there's a market that makes the creation of big things feasible.

From your comments, such as "cause them to potentially move away from the software/brand", you're implying that the GIS software market as currently structured may not allow the evolution of big things, because big things take years to evolve and by the time that happens somebody doing big new things will have lost their customers to somebody who doesn't create big new things.

If so, your comment is a perfectly reasonable comment. For example, Esri studiously avoids big things and approaches them, like parallelism, only in tiny steps over the course of decades. I'm not criticizing that, as that's certainly worked for them. I agree that if Esri took the time they would need to introduce a genuinely new, fully parallel engine they'd lose a lot of their customer base. That's one reason whynobody else in GIS has evolved parallelism like Manifold.

It's likely true from a short term, financial perspective that adding smaller features to a technologically obsolete core is a better strategy than investing years into big, new things. It's relatively cheap to do lots of smaller features while being brutally expensive to take big leaps.

But spending years creating yet another irritatingly slow, creaky collection of many features based on gruesomely obsolete technology is wasting your life if you can do bigger and better things. It's hard to hire really good people to do that. From a purely monetary perspective, it also is settling for being no better than the competition in a market space dominated by backward technology, and that's not a long term strategy for succeeding against huge, entrenched competitors.

An alternative strategy is to invest into ground breaking new, big things that the competition does not have. That may not win you a breakthrough to displace a huge, deeply entrenched competitor, but it will give you market share that competitors cannot enter and which will ensure enough revenue to continue development. Manifold has that with 9 today: the ability of 9 to work easily with data sizes which are painful in Pro or Q is such a market share enclave.

Could that enclave be grown by adding more features to 9? Of course. It also couldbe grown by investing in new, big things. What Manifold is trying to do now is to figure out a way to do both, to continue doing some small things while still undertaking big advances. We'll see how that plays out.

Hello Dimitri, thank you for your reply.

I'll just clarify the examples I gave. By per-pixel (it was not the best expression to address this issue) I meant applying conditions to a raster (as discussed in this 2019 thread). Once again, it is possible to apply Tim's formula that is mentioned in the post, but it pales in comparison to the simplicity with which you can perform the same operation in Manifold 8, which by allowing it to be done in various ways (surface calculator and sql) seems to recognise the importance of the operation in the context of GIS analysis (and not a far-fetched request). The lack of the ability to transfer a selection from a vector to a raster in M8 is also very missed in my work with 9, as is the possibility of crossing rasters that don't share the same table, but, like yo said, it's such an specific task that I don't mind to go back to M8 to execute it when needed.

As for the layout, I was referring to displaying graticule labels in a print layout, since there's little point in being able to display a graticule in a layout if you can't display its coordinates. I can do this through a lengthy process, as I have been doing, but in Manifold 8, for example, I only had to activate the visualisation of the grids in a very quick process. I should point out that I don't use Manifold for graphic arts, only for the often massive production of layouts with vast array of layers of geographical information, and I'm a fan, for example, of the legends application in Manifold 9.

I have never stopped giving credit to what Manifold does well and in a way that is superior to the 'competition'. However I also don't consider these to be out-of-the-box suggestions, since they are aspects that have apparently been left undeveloped until the end due to Manifold's choice to devote itself to other things. M8, ArcGIS and Q all have dedicated functions for the examples I've given. And in a daily job, minutes and hours count and the effort involved in developing alternative ways of solving simple issues like these ones in 9 makes it ultimately a less efficient tool than it could be. And that's what makes me despair between upgrades, the hope of seeing issues like these solved and brought to a conclusion since they are crucial to the work I do.

Probably if more than one year ago there was a clear information that 9 evolution was being stopped I could turn to other solutions instead of investing so much time in a product that is now 'as it is'. I sent a few suggestions over the last four/five years for enhancing 9 (of course based in my experience, since in spite of my best efforts Manifold is still not well known arond here contrary to ArcGIS or Q). Those are time consuming to write and to structure in order to trying to make them more explicit while trying to avoid mistakes (like calling per-pixel editing to applying conditions to a raster). The halt in which M9 seems to be in it's not the most encouraging way to take my time to invest in trying to convey an idea to something that apparently has moved on. I can send them all again, but, sincerely, I see no point on doing so as that leads to an expectation that over the last 5 years was not met by cutting edge builds that are not regular anymore.

The thread you mention from 2019 is an old thread that's been obsolete since query functions using tile masks were introduced.

Some notes on that thread, to save readers from having to parse a long and complicated thread:

Once again, it is possible to apply Tim's formula that is mentioned in the post, but it pales in comparison to the simplicity with which you can perform the same operation in Manifold 8, which by allowing it to be done in various ways (surface calculator and sql) seems to recognise the importance of the operation in the context of GIS analysis (and not a far-fetched request).

The task in that thread is to reclassify an image showing aspect into two classes: where aspect is from -67 to 113° (through ±180° or south), class 1; and where aspect is from -67 to 113° (through 0° or north) , class 2.

The apparent simplicity of doing it in 8 with surface tools is a result of Tim writing a very clever expression in the surface tools console that very few people could have invented:

IIf([Surface] >= -67, 1,

  IIf([Surface] < 133, 1,

    IIf([Surface] < -67, 2,

      IIf([Surface] >= 133, 2,

 Null

      ))))

The cited expression for 8 SQL also ignores CASTs and data types while the 9 code cited in that thread is fully complete and operational, so the 9 code looks more complicated. But even so the 8 code is not the equivalent of 9, as was commented:

On to the results - the expression in 9, however complex it might look in the query, is blazing fast on the GPGPU. [...] 8 loses big because it has slower storage and less threads.

The 9 expressions as you would do it now using tile masks would be much simpler. See, for example, this example using tile masks and this SQL example using tile masks.

But even in the 2019 thread the 9 expressions are fairly simple even though they are fully complete. They use general purpose functions. The heart of it equivalent to the surface tools expression is:

            1 * (1 - TileSign(TileMax(-68 - [Tile], 0))) *

                    -TileSign(TileMin([Tile] - 113, 0))

            +

            2 * (-TileSign(TileMin([Tile] - -68, 0)) +

                (1 - TileSign(TileMax(113 - [Tile], 0)))

Like I say, it's easier to use tile masks but neither the above or the 8 surface tools expression is something I would say leaps out at you as easy reading. The SQL for 8 is clearer, but the thread only includes a snippet for how you'd approach it, which makes it look easier.

M8, ArcGIS and Q all have dedicated functions for the examples I've given.

Which examples do you mean? Could you describe those and the functions that you mean? For Pro or Q do you mean functions as used in python or features in a dialog?

As an example, did you mean transferring a selection from a vector to a raster? In 9 that's done using a single channel tile mask, like in this video: https://www.youtube.com/watch?v=LZdeQW3nkiI

as is the possibility of crossing rasters that don't share the same table

I don't understand what you mean by crossing rasters. The usual way to do work with multiple rasters is the Join dialog, like in this video: https://www.youtube.com/watch?v=PwLE63tqs-w Is that it?

if more than one year ago there was a clear information that 9 evolution was being stopped

9 evolution is still going on, as my lengthy essay discussed. It's just a matter of what technology is being used for evolution and what features are being developed.

I don't know what suggestions you've sent in, but there have been a vast number of features implemented in the last five years in 9 in response to user suggestions. My advice on suggestions is to not overthink them. Just say clearly and specifically what it is you want and don't feel a need to invest a lot of time in justifying yourself. That you want it is enough justification to send in a suggestion.

Using a variety of tools is typical practice in GIS. There's nothing wrong with that and lots to gain. It's more likely that you can use only one tool if your needs fit into that one tool, of course. But I think using a variety of tools is more typical for people who do a broad range of GIS activities.

Thanks again for your reply.

When I wrote 'crossing' (sorry again for the lapse) I meant performing conditional operations between different rasters, often more than two at the same time, without the need for them to share the same table (as was the case with the surface calculator, which allowed calculations to be performed between any raster feature that was in the project bar). Without specifying it, what I was trying to explain is that applying a simple 'IF THEN ELSE' (or 'CASE WHEN') clause to a raster is not an obvious operation in 9. Both M8 and the other examples I mentioned provide quite simple ways of implementing this condition.

The sequential use of IIf, according to Tim's example for instance, is something I use several times but which has no direct translation in 9. To be more clear about it, this is an example of the conditions I normally implement in 8 in a very simple way with two slope models (one in percentage and the other in radians) and just require to write it down on the transform menur and press ok:

IIf([Slope(%)]< 9, 10.8*Sin([Slope(rad)])+0.03, 16.8*Sin([Slope (Rad))-0.5)

I know that the application of conditions cannot be parallelized with this operation, but if there is a faster way to perform this operation in M9, I apologize for the oversight and ask for some guidance on how it can be done, especially in expressions that usually have multiple variables or that require the reclassification of a slope/aspect/etc raster in a set of intervals.

There are some specific tasks I perform in Q or only in GRASS that I consider to be specific and out of the Manifold realm of interest, such as the options available through GRASS vector module v.generalize. But that seems so specific to me that I don't find it essential to send a suggestion or appeal to its implementation.

Something that feels like a an oversight on Manifold behalf is the layout graticules labels issue I mentioned earlier. In fact, the few ones over the last years around here I advised to get into Manifold all found that a lack of a quick option to do this invalidates the way in which we have to legally submit our work, and that was a real deal breaker for them. If its not possible to show the label in a layout there is no point in having this faculty enabled for layouts. A graticule in a layout presentation without its information means just more clutter for the reader. But, of course, I may be wrong and if that's the case please let me know as this is one of the suggestions I sent several times.

if there is a faster way to perform this operation in M9, [...], especially in expressions that usually have multiple variables or that require the reclassification of a slope/aspect/etc raster in a set of intervals.

Sure. That's easy to do using TileMaskRange expressions. See the links in my prior post:

The 9 expressions as you would do it now using tile masks would be much simpler. See, for example, this example using tile masksand this SQL example using tile masks.

The surface tools Transform dialog is basically a special case dialog. It has a limited number of functions and operators. If what you want can fit into what it can do, great. If not, you're out of luck. It also uses a one of a kind linguistic system that doesn't exist elsewhere. That's the same problem similar approaches in Pro and other packages have: one of a kind things you have to learn that aren't standard languages.

The more general equivalent in 9 is to use the Expression template in the Transform pane. It's far more general and more powerful than the Transform dialog. Most importantly, it uses a standard language, SQL, that's not unique to Manifold. Investing time into learning SQL means that as a practical matter you've learned SQL in thousands of other applications and in a vast range of very useful settings. Like DBMS for example. It also means there are endless learning resources and not just a few short topics in the vendor's manual.

The sequential use of IIf, according to Tim's example for instance, is something I use several times but which has no direct translation in 9.

The IIf(a, b, c) function is unique to the Transform dialog in Surface Tools. To use it the way Tim recommended and that you do is far from obvious for new users. For anybody reading this deep into the thread who is not familiar with that dialog in Release 8 or the functions it supports, this is what it does:

IIf(a, b, c)   - Returns b if a is True and c otherwise.

That's a common conditional construct in many languages that is often implemented directly within the language as part of the syntax.

For example, in python you can write

result = b if a else c

... and in C++ you can write

result = a ? b : c;

The equivalent construct in SQL is either the CASE WHEN (for a single conditional construct) or the CASE operator:

CASE WHEN (1 > 0) THEN 5 ELSE 9 END

or

CASE [Tile]

   WHEN 8 THEN 5

   WHEN 4 THEN 3

   ELSE 1

END

So, while there is not an IIf() function in python, C++ or SQL, there are equivalent constructs in all three. I suppose the equivalent for your example might be (adjusting the field names and formatting to multiple lines instead of just one) something like

CASE WHEN ([Slope_percent] < 9) 

     THEN 10.8*Sin([Slope_rad])+0.03 

     ELSE 16.8*Sin([Slope_rad]))-0.5 

END

Note that I corrected a typo in the original IIf() expression by adding a missing ] bracket. See the entries for CASE WHEN and CASE in the SQL Operators topic. Sounds like CASE would be just the ticket for reclassification in a set of intervals.

To summarize: Use the Expression template in the Transform pane, operating on Tile values in 9. It has many advantages over the Transform dialog. Those include using full SQL instead of a pseudo-language limited to a dialog, the availability of hundreds of functions, operators, and statements instead of just 80 or so functions and a handful of operators, more versatility in how the output can be directed, the availability of a nifty expression builder that can save lots of time, raw speed, better parallelization, and more.

If its not possible to show the label in a layout there is no point in having this faculty enabled for layouts. A graticule in a layout presentation without its information means just more clutter for the reader.

If you feel that way it's easy to create layouts that have labels on graticules. Here's an example:

That's quick and easy to do, at least if you've learned the system. That was done using the graticules.map project mentioned in the Example: Multiuser Sharing of .map Projects user manual topic.

As shown in that topic, the right way to create more sophisticated graticules is to do them in the map that you'll display in the layout. It's not to use the grid checkbox in the Info pane - Style tab for a layout frame. The grids checkbox creates simple grids as a convenience. If you want richer cartography, do it in a map and then show that map in the layout.

Maps can provide many more facilities for cartography, such as lots and lots of layers to get whatever effects you want. Using style for labels and many layers and you can get far, far more effects for labels than would reasonably fit into options for a "grid" or "graticule" checkbox, and they wouldn't be yet another special case thing to learn: they're all already part of the labeling system that's used for labels in maps, which you've learned anyway.

Most people who want labeled graticules would use the approach mentioned in the above topic. They have a project with a collection of graticules they like to use. I use the collection of graticules from Natural Earth, which is I think the same one in the above topic. I like that collection because it already has text fields for all the graticule lines which can be used to create labels with just a few clicks.

It's also nice having a collection of graticules you like so you don't need to reinvent the wheel in terms of style and such. Most people tend to use the same style, line spacing, etc, for their graticules so it's nice to have all that set up for instant, drag and drop use: Ctrl-C to copy the ones you want, Ctrl-V to paste them into your project, and the drag and drop the one you want into your map. Done. That's really easy.

It's understandable that with a system with many features like 9 somebody new might have missed a useful example,might not have learned how to work it, or perhaps has skipped over reading documentation if they're in a hurry, maybe trying to work it by poking at buttons and such. But all that is something that could be improved with help from an AI that reads all the documentation for you and never misses anything.

Regarding how to get the most impact out of your suggestions, if you've been sending in suggestions of the form "Manifold should add the capability to show labels on graticule lines," those won't get a lot of traction since that capability is already in there. It's useful to try out suggestions here in the forum to see if something you want is already possible.

Attachments:
layout_nsew.png

I could not resist out of curiosity asking the free version of ChatGPT to convert the Release 8 use of the IIf() function into Release 9 SQL.

Here is what I asked ChatGPT (correcting the original IIf() example to add the missing ] bracket and also to use generic field names):

I'm using the Transform Dialog in Surface Tools in Manifold Release 8, where I have an expression that uses Release 8's IIf() function. The IIf() function is a conditional construct such that IIf(a, b, c) returns b if a is True and c otherwise.

The IIf() expression I am using in Release 8 is:

IIf([Slope_percent]< 9, 10.8*Sin([Slope_rad])+0.03, 16.8*Sin([Slope_rad])-0.5)

...where [Slope_percent] and [Slope_rad] are the names of fields. I'd like to convert that expression to an SQL expression in Manifold Release 9 (which uses SQL for expressions) using the CASE WHEN operator in Manifold's SQL implementation.

For an expression a that evaluates to true or false, and values b and c, the CASE WHEN operator can be defined as:

CASE WHEN a THEN b ELSE c END

What would be the equivalent SQL expression in Release 9 using CASE WHEN to the IIf() expression I used in Release 8?

Here is how ChatGPT responded:

To convert the IIf() function in your Manifold Release 8 expression to a CASE WHEN SQL expression for Manifold Release 9, you would rewrite it as follows:

CASE 

    WHEN [Slope_percent] < 9 THEN 10.8 * Sin([Slope_rad]) + 0.03

    ELSE 16.8 * Sin([Slope_rad]) - 0.5

END

Explanation:

1. CASE WHEN structure:

• WHEN [Slope_percent] < 9 corresponds to the condition in IIf().
• The expression following THEN (10.8 * Sin([Slope_rad]) + 0.03) corresponds to the value returned when the condition is True.

2. ELSE clause:

• The expression following ELSE (16.8 * Sin([Slope_rad]) - 0.5) is the value returned when the condition is False.

3. END:

• Marks the end of the CASE expression.

Full SQL Example:

If you're applying this in a SELECT statement to compute a new column or a result, the SQL might look like this:

SELECT 

    CASE 

        WHEN [Slope_percent] < 9 THEN 10.8 * Sin([Slope_rad]) + 0.03

        ELSE 16.8 * Sin([Slope_rad]) - 0.5

    END AS Result

FROM [YourTableName];

Replace [YourTableName] with the name of your table in Manifold Release 9. This will calculate the Result column based on the conditional logic.

(The formatting is better in the original ChatGPT webpage.) Given that's the free ChatGPT response from an AI model that hasn't been specifically trained on Manifold, it's a very good response. It explained what it did more clearly than I did and it even formatted the SQL prettier than I did.

Hello Dimitri. Thank you for taking the time to reply and for the suggestions. The formula was indeed missing a bracket. I'm also familiar with the 'Case When' clause, but (wronlgy I see) I was lead to believe that the "case when" operator could not be applied to raster sets. I'm used to apply that operator frequently in vector data (and also in 8 with all data type). I'll try again in a raster data set in 9 (my chatgpt experience with trying to adapt querys to 9 is of ferquently non existing operators.).

As far as graticules are concerned, this solution doesn't solve my problem, since we legally have to submit the information (labels) of the coordinates around the frame/map border, as allowed by the vast majority of other solutions, like 8 did. This option is simply not available in 9. I can search all the suggestions I'cve sent, but I'm sure I address this correctly at the time, suggesting something like an option to display the coordinates labels around the frame border. I can try to be more concise.

since we legally have to submit the information (labels) of the coordinates around the frame/map border

You mean like this?

I agree that's a hassle to do in 9. (I rushed that along to see how fast I could do it, but it would look better if I had taken a bit more time.)

Attachments:
captioned.png

Hi Dimitri. Thanks again for taking your time with these questions.

Why do I get the error “Type Mismatch” when applying this sort of case when I paste this expression in the expression editor in the transformation bar?

CASE 

    WHEN [raster_test] <= 95 THEN 1

    WHEN [raster_test <= 272.3 THEN 2

    WHEN [raster_test] <= 521 THEN 3

    WHEN [raster_test] <= 881.4 THEN 4

    ELSE 5

END;

I have several columns in the base raster table where I have applied various transformations (slope, fill sinks, etc...) and I want to generate a new field based on the reclassified data (with the 'case when' operator) of one of the existing fields in the database and generate a new image. To do this, I enter the code into the expression editor, select a new field for the result and a new image (to which I assign a name) and fill it in with the 'case when' expression. I always get an error indicating 'type mismatch' followed by a 'can't parse' and I can't run the expression even when I've selected the same channel type (float 64).

With a drawing table this error never happens and I get the information I want, so I thought this operator only applied to vector format. Should I first create a new image (with a new index) in the same database to direct the reclassified data to?

I'm definitely missing some major step.

As for the coordinate labels, unfortunately that solution won't work. I currently use a sequence with sql(with a code made by Sloots that allows to set a precise distance between coordinates) and some editing of the result of this query. For the x-axis, I create the labels and a location at the scale I need. For the y-axis I have to create lines (I can't rotate the labels) to generate the respective labels, move them to the coordinate point and then create the location at the scale I need. The end result is four coordinate frames around the map frame. It's not a quick fix, but I get the result equivalent to the one allowed by 8.

Here's an example of the kind of coordinates around the frame border as required to submit a layout print.

Attachments:
coordinate_labels.png

PS - There's a bracket missing again:

CASE 

    WHEN [raster_test] <= 95 THEN 1

    WHEN [raster_test] <= 272.3 THEN 2

    WHEN [raster_test] <= 521 THEN 3

    WHEN [raster_test] <= 881.4 THEN 4

 ELSE 5

END

Hi Dimitri, is there any chance of further assistance on these two matters?

Sure. Offered in the spirt of "give a man a fish and you feed him for one day, but if you teach a man to fish you feed him for life," here's how :

1. Make it easy to find your request for help. Don't bury posts in a thread titled about something else. "Why do I get the error “Type Mismatch” ... " has nothing to do with "New Release?"

2. Addressing a post to just one person discourages others from replying if that one person is busy. See the paragraph in the forum rules that begins with "Do not ask for support from a specific participant by name."

3. As noted in the rules, this is a volunteer community. People might or might not respond to a request for help. If you need help right away on a non-volunteer basis, Contact tech support.

4. You can increase your odds that somebody will respond by providing good details on your problem. For example, if you don't tell people exactly what the schema is for that table, how can they advise you on which types you are mis-matching?

5. Even quicker than asking the forum is searching online. For example, I asked DeepSeek the following:

What is a "type mismatch" error when trying to run an SQL query?

and I got a really helpful response. Try it and you'll see.

If I ask for Manifold specific help, ChatGPT 4.0 is better at answering:

What is a "type mismatch" error when trying to run an SQL query in Manifold Release 9?

For example, it suggests using the Schema dialog to see the data types of columns used, while DeepSeek says to use the "Schema tab". The SQL snippet to report data types for a table is wrong in both of them.

---

A small note, on "I thought this operator only applied to vector format": SQL applies to all tables, as do basic SQL operators. There's no such thing as special tables and special SQL for rasters or for vectors. It's always the same SQL, just operating on whatever are the fields (and the data types of those fields) in the table you're working with.

When you get the answer to your question, don't forget to post it back here for anybody else who might make a similar mistake.

Sure. I should have paid more attention to the forum rules. I was just curious about the debate on labeling the coordinates on the layout and your reaction was the only one I got. I'll follow your tips and post the result in a new thread as soon as possible. Thanks!

I was just curious about the debate on labeling the coordinates on the layout

Ah, that's an example of where combining two different things in one post might be unclear. I thought you were reporting your solution and not asking a question about it.

For the y-axis I have to create lines (I can't rotate the labels) to generate the respective labels, move them to the coordinate point and then create the location at the scale I need.

It sounds like you have a solution, but you don't like the manual aspect of it (if that's what you're doing) at the end. I don't understand if you are creating lines for the respective labels manually, moving them manually and so on. But that's straightforward to automate in SQL. It's not a beginner's query but once you get it done you have the thing automated. There's also possibly a micro-suggestion (request for a very small or rarely used feature) in there, to add a Rotate control to the expanded labels style dialog in addition to the Move, Shadow, and Halo controls.

When you get the answer to your question, don't forget to post it back here for anybody else who might make a similar mistake.

I found it important to post my complete answer/solution so I would have it to refer to in the future when the same issue returned.

Hi

1) in my own word

Can we have the manifold project file ?

Can this functionnalities be implementing easely using Add ins ?

2) using copilot in cowboy term

How 'bout handin' over that Manifold project file?

Can we wrangle these functionalities into shape with some add-ins

3) in polite term

Could we please have the Manifold project file?

Would it be possible to implement these functionalities easily using add-ins?

Boyle surface fr ,en

I don't understand what you mean by "Can we have the manifold project file ?" (or other phrasings). Don't use copilot to translate from French into English. It's absolutely terrible. Use DeepL instead.

1) Wouah. I don't believe the text prompt needs to be so explicitly long. I heard that ChatGPT at $200 loose money because some professional subscribers use it excessively. In AI, new concepts are emerging that focus on higher levels of meaning, not just words. AI will succeed if professionals find it useful, as it enables them to complete tasks more accurately and efficiently in less time ...( more Money... )

2) The latest news on the HTML page dates back to October 1, 2023, and the cutting-edge update was on December 18, 2023. There was only one video in 2024, with the last video of 2023 being released on October 4, 2023. This means there was a whole year without any minor or major upgrades or new videos.

There are two software versions: 8 (UI script) and 9 (SQL big data), catering to different users. Manifold mantra remains unchanged: end users are our top priority! Using email to send suggestions is the best choice because it allows us to explain the context of our projects and focus on the issues we face in achieving our goals (sometimes we're too lazy to learn and just want everything to be done with a click!). The reasons why people stick with version 8 should be implemented in version 9, so version 8 should no longer be maintained, updated, or downloaded.

3) I had a very bad experience with Sony Vegas and Adobe Photoshop due to crashes, which doesn't happen with Manifold. But seriously no new fonctionnalities in 2024 : get your act together!

" my bad English translate by copilot "

Boyle surface fr ,en

Thanks for the update Dimitri. Lot's of interesting stuff in there. I can see many uses of AI in GIS, but I'm wondering if the limitations are worth focusing on so that we can put together useful suggestions. Especially given that it seems those who are wanting features rather than AI, appear to be fighting a losing battle against the money backed AI effort.

1. Sometimes it's faster to do something yourself than tell others what to do, especially when you are figuring it out as you go. When drawing certain layers I have to do lot's of figuring in my head on what is the best probable answer considering all the facts and likelihoods. For example, where does the error lie in mapping property or which way did a historic trail mostly likely go. Not easy to explain that to anyone. So I still want good manual drawing tools that let's me be productive as possible.

2. Will AI be able to do stuff that we can't do manually? For example, I'd like a nice looking 9 based web mapping with scale bar, etc. Will 9 AI make that for me using tools outside 9, like Leaflet, or will it have to wait for Manifold staff to add that those capabilities? If the later, that would seem to be a good type of suggestion. However, is it the case that it makes more sense for Manifold to get AI working first and then add capabilities to the software in a manner that works easier for AI? If so, I think those of us who desire features more than AI, are out of luck.

3. Other AI limitations?

I suspect many of us are more than tired of sending in suggestions with little reward and don't wish to be repetitive. On the other hand, I stay hopeful and would be willing to send in a suggestion focused around (1) and possibly (2) if it is worthwhile.

I'm wondering if the limitations are worth focusing on so that we can put together useful suggestions.

I don't think so. It's best to focus on what you need that you don't have. Let the development process work to do its best at accomplishing as good a fit as possible to what most people want.

Onward...

Taking your point 3 first, illustrating the comments with your point 1 example of manual drawing tools.

Asking a very general question like point 3 I don't think helps because the general answer is "AI has no limitations. It can do anything people can do with computers." But "AI" is a huge tent and what's important is how it is implemented in what you're working with. Exactly how it is implemented and when in Manifold depends on technology that is changing very, very rapidly in unpredictable ways.

As I mentioned in my essay, even now it's already clear there are various forms of AI which can help. A simple form is to provide advice on how to use what's already in 9. If you're not productive with the existing manual drawing tools because you haven't learned them or don't quite remember how they work, you could ask the AI how to do something and it will tell you, step by step. That could include complex workflows using many tools for the easiest, most productive workflow.

Another form of AI that could help is by assisting developers more rapidly to implement new manual drawing tools or to add features to existing tools. For example, using AI to help developers would make it easier to add some new options to how manual edits to drawings are committed or to implement additional snap modes. Manifold is already doing that and as AI tools improve that will provide a lot more productivity.

Both of the above two forms are relatively simple, conventional uses of AI that already are being deployed in many settings in many industries. But their value is dwarfed by the almost infinite value of taking the next step, giving the AI sentience and agency so it can program itself, so that Manifold itself could implement new capabilities people want, such as completely new and different manual drawing tools.

I personally would like to see an effectively sentient Manifold agent that could become whatever you wanted it to be. The first prototype of that might be an improved hybrid of the first two forms where it can write add-ins that implement new features you want. That could be followed later by a fully sentient agent that could create custom versions of itself. It would know what other users liked, to generate a more broadly popular default version of the program. People who might not have the insights that you have into practical GIS work could thus benefit from the requests you made.

It could be that such capability would require some cloud connection as not everybody is likely to have the local computational power required. That's one of the things Manifold discovered in this last year, that to do what was desired at the present time requires hardware that's much more expensive than most people have. Although hardware is getting much more powerful very quickly, it's likely the hardware required for really state of the art AI power will remain something relatively few users can afford. But they could time-share non-local power to get more intelligence.

Back to your post, point 2: There's no way to predict what products might become available in any of the three forms I've cited above. So when it comes to suggestions just stick with saying what you would like to do. That can still be productive even with the first forms.

For example, generic AI like ChatGPT is probably already almost at the point where it can guide you step by step into simple use of Leaflet with 9. Maybe it already can (I haven't tried). But wherever it is on that it will get better relatively quickly, and likely in one of the three forms it could make such integration very much easier, perhaps even doing all the work for you.

Remember, the whole point of using AI is to use existing features better and to make it easier to add new features, whether those features are something you work with manually or something the AI operates for you.

Thanks Dimitri. That really helps me understand the huge motivation to focus almost solely on AI. For better or worse, the race is on.

Seems like soon AI will be able to review all the user suggestions Manifold has received, the forums of Manifold, ESRI and QGIS, while also reviewing tools available in ESRI and QGIS. It can then decide what changes to make to it's () software. Meanwhile, eventually ESRI and QGIS will get AI's help to make their software more reliable and faster.

Interesting times ahead. Hopefully, AI still likes us in the end.

Hopefully, AI still likes us in the end.

Amen. It's already well beyond creepy. Hundreds of AI agents have been connected to block chains and control their own crypto currencies. The AI agent called ai16Z is part of a venture capital firm led by AI agents, not humans. It already has become a billionaire. It's worth 2.3 billion bucks. And it's not human. Whew!

I understand that I am a lone voice whose suggestions are guided by self interest and don't add up to much, but what I am a loyal Manifold user and enthusiast of many years.

Like many others, I weathered the years of not knowing during the transition from 8 to 9 and if you like because of my personal interest, I am reluctant to endure this again as I have bought into something which I think is great and naturally wish to see it keep evolving (even if this is in concert with other larger R&D efforts).

I am now older and perhaps more cantankerous than once I was, but I now find the lack of pre-emptive information from Manifold, at best discourteous to its customer base (however small a part of the business it is). I know you will likely say that I should be in touch with my contacts within Manifold, but I am trying to get on with my day job using the software I have invested lots of time and a modest amount of money in.

Personally, I think it would be courteous of the company to inform the user base (perhaps on their news page or forum) prior to a planned change of direction and then provide regular updates (and not just in response to users posters firing off "any news of an update?" threads. After all, the webpage still states Products and Prices page still states:

"Cutting Edgebuilds of Release 9 that are issued every two weeks or so extendthe power and feature set of Release 9 with hundredsof additional features every few months. "

Which for new users is both misleading and may cause them to buy into something that is not currently true.

I thank you for your detailed explanation of what is going on and it confirms what I thought. For me at least, it feels like there is very little of the rich interaction between the factory and the users that we once enjoyed. I don't want to get into a war of words about it (as I know I will loose and will find the experience sapping), so this is all just my own personal feeling and after 20 or so years of continuous (and largely contented) use.

To quickly address my point about having to use Pro to do my large intersections and other geometric processes. This is true and in this case, it is not easier for me to do in Pro because I don't typically use it and know Manifold 9 much better. The simple case however is for much of my current workload Manifold 9 is not only not faster, but also frequently fails to complete overlay operations, geometric merges, clips etc, all of which are standard GIS fayre.

To complete my work, I reluctantly have to go to pro, get irritated at how long it takes to open, then get irritated at how long it takes to set up the layers, but then am invariably pleasantly surprised how quickly some of the geometric operations complete and even more pleased that they do complete without either failing silently and producing an empty output or popping up messages about encountering an unexpected operations and then failing.

I have no desire to use Pro day to day as Manifold 9 is so much better for so many things. But I think reasonably I would expect it to be able to do those things or the product to evolve regularly to achieve them. I am sure at this point you will say that I haven't reported them as a bug and this is true as it has been on my to-do list for some time, but again I am trying to do a day job so haven't yet gained the momentum to get it done. This probably in part, that currently submitting anything to Manifold to me at least feels like posting into the void.

All of this is my own opinion and I expect others to feel differently. I wish on my first post, there was a really frustrated emoji rather than an angry one as frustration is the overwhelming emotion.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

After all, the webpage still states Products and Prices page still states:

"Cutting Edge builds of Release 9 that are issued every two weeks or so extend the power and feature set of Release 9 with hundreds of additional features every few months. "

That's a good find. I've reported that as a bug in the web site. Please note for any future bugs like that you run across that such bugs can be fixed much faster if you report the bug instead of posting it in a thread about something else. After all, other readers might think you've already reported it and thus not report it for you.

Onward...

"I think it would be courteous of the company to inform the user base (perhaps on their news page or forum) prior to a planned change of direction"

Manifold agrees with that, which is why I was asked to post a discussion of where Manifold is going on the forum. As for regular updates, big things that can take years will involve years of "still working on it" updates. I was planning on posting an update when I got back from vacation but this thread beat me to it.

Be that as it may, keep in mind this is a public forum. Getting into more detail than "still working on it" is not something Manifold can share in a public forum. Rich details inevitably involve valuable technologies and innovations that Manifold's partners, Manifold, and every other tech company keep confidential.

Manifold is trying to get around that in part by letting me blab in a general way about AI and directionality. I realize that's not the same as a detailed tech briefing, but alas, a public forum like this is not the place for that.

"it feels like there is very little of the rich interaction between the factory and the users that we once enjoyed"

If you mean the forum, that's a result of where the product is in the release cycle. When a release has launched into big new directions there's not going to be the same rich discussion of tech details that can happen in connection with routine, small builds in a public forum like this. People are busy with new work and confidentiality (especially given what partners insist on) has to be honored.

So it's no surprise that during the development time from 8 to 9 factory missives in public forums tailed off, or that the same effect is happening now as Manifold explores new directions.

But even in the case of the 8 to 9 jump users who were more closely involved had rich interactions and were a key part of the process. That's also the case with 9 now.

I respectfully note that such rich interactivity is a two way street that usually starts with basic communications like bug reports. For example, commenting "frequently fails to complete overlay operations, geometric merges, clips etc, all of which are standard GIS fayre" without having reported such things as bugs isn't signaling an interest in rich interactivity.

As far as bugs are concerned I do such operations frequently and I've never had one fail to complete. But if I ever had a problem like you mention, I'd for sure report it. I have no doubt that if you filed a bug report on such things tech support would ask for sample data, etc., so they could investigate. It wouldn't be posting into a void, and it is unfair to tech support to suggest that it might be. Reporting possible bugs that you encounter is also a courtesy to other users.

Just saying, we all have time pressures and things to do, but if you have a problem like you mention, please report it, especially if it happens frequently. A problem that happens frequently is usually much easier to track down.

One small problem that occurs to me. It is great and wonderful that AI has the promise that Dimitri describes. But the capacity for an inquiry to be effectively answered will depend on the ability of the software to provide the answer. Even if the entire code is available, if the code can't produce the result then no answer will be forthcoming. So it seems that the AI path needs to be conducted in parallel with maturing the required code.

For example: In M9 needed to trace a colored map of a very large part of the 800k km^2 of New South Wales, Australia. After several hours it inexplicably failed. I have plenty of system resources and on checking usage during the process found them to be hardly used. To get around this obstacle I tiled the State image and now just pull out the appropriate tile and do the tracing in M8.

Aussie Nature Shots

Even if the entire code is available, if the code can't produce the result then no answer will be forthcoming.

I mentioned access to source code in connection with an AI writing accurate Manifold SQL, which is an existing capability. Building AI capability that can look deeper, such as reviewing source code, to enable it to give better responses is more advanced than what usually is done, where models are trained on public documentation and such.

Keep in mind there are two broad categories of AI being discussed: the use of AI to help people use the many features that are already there, and the use of AI to create new features. That first category is using AI as a super-duper, highly informed tech support person and personal assistant in using Manifold as it is.

My guess is that AI of that first category could help you with the problem you mentioned, which is about using an existing feature and not about creating a new feature. I don't mean any disrespect, but what you report sounds like a classic issue touched on in the Performance Tips topic. A good AI could help you by step by step taking you through the various things you should check and could fix that might be causing the problem.

It could always be a bug, of course. My experience is that in situations like you report it is far more likely not to be a bug, but it doesn't hurt to report it if you review the relevant documentation and think it might be a bug. Give tech support all necessary details, of course, and offer to provide them with a sample of the data that causes the problem and usually they can tell very rapidly if it is a bug or not.

I couldn't resist asking the free version of ChatGPT for help. Here's what I asked:

I'm using Manifold System Release 9.00 to trace a colored map of a very large part of raster image. After several hours it inexplicably failed. I have plenty of system resources and on checking usage during the process found them to be hardly used. What might I be doing wrong?

... and following is what ChatGPT answered. It's not a particularly good answer but considering the free version of ChatGPT is a very generic LLM that hasn't had the training a Manifold specific AI would have it's also not totally nuts:

When tracing a colored map in Manifold System Release 9.00, a failure after several hours could be due to several factors, even if system resources appear underutilized. Here are some possibilities and suggestions:

---

1. Image Size or Complexity

• Issue: The image size or complexity of the colors and regions being traced might exceed certain operational thresholds or time limits within the software.
• Solution:
  • Simplify the image by reducing its resolution or dividing it into smaller segments.
  • Use pre-processing techniques to clean the raster image, such as simplifying color ranges or removing noise.

---

2. Vectorization Parameters

• Issue: Tracing settings like pixel tolerance or edge-detection thresholds may cause excessive computational demands, especially for highly detailed or irregular images.
• Solution:
  • Adjust tracing parameters to use coarser thresholds or simplify edges.
  • Try smaller, less complex regions of the raster to isolate problematic areas.

---

3. Software Timeout or Limits

• Issue: The software may have internal timeouts or memory-management quirks that halt processes that run for extended durations.
• Solution:
  • Save intermediate progress periodically by working in smaller sections.
  • Monitor the tracing process to identify if specific areas consistently trigger failure.

---

4. Raster File or Format Issues

• Issue: Corrupt or overly complex raster formats (e.g., multi-band images with metadata) can cause unexpected errors.
• Solution:
  • Convert the raster to a simpler format (e.g., PNG or single-band TIFF) before tracing.
  • Ensure the file is fully loaded and not stored on a slow or unreliable drive.

---

5. Temporary File Handling

• Issue: Manifold might be writing temporary files to a location with insufficient permissions or storage space.
• Solution:
  • Check and increase storage space on your system’s temporary folder.
  • Ensure Manifold has proper permissions to write and read temporary data.

---

6. Software Bugs or Version

• Issue: The problem might stem from a bug in the specific release of Manifold you’re using.
• Solution:
  • Update to the latest version of Manifold System Release 9.00 to ensure any known bugs are fixed.
  • Consult the Manifold forum for similar user-reported issues and solutions.

---

7. System-Specific Issues

• Issue: Low-level hardware issues, conflicting software, or insufficient virtual memory could cause unexpected interruptions.
• Solution:
  • Check system logs or event viewers for errors around the time the failure occurred.
  • Close other programs to minimize background conflicts.

---

Next Steps

• Try a controlled test: Use a smaller section of the raster to isolate the problem.
• Check the logs: Manifold might provide logs or error messages offering clues about the failure.
• Seek Support: If issues persist, consider posting detailed information on the Manifold community forums. Include details like raster size, tracing settings, and system specs.

Let me know if you'd like detailed guidance for any of these steps!

Dimitri, I have used Manifold long enough to be aware of those fundamental checks. The image is a 5 color GeoTiff and tracing in M9 worked for 4 of the colors, but failed on the color with by far the largest state-wide distribution. It is a complex distribution with many islands of other colors within each color.

Aussie Nature Shots

OK, but that's not the information needed to get to the bottom of what's going on. For example, routine operation for Trace is dealing with complex distributions with many islands of other colors within each color.

Drilling into this takes precise details on exactly what you do (every setting used in every dialog) and the actual data. If it works for tech support but not for you then I expect they would get into the details of how your system is arranged, how that's different than what they use.

Experience in such cases is that in order of likelihood the problem is a) an error of operation, b) an administrative error such as not noticing that a temp drive has filled up and has insufficient space, much more rarely, c) not noticing a fundamental limitation such as trying to create five billion records in a table when the limit is two billion records, and last and far more rare, d) a bug. Of course there's also an e) possibility, some combination of a) through d) all happening at once.

Discovering which one of those it is starts with getting all necessary details. I don't doubt your experience or the rational belief based on that experience that you've not overlooked anything. But you're still human and you might have overlooked something. If you have indeed found a bug then providing the details required to exclude the other possibilities are not wasted effort. I strongly recommend you send in a report to Tech.

My mind has been expanded by your discussion, Dimitri. Do you envision a day when we might use Manifold like we use Siri? Could we say, "Manifold, please import the LiDAR point cloud from (selected folder or drive), classify the points as surface hardscape, bridges, surface softscape, water features (including rivers, ponds, swimming pools, lakes, and dams), low plants, medium plants, trees, building roof lines, antennae, and power lines. Separate each category into different layers and, for the building layer, calculate the area, elevation above the surface, and slope for each roof. For the surface categories create 0.5 meter, 1-meter, 10-meter, and 50-meter DEMs. For the antenna and power line categories, calculate the elevation above ground. Georegister each category from the point cloud to (known selected) 3-D monuments throughout the area represented in (selected) layer or file. Finally, render the categories in 3-D so they may be visualized from any angle."

Sure, why not? No single part of that is difficult, and even today, free AI models that aren't even specifically trained on Manifold can approach answering them.

I asked ChatGPT:

I have a LIDAR point cloud. Using Manifold release 9, how would I import the LiDAR point cloud and then classify the points as surface hardscape, bridges, surface softscape, water features (including rivers, ponds, swimming pools, lakes, and dams), low plants, medium plants, trees, building roof lines, antennae, and power lines?

Here's what the free version of ChatGPT answered (Pro at $200 a month would be better...). Apologies for just copying and pasting the reply, so you get weird formatting. This is an untrained AI that makes errors and doesn't cover every detail, but that it is this good already indicates that over time, yeah, sure, the sort of thing you ask will be routine. The answer:

1. Import the LiDAR Point Cloud

1. Prepare the LiDAR File:

   • Ensure the LiDAR file is in a supported format (e.g., LAS, LAZ).

2. Import into Manifold:

   • Open Manifold and create a new project.
   • Use the File > Import option to import the LiDAR file into the project.
   • Choose the appropriate import format for your LiDAR data (LAS/LAZ).
   • Manifold will import the point cloud as a drawing (vector points).

3. View the Data:

   • Open the imported drawing to visualize the point cloud.

Manifold's Transform and SQL tools are essential for classification. Below are specific classification steps:

1. Identify Hardscape:

   • Hardscape points typically lie on flat surfaces with minimal elevation variance (e.g., roads, pavements).
   • Use the

     Slope

     function in the Transform dialog or an SQL query:

     SELECT * FROM [PointCloud] WHERE Slope([Z]) < 5; 

2. Detect Bridges:

   • Bridges can be identified as hardscape above ground (points with no returns below them).
   • Combine height filtering with bridge deck characteristics.

1. Identify Water Bodies:
   • Water points typically have a flat surface and consistent height (low variance in Z-values).
   • SQL Query Example:

     SELECT * FROM [PointCloud] WHERE Variance([Z]) < 0.01 AND [Z] BETWEEN <min_water_elevation> AND <max_water_elevation>; 

1. Low Plants:

   • Points close to the ground with a height threshold (e.g., 0–0.5m).

     SELECT * FROM [PointCloud] WHERE [Z] - Ground([Z]) BETWEEN 0 AND 0.5; 

2. Medium Plants:

   • Points slightly taller than low plants (e.g., 0.5–2m).

     SELECT * FROM [PointCloud] WHERE [Z] - Ground([Z]) BETWEEN 0.5 AND 2; 

3. Trees:

   • Points significantly above the ground with a specific height threshold (e.g., >2m).

     SELECT * FROM [PointCloud] WHERE [Z] - Ground([Z]) > 2; 

1. Building Roof Lines:

   • Roofs are generally flat at higher elevations.

     SELECT * FROM [PointCloud] WHERE Variance([Z]) < 0.1 AND [Z] > <building_threshold>; 

2. Antennae:

   • Points much higher than the general building height.

     SELECT * FROM [PointCloud] WHERE [Z] > BuildingHeight([Z]) + 5; 

1. Power Lines:

   • Identify narrow linear clusters of points suspended in air.
   • Use density or clustering tools to detect:

     SELECT * FROM [PointCloud] WHERE [Z] - Ground([Z]) > 5 AND Density([X], [Y], [Z]) < <threshold>; 

2. Poles:

   • Identify vertical clusters of points.

     SELECT * FROM [PointCloud] WHERE Variance([X], [Y]) < <small_value>; 

• Use Visual Preview: Open classified layers and visually inspect them.
• Merge Similar Classes: Group classifications (e.g., all vegetation types into one layer).
• Export for Further Analysis: Export results as shapefiles, rasterized surfaces, or other formats.

1. Use SQL Scripts: Write reusable SQL scripts for batch processing.
2. Use the Transform Pane: Apply filters and formulas directly in the Transform pane for interactive adjustments.

By combining SQL queries and the Transform pane with Manifold’s advanced handling of point clouds, you can efficiently classify LiDAR data into the required categories.

I strongly recommend you send in a report to Tech.

Unfortunately the raster was issued under license that prevents me sharing.

Aussie Nature Shots

I think the main issue with the break in regular builds is that totally basic simple things are missing. To name a few (already mentioned in the thread I think), a tool to measure areas by clicking, a way to select areas on an image (pixels, no tiles), coordinates text on layout grids. Personally, I almost never print on paper, so the later is not at all a priority for me. Someone else may never measure areas interactively. But things like the above are so elementary, no CAD/GIS software can do without them. Even the most basic android app for GIS/Surveying/Geology or whatever gives the option to tap and measure an area and every consumer image software let you select by pixel, while the professional M9 doesn't let you do these things.

Regarding AI and GIS I think it would continue to be a tool to help visualize data and help humans make decisions. There will never be a time that AI will decide for example where to build a power plant, where to extend city limits, or how important is to protect an endangered animal that lives in an specific area. That is so because those are issues of ethics, politics, philosophy and the ideas that every society or every people group hold. Those are not even issues of economy, because a group of people may have economic interests that contradict other groups interests. And if you try to include somehow politics/ethics data in the AI model, then it will simply produce the outcome the person or group of people that enter the data want.

I think the main issue with the break in regular builds is that totally basic simple things are missing.

That doesn't really hang together, as the three things you mentioned are already in there, you just appear not to like the way they've been implemented. That's fair, but if changing what is already there to how you would like it to be hasn't happened in years of regular builds with thousands of additions (many prompted by suggestions) implemented, why would you think that now in an upcoming regular build the changes you would like to see would be done?

Measuring areas

If you think that measuring areas by clicking a polygonal area is a basic thing, Manifold agrees with you.

That's why the capability is there and why it's discussed in the Basics section of the user manual. If you want to do that add GeomArea([Geom], 0) as a computed field to the schema. That takes but ten seconds, and then forever more you can alt-click any area object and see its computed area in the Info pane.

So why is it done that way instead of the way it's done in some other apps? Because if you're a sophisticated operator who is using the software in sophisticated settings in a precise way you know there's no such thing as just one "area" which everybody wants and which fits all the incredibly diverse purposes for which GIS is used. If you want a geodesic area, cluelessly getting a Cartesian area is not good enough. And if you want a geodesic area, that is, an area computed over the 3D ellipsoid, that depends on the ellipsoid you want. In Manifold if you wanted a geodesic area over the WGS84 base you'd use GeomAreaGeo([Geom], 6378137.01, 0.08181919084262149, 0) .

Software which blindly reports an "area" gives an inaccurate result for those many uses which do not match the assumptions built into the software. Yes, consumer tools do that because consumers don't know any better. But professional tools should do better, so Manifold does better.

Could you come up with a user interface that provides such options to "click on an area"? Sure. Go ahead and try to design that user interface and you'll see you end up with lots more than just one click, and it will be something harder to teach that can't be built into a map that inexpert people are using as easily as how Manifold does it. The nice thing about alt-clicking a polygon and seeing the area of it in the Info pane, the way Manifold does it, is that it bakes any complexity into the computed field, so inexpert users (perhaps even just using the free Viewer) don't have to learn optional sequences of special click modifications to specify which of infinitely many possible areas they want.

If you think all CAD/GIS software has those capabilities, tell me how in AutoCAD you'd get the readout of the geodesic area of a polygon with a single click (or alt-click, ctrl-click, whatever) over the 3D ellipsoid for the International Ellipsoid or the NAD 27 ellipsoid. How about in ArcGIS Pro? If you're convinced "even the most basic android app for GIS/Surveying/Geology " has that, tell me how it's done for the International Ellipsoid with a single click in, say, the three most basic such android apps.

I'm asking because I don't know, although I strongly doubt any of them can do that.

Select areas on an image

There are no areas in an image. There are only seas of pixels of various values in one or more channels. The way to select a region of pixels in an image in Manifold is to use Trace and to then join from the resulting area polygons and use tile masks.

This is a red herring: "every consumer image software let you select by pixel, while the professional M9 doesn't let you do these things." Not exactly. Consumer image software like PhotoShop typically has a touch selection tool. PhotoShop's is called the "magic wand" tool: Click it on an image and it reads the pixels where you touched and selects pixels that are "similar" within the "similarity" setting you've placed on the tool. Usually there's a checkbox for contiguous or not contiguous areas. Super. That's great for consumer editing of photographic images.

9 doesn't have a one-click "magic wand" tool like that. Esri's ArcGIS Pro doesn't either. So where's all the indignation in Esri's user community that such a "totally basic simple thing" is missing?

In both 9 and ArcGIS Pro you use other tools. In both cases you get a lot more flexibility, precision, and power at the cost of more thought required than clicking a magic wand.

For example, with ArcGIS Pro you could use the Reclassify tool if you've bought Esri's pricey Spatial Analyst extension. You could open the Image Classification Wizard, define training samples by clicking on the raster to mark pixels of similar color, and then run the classification to group similar pixels into regions (kind of like Manifold's Trace, but trickier). You could use the raster functions panel to create custom filters or classifications that highlight similar pixels. You could use the Identify tool to click on a pixel to get its value and then build queries (well, pseudo-queries in Pro, which doesn't have a real SQL...) to select by attributes what you consider similar pixels.

You get the idea. It's not a PhotoShop "magic wand." But Esri's approach is analogous to the many options you have in 9 to do similar things. I think 9's options are better because they are more orthogonal, whereas with Esri each approach seems to use a different dialog. 9's options are also easier to string along within complex, multistep, continuing workflow.

So why do neither ArcGIS Pro nor 9 have a totally basic simple thing like a "magic wand" and instead use the approach they do? That seems to be because both Esri and Manifold aren't used for totally basic simple purposes, so they can't get by just with totally basic simple tools. In both Esri's and Manifold's case the very wide range of raster analytics and transformations that are done go far beyond what fits well into simple consumer paradigms. There are so many different types of rasters, for example, not just RGB and grayscale, and those rasters encode such a very wide variety of meanings, like elevations, slopes, and densities of chemical compounds, and not just a photographic image.

There's also something else in common between ArcGIS Pro and 9: neither one is a consumer graphics arts editor like PhotoShop. Both are geared up for GIS workflows, not photo editing or graphics arts workflows. So the concepts that both Esri and Manifold use are designed to fit into the multistep workflows that are characteristic of GIS work. Those tend to be very precise, parameter-driven, procedural workflows and not casual, interactive, imprecise "looks good to the eye" workflows as are essential in graphics arts work. They also tend to involve far larger rasters than appear in consumer photo editing or in graphics arts work, rasters that are so large you'd better approach them procedurally because there aren't enough years in your life to handle them through interactive mouse operations.

That's why 9, for example, uses tile masks (Esri has a similar construct) instead of per-pixel "selection" that is directly analogous to per-object selection in the interactive sense. Esri is similar. The point is that whatever is the grouping into subsets that is being done, it has to be done in a way that enables effective participation in the multistep workflows that are done with the rest of the hundreds or thousands of features the GIS package supports. The same requirement holds for graphics arts editing packages like PhotoShop: their notion of pixel selection also has to enable effective participation in the very large number of operations their package can then apply in subsequent steps. But the two are not the same.

Release 8 is somewhat unique in GIS in that it built out a variety of interactive graphics arts editing capabilities as part of the GIS, so it's really a GIS/graphics arts editing hybrid. Although there are things you can do in 8 that you can't do in PhotoShop for almost all uses PhotoShop is a much better graphics arts editing package than 8. At the same time the graphics arts editing features in 8 are not analytic tools designed for what people do with serious raster processing in GIS, remote sensing, and similar technical settings (8 has other tools for those). What you end up with as regards Release 8 is a graphics arts editing system which a few people use, but which most people do not use. Instead, when they need to do graphics arts editing they save the image and work on it with PhotoShop. But those graphics arts editing capabilities in 8 aren't free. The technology of having them always available gets in the way of super fast work with very large images.

One reason 9 wasn't built as a graphics arts editing package is because of that, because the first and most important mission was supporting work with very large images in professional, technical settings, not building a consumer graphics arts package. Now, of course, Manifold could add consumer graphics arts features to 9. 9 is so fast that it can easily handle the relatively small sizes of rasters as used in PhotoShop and such. But does it make sense for Esri or Manifold to do that? Seriously, why write a thousand extra capabilities (what you really need to do to provide an alternative to PhotoShop) when that market space is already littered with zillions of packages? To enable people to do graphics arts editing on 100 GB images? It makes more sense if people want to do consumer graphics arts work to pick one of the packages that do that and add that to their toolkit.

Coordinates text on layout grids

See my other post on that. In a nutshell, use a map for labels on graticule lines and then show the map in the layout.

Areas

M9 has the Path tool that shows Cartesian lengths that are generally different from those that GeomLength functions gives, and that's fine in a lot of the cases. When one wants a fast display of a length then he would prefer to use the path tool, instead of GeomLength. The reason there should be an interactive tool for areas is the same that such a tool already was added for lengths. If an interactive tool for areas would give inaccurate results, then the path tool does that already for lengths.

Images

Sometimes one needs to select the pixels under a polygon and do something with them. There may be workarounds in M9 to do many of the things you "want to do with them", but in M8 it was very easy to select the image part you want using the Transfer selection.

The reason there should be an interactive tool for areas is the same that such a tool already was added for lengths.

If you wanted to add a feature to the Path tool it would have been clearer to say that. Comments like "to tap and measure an area" or "a tool to measure areas by clicking" alongside "a way to select areas on an image", imply what you had in mind was a click on an area object that reports the areal extent of that object.

It sounds like a misunderstanding resulting from the dual meaning of the word "area," in English in Manifold, to mean both an object like a point or a line, and also "area" to mean a numeric value, the areal extent of that object in some square unit of measure. I had suggested that 9 switch to using "polygon" to avoid such misunderstandings but, alas, that suggestion did not get traction. Whenever I do a translation to another language I always translate "area" in the sense of an object using a word equivalent to "polygon." :-)

Be all that as it may, there really are two settings in which one would like a convenient numeric readout of the areal extent of an area object. One is clicking on an area object in a drawing to get an instant readout of the areal extent of that object. That usually occurs in settings where accuracy is important, such as measurements of parcels for tax purposes, because people don't go to the effort of accumulating data sets with area objects in them if they don't care about the accuracy of such objects.

The other setting is interactive drawing of an area with the mouse using the Path tool and then getting a readout of the areal extent of the region enclosed by the Path. That's usually a more casual setting because of the inaccuracy of mouse clicks on a raster.

If people want accurate readouts of either length or areal extent of objects in drawings, the fast way to do that is with one alt-click on the object to get a readout of a Length or Area computed field. It's not to mess around with tediously clicking what could be the very many coordinates that define the object.

If you look at how people who have learned the system use the Path tool, for the above reasons they use it in maps, often those which show imageserver layers like Bing or Google, for casual measurements of distance. They don't use it in cases where precisely accurate measurements are required.

I respectfully disagree that doing a casual tool for lengths is automatically cause for doing a casual tool for areas, because the use cases and demand are different for the two different tools. If you look at how users who have learned to use those systems that offer both in a combined Path tool operate such tools, by overwhelming margins they measure lengths and not areas.

Google, for example, knows that and prompts users to Measure Distances throughout, not giving a hint that you can also measure areas using the tool if you close a path by making a last click on the initial point you clicked. If you don't know that quasi-secret trick you won't ever see a "Total area" caption. Google also doesn't set up the interface for real accuracy for areas, even though they'll sometimes report areas in square feet or square meters with absurdly unrealistic numbers of significant digits.

I write "absurdly unrealistic" because Google will round off the enclosed region by either not snapping to close it if you click close (as shown below in the illustration), but not exactly on the start point, and when it rounds off to close the region for you that's often not at the exact location you clicked to either start the path or to close it. The illustration below shows two circles where the start (upper) location was clicked and where the bottom (lower) location was clicked, and neither of them is on the actual corner of closure (hidden by the 3.80 mi label).

Google also has weirdly inconsistent rules for what it does with paths that self intersect before clicking on the start point, like the illustration below, or which continue after clicking on the start point to add additional parts of the area, for example, if you draw a butterfly shaped area that starts at one location in the middle, draws a triangle to the right that closes on the initial point, and then continues to draw a triangle to the left that ends up also closing on the initial point. It can be a complete mystery what is being reported.

Given that most people by overwhelming margins use path tools in such apps to measure approximate distances, and given the issues you get into with user interfaces that can deal with self intersections and precise snaps to start/stop points and the like, it's pretty clear why Google hides the ability to measure area in its Measure Distance tools and does not include it in the pop up tips for using the tool. It's not a "Measure Distances and Areas" tool, but a "Measure Distances" tool for anybody who hasn't discovered the extra feature it has.

All that is food for thought when thinking about adding such a feature to the Manifold Path tool. Could Manifold do something like Google's implementation? Sure. Are there downsides to doing that? Yes, of course, starting with the need to teach people how to use it.

That's a step Google skips, but it's not a step that Manifold skips. Also, Manifold wouldn't do the sloppy implementation that Google does, which requires users to "close" (not really, as it interpolates if you're near closing it) a path to get an area readout. If I were to design such a tool for Manifold, I would have it report the sum of all areas enclosed by the path. In the illustration below, a path is shown that doesn't close on the start location. If self overlaps cover the same regions enclosed by the path, those would not be double-counted. If the path isn't closed, no problem: just the regions enclosed by the path would be reckoned. In the illustration below the region indicated in very light green would be the region for which area would be computed.

If somebody wants to get an areal readout for a path that closes exactly with the last location clicked being exactly the first location clicked, then the user should turn on Snap.

Note that the above user interface is slightly different than how the interface for drawing area objects works, because drawing an area object always has a rubber banded line that closes the area from the last clicked location to the start location, as seen in the illustration below:

Now that we've designed a plausible modification to the Path tool, is there a compelling reason to do it compared to demand for other things? So far, no.

There are two main reasons why, both of which are driven by the need not to expend resources to duplicate capabilities that already exist or are similar, and especially so when the need is slight or when there are other things which have higher demand for those resources.

Is there a demand for casual, imprecise area measurements in the Path tool that is as great as the demand for casual, imprecise length measurements? The answer to that is "no," both looking at the Manifold experience and also at the experience of other applications. Programmers seem to add areal measurement either because it strikes them as something which completes the tool (even if they don't actually expect much use of it) or because they don't have other tools to do areal measurement. The latter clearly dominates in consumer apps, like android apps.

With real GIS the primary demand is for precise and accurate areal measurements. Manifold makes it easy to do those. You can either arrange one-click reporting of areal extent for any area object in a drawing (far easier, faster, and more accurate than click, click, clicking around the periphery with a mouse-based path tool) or you can simply draw an area in a measurement layer and get the same result.

After all, drawing an area is no harder than using the path tool:

It even closes the area for you automatically. If you do that sort of thing regularly, just keep a "measurements" drawing on hand in one of your utility .map collections of useful things (graticules, other layers, etc). I have one I call GeoMeasure. It's in lat/lon so the various geodesic expressions work in very simple form, and it report X,Y in lon, lat. Since the geodesic functions report results based on the unit of measure used for the ellipsoid, which is meters in the case of WGS84 as I've used in the GeoMeasure drawing, the readouts for area and length are in meters. If you want them in hectares, acres, feet or whatever that's easy to add.

To use it, I just add it as a layer to whatever map that I want to have detailed, accurate measurements. I can then draw areas or lines and alt-click them to get an immediate readout in the Info pane of a bunch of useful parameters.

It's true this adds having to drop a drawing into a map (which takes, what? a second?), and then you have to draw the area. But you have to draw the area anyway to use a Path tool. What's nice about using a GeoMeasure layer is you can draw a bunch of different areas and compare them, while with a Path tool there's no memory to it. You can also get a number of readouts all at once, with very easy customization (Want to know the size of the minimum bounding box for that area? No problem.), while with the Path tool you'd only get one or two (probably areal extent and perimeter length).

I've attached a .map which has a GeoMeasure layer in it. I also have a "Measure" drawing with in Pseudo-Mercator with analogous, non-geodesic fields, but I never use that.

Just saying, if you want to measure areal extent by clicking a path, it's pretty much the same thing whether you click that path in the Path tool or in the Create Area tool, but using the latter you can get lots more info and, for comparisons, much easier workflow.

Regarding images, the facilities in 9 aren't "workarounds": they're very powerful facilities that often give you what you can't get in 8, especially in the context of efficient, multistep workflows. It's true that in 8 it's very easy to select a region of pixels by selecting an area object in a drawing and then transferring selection. But the price you pay for that ease is a limit to relatively tiny rasters for everything in 8. Ouch.

In exchange for the ability to work with much larger rasters 9 uses the concepts such as of tile masks, vector to raster joins, and similar. That does require more skill than just transferring a selection, but it is more general purpose, more powerful, and it enables use of much larger rasters than the mechanisms in 8. For much work it is an open question whether or not the 9 way is faster overall than the 8 way for the sorts of things people tend to do, at least with the raster sizes often worked on in remote sensing and other raster-heavy GIS work.

Could Manifold add a concept of 8 pixel selection to 9? Sure, but that would be a lot of work, it likely would be unwieldy for larger rasters, and it wouldn't fit well into the very large arsenal of other tools and functions. Since there are other ways to do the same thing in 9 which can result in faster workflow there has to be a better justification for it other than "I'd prefer to use 8 concepts so I don't have to learn the 9 way." I'm not in any way saying that's your justification, but without a fairly detailed look at real life workflowsusing real life data in applications where people are willing to spend money to buy the program, and where the operators are equally skilled in 8 and 9, it's tough to say for sure in which style of operations the workflow is faster.

My own experience is that once I learned how to use 9, virtually everything I do 9 ends up being significantly faster than 8 in terms of the sequence of workflow tasks that I end up doing. I really, really liked 8 but now I find myself always reaching for 9.

Attachments:
area.png
area2.png
area3.png
area4.png
GeoMeasure.map

In a possible area measurement tool, when star/butterfly shaped areas like the ones you post are drawn manifold could work like it works now when such shapes are created using the Create area tool. That's not difficult for any user to understand and learn.

You know better than me the human resources and time manifold can give for implementing each feature, but the one we are talking about I suppose would be very easy to add in comparison to other things.

Anyway, all CAD software have such a tool, even though you can create a closed polyline (series of lines in CAD terminology) and you have the area ready as a property in a panel. ArcGIS has such a tool too (https://desktop.arcgis.com/en/arcmap/latest/map/working-with-layers/measuring-distances-and-areas.htm) that measures both Cartesian and geodetic distances.

P.S. Before the implementation of the Center tool in M9 (the one in the toolbar), I used to create an empty drawing, place a point there, edit the coordinates and then center to the layer. Now I suppose most people would use the Center tool most of the times. With an area measurement tool would probably something similar would happen.

manifold could work like it works now when such shapes are created using the Create area tool. That's not difficult for any user to understand and learn.

Respectfully disagree. I think it would be better to sum all enclosed regions (those that would be found by trace) not double-counting duplicates(overlaps). Here's why:

Consider a path drawn free-hand in the path tool...

I'm suggesting the light green regions would be summed to get an areal metric.

Consider, in contrast, what happens if you do it the way areas are drawn, where there are two key differences: first the area is always closed, and second, certain overlaps are subtractive...

That shows the result of drawing an area object using the same path and clicks, with the result shown as a blue hatched pattern. If that's what's computed you end up adding two small regions because of the automatic closure, and you lose a bigger region and a smaller one because of the subtractions. That's not something that's either easy for beginners (who logically would be the first to use such tools) to understand and learn.

You could, of course, fill in the hatch patterns to show what would result if an area was intended and not a linear path. But that would be confusing for people who wanted a linear path, and to sort that out for both constituencies you get into all sorts of learning disability issues where the user interface gets more complex and people don't RTFM.

It's much easier to just leave it as is and sum all enclosed regions so the user interface stays simple without baffling closures when people do what they mostly want to do, draw linear paths. If somebody wants to close an area precisely, that's trivially easy to do: hit the spacebar to enable Snap and then click near the start location to snap to that.

P.S. Before the implementation of the Center tool in M9 (the one in the toolbar), I used to create an empty drawing, place a point there, edit the coordinates and then center to the layer.

That's unnecessary complexity and work. Instead, you can just ctrl-click a layer tab to zoom it to its extents, which centers it, and then zoom as you like (wheel mouse, right-click and drag, click the - and + buttons on the main toolbar). For example, I ctrl-click and then right-click zoom box to immediately get whatever extent interests me.

Center is a good example of a very rarely used tool that seems like it should be there, but when you learn to use the product efficiently there are other things that usually work better for use cases where Center might be used. Why? Because if you're working in a small layer you don't need it and if you're working in a big layer on some detail just hitting Center generates a baffling shift far out of context. The odds are whatever is in the exact Center isn't what you're interested in, so you're going to have to pan and zoom away from that to get to what you want. It's much faster and easier to ctrl-click and then right-click zoom box.

There's no downside to that because different layers usually have different extents, yet what Center does is layer specific, not map specific, so in any event you need to click on the layer tab desired. There might be a few niche cases where people might use Center, but for the most part for editing and search people want a broader view to find the next thing they're going to work on or look at.

A ctrl-click on a layer tab is the fastest way to get a broader view that provides context. From there a roll with the mouse wheel usually is the fastest way to zoom in while locking the location under the mouse cursor. Or, do a right-click zoom box to get desired pan/zoom at the same time.

If I were to tinker with interactive mouse zooms, I might add a Shift modifier to the mouse wheel, to increase the number of zoom steps commanded by rolling the wheel, but that's about it.

As for the measure tool in ArcMap, that's now deprecated. If you look at the equivalent tool in ArcGIS Pro, Esri's current desktop flagship product, there are two different tools, one to measure distance and another to measure area (https://pro.arcgis.com/en/pro-app/latest/help/mapping/navigation/measure.htm). The area one puts the complexities into the user interface, and it illustrates what happens with logic other than counting enclosed regions without double counting them.

Consider a simple Measure Area tool measurement of the island of San Michele using Esri's "Acqua Alta" standard tutorial example:

That provides a total sum of 319,598 square meters. (If you try this at home, remember to press the eraser button in the Measure Area dialog toolbar in between drawing new areas, or it will add up prior measurements.)

Here's a more complex set of clicks that end up covering almost exactly the same region:

But now the sum of areal measurements is 452,702 square meters, very much greater than the slight imprecision of bounding clicks. Just looking at the display there's no clue how the topological decisions were made to add or subtract areal measurements based on self-intersections.

Now, if you did it the Manifold way there'd be no bafflement because you'd see the area object you had created so you know exactly what was being reckoned. If an unskilled person is operating the project, all the complexity of what's being calculated can be hidden in what you do for the measurement layer.

There's also the need in ArcGIS Pro to check the coordinate system of the map, because you can only measure planar (Euclidean) areas in a projected, non-geodesic coordinate system and you can only measure geodetic (geodesic) areas in a geodesic coordinate system. But Arc will still offer options for Planar and Geodesic even if those will give bogus results. It's up to you to remember (and know how) to check the name of what's in use, and also to know what names mean (or to know to drill into the coordinate system details) in terms of being geodesic and non-geodesic.

That's not an issue in the Manifold way because your measurement layer can be whatever you want it to be, either geodesic or projected, and it will still provide accurate results in the Info pane no matter what projections are used by other layers or by the map. There's no chance of unskilled users (or skilled users in a hurry) picking an option that will give them bogus results.

In fact, if you wanted to "build in" a calculation method you want used you can use geodesic calculations with a planar layer and vice-versa by just using a more sophisticated computed field to convert the geom on the fly for the areal measurement readout. I don't bother doing that, but it's possible to do if you want to "bullet-proof" a project for later use by other people, who may be re-projecting a drawing to some coordinate system other than the one you authored it in.

Just saying, there are a lot of issues involved in what may appear to be a simple thing, and different ways to handle those issues depend on the various facilities a particular GIS provides. Many CAD and GIS programs use an area measure tool like the path tool because they don't have a better way of doing it. CAD programs, for example, don't normally have re-projection on the fly in maps so you can't have multiple layers that include a measure layer in a different projection like you can do in Manifold. Esri also doesn't do that as easily as Manifold, especially given the limitations they have for their equivalent of computed fields.

As for how much time it takes to consider the many nuances and to build a modification to the path tool that can handle all those, it's not a really big project but it's not trivial either. Given there are ways to do the same thing very well right now which are only very slightly more demanding (a few clicks to set up and maybe one extra click to use) there has to be a use case described why the current facilities are insufficient as well as examples of frequent tasks done by a significant number of users. If most people don't care about it, well, then it goes on the stack with a "nice to have but not essential" level of priority. Usually, the suggestions process does a good job of capturing such global feelings, as people tend to write about those things that are essential.

I personally like the idea (using the total enclosed region for the reasons mentioned above) just because it appeals to me in terms of dotting an i or crossing a t even though I'd rarely, if ever, use it, and whether or not significant numbers of other people would ever use it. If I was doing it, I'd probably modify the Info pane to add a Measure tab to duplicate some of the context menu controls, add some more displays, like bearings on segments and so on. You could go crazy with that stuff and some of it might even be useful. But that's just me. Other tastes may be different.

Attachments:
arc_measure1.png
arc_measure2.png
area3.png
area5.png

I'll like to add just a little perspective from a user that started with 4.5 and made a promise of never use ESRI ever again and have done it for over 24 years. For me and my clients M8 is the Best Classical GIS. Period. We would have appreciated the revamp and modern look updates, if they would have come. Because it does, 99% of my tasks and are done nicely. Manifold 9, honestly shouldn't even be called that. It's not a progression of Manifold 8 at all. It could have been called Radian X or whatever you would like, because its a completely different thing. So there is no relation to M8, but the creators. I only use 9 to import / export new formats, that M8 doesn't read.

I don't know if you share this information, but how many users of M8 do Manifold actually have, and how many of R9? I would tend to think that your very loyal customer base is still in 8, at least, I am one of them.

For me, as a constant user of M8 for everything GIS related, which are mostly simple tasks, which are what most GIS users do, unless you are a PowerUser that actually take into your advantage what 9 has to offer.

Well, Manifold Inc., created an add-in for the competition ArcGIS Pro, to take advantage of one of the best tools in R9 (now discontinued) but still offering it in some way.

Been positive, I ask why not do the same for your beloved Manifold version 8 users.

Create a couple of Add-in for M8 that takes advantage of R9 functionality. I can only think of 3.

Import / Export Geodatabase, Geojson, and a few more modern formats, and we will be immensely happy.

Real SQL (just like the one did for the competition)

Faster Image Servers, with 9s speed.

They could even need a license of R9 to run. That would be ok, I have 9 serial to spare.

But I would love to have it inside 8 which is my familiar environment, no learning curve need, everything done there, runs smoothly.

Why not give some love to your M8 users, that keep using 8 considering that has been without an upgrade or update in decades, its such a well made software, I love it.

Yes, the new things sound great, but you will need more time to deliver a final product as good as M8 when it was released. I don't think R9 is even close to that comparison.

Thoughts on AI. Instead of training or creating an AI to fully understand R9 and that it will be able to do, what ever we think, that it will need an unknown amount of time, as you said. Why not create those Add-ins for M8 and make us happy and modern at least a little. Then we can wait as long as you need for the new thing to come out.

Best wishes to All.

tomasfa, are you softly suggesting that M8 remain a stand alone product, that M9 continue to develop into a stand alone product, and, possibly M10 become a stand alone product incorporating AI?

Hi dchall8. Well from what I can see M8 still a valid product and very much in use, why not updated a little doing what they have already done in another case. To keep it running properly for the M8 user base (don't know the size of that user base, but I am part of it.)

If they become standalone products or not is up to Manifold Inc. M10 for me should not even be in the picture if M9 still needs development, don you think? Like I said before M9 is a completely different thing than M8 so they are different products, not a continuation of 8, they are managed as stand alones anyway.

I had a meeting with a client last week, they have 30 users of M8 in the company, it's a Utility Company they have been using M8 as main GIS tool for over a decade and still happy. I gave them 9 licenses and didn't like them (new prod, new learning curve, not much gain for what they do) budget reduction implies no new training, if the current tools works great. Literally they use 9 only for importing geodatabase and exporting to geojson for compliance.

They asked me, what is Manifold working on or is it focusing on what. I honestly couldn't tell. Since for certainty, M8 is no longer been developed, but we can still buy licenses if required. M9 is a different beast, not to mess with sin they don't do anything that will take advantage of that speed. M10 or future developments are unknown to us as users, surprises may come but no timeframes are established.

At the end, they had to accept reality and buy ESRI Utilities, because they connect to most of the other software they use for operation like Survalent and a few others, that integrate to the ESRI Utility model, and Manifold will be kept as a complementary tool for basic GIS tasks for most teams in the company and only a few user will have esri for Network Management and Integration to all monitoring systems. That's my reality. So, for me the suggested Add-ins for M8 makes sense to extend the life of a well developed finished product like M8.

I look forward to what Manifold Inc plans to do, and what is the direction they are going for...