Subscribe to this thread
Home - General / All posts - New Release?
228 post(s)
#25-Feb-24 18:53

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?


2,064 post(s)
#26-Feb-24 04:00

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 |


7,449 post(s)
#26-Feb-24 07:33

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.

515 post(s)
#26-Feb-24 08:55

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


7,449 post(s)
#26-Feb-24 13:31

Sorry, I can't comment on that.


2,064 post(s)
#26-Feb-24 09:42

Sounds interesting. Thanks Dimitri

Landsystems Ltd ... Know your land |


7,449 post(s)
#26-Feb-24 07:18

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.

Mike Pelletier

2,138 post(s)
#26-Feb-24 14:38

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.

186 post(s)
#26-Feb-24 16:08

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.

515 post(s)
#28-Feb-24 06:24

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.


2,064 post(s)
#29-Feb-24 21:48

** 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 |

Mike Pelletier

2,138 post(s)
#01-Mar-24 21:56

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!

1,012 post(s)
#05-Mar-24 08:18

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

Mike Pelletier

2,138 post(s)
#05-Mar-24 14:29

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

1,012 post(s)
#10-Mar-24 06:06

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

Mike Pelletier

2,138 post(s)
#12-Mar-24 21:22

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.


6,410 post(s)
#05-Mar-24 17:12

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?

184 post(s)
#23-May-24 08:11

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)

Mike Pelletier

2,138 post(s)
#23-May-24 15:01

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.

1,012 post(s)
#24-May-24 07:27

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.


7,449 post(s)
#25-May-24 06:36

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


7,449 post(s)
#25-May-24 08:22

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$


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


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.


145 post(s)
#19-Mar-24 10:57

** Speculation start **

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

** Speculation End **

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.