Subscribe to this thread
Home - General / All posts - Direction for new builds in 2020

8,970 post(s)
#05-Mar-20 11:39

The new official build kicks off a new emphasis for Manifold in the months ahead, inspired by community feedback and discussion.

Several people have remarked that with increasingly powerful software Manifold has seemingly moved away from its roots of creating GIS for everyone. A company founded to make GIS accessible to anyone, with an initial starting price of $45, now builds technology that can span thousands of CPU and GPU cores and handle a roadmap for the entire planet ...with a learning curve that looks very steep and a list price of almost $600. The increasing power and sophistication of the product can be a barrier for GIS beginners. Manifold would like to make all that easier.

The new emphasis is on making Manifold more accessible to everyone, including hobbyists, individual users, and people with Microsoft Office skills who are new to GIS. There are five themes in that new emphasis:

1. Ease of use / quality of life - Continue Manifold's current campaign of adding conveniences, filling gaps, and smoothing off any sharp edges in the current interface and feature set. In addition, introduce new features and changes in the user interface, such as smarter visual tools and simpler and more intuitive panes, specifically designed to make the product easier for people with less GIS or Manifold experience. Make the workflow easier for experts as well, without trading off any power.

2. New packages - Huge, all-in-one packages can be overwhelming. It's likely that Manifold will introduce different packages, so an entry level, base package with a subset of features can be made easier for beginning users, while providing greater capabilities through extensions or other editions for more advanced users.

3. Enhanced documentation - Enhancements will focus on better introducing the product in the early stages of learning. New packages can have dedicated introductions without having to cover it all in early topics. Topics covering the basics of working with Manifold can be translated into local languages.

4. More languages - Experts use English in many countries, but non-experts often prefer that at least the UI is translated into local languages. With 9 having a native localization capability, we saw multiple user localizations appearing and maturing. It's time for us to help by providing tools that make the translation process easier and by making localizations easy to reach for other users. We are also doing outreach to universities and others to expand the base of contributed localizations. This effort has already generated new translations for French, Russian, and Chinese, with new Portuguese and Spanish translations expected soon.

5. More accessible price - Having a high list price with the product always on sale is just too un-Manifold. Starting with this public build Manifold has trimmed the list price to $345, with special offers only on Release 8 trade-ins. That will be a big help for individual users and in many countries around the world. In the months ahead we will likely provide other options at even more accessible price points, using alternative pricing mechanisms such as subscriptions, or simplified, subset packages.

Making the product stronger, easier to use for beginners and experts alike, and more accessible to more people from learning, language, and price perspectives, are all good things. How that plays out in the months ahead will depend on many details of implementation, with community guidance playing a key role.

181 post(s)
#05-Mar-20 20:57

I think it is a direction that makes a lot of sense. I support it wholeheartedly.

I also really like the fact that you are clearly communicating the direction of your product development for the year. Very cool.

scandalxk55 post(s)
#09-Mar-20 11:11

Thank you Adam.

With 25 years of M8 and its predecessors to un-learn, I have found the step up to M9 pretty high. Most of my GIS use is combining, measuring and mapping disparate data sources for specific civil engineering and environmental projects, generally at the graphical level rather than the database analysis level. I get data from engineers, ecologists, clients and others, government departments, Ordnance Survey maps, my own GPS surveys, throw them all together, eyeball what I need to know, measure, select and format as required, print a map and use it on site or put it in a report. I don't think I have written a SQL query since I was studying 30 years ago. Yet GIS is central to my working day, and M8 has, for a long time, been my favourite software by far.

I welcome your new focus on useability in M9, and on the needs of customers with equally important but technically less advanced requirements. Obviously the first priority is to get the underlying technology working well, and naturally most of the contributors to this forum come from the technical end of the spectrum - so perhaps their interests are driven hardest. However, I am sure there are plenty of less technical users, like me, whose money is just as good as the techies' money. Improving ease of use and - especially - rapid production of simple site maps or document quality layouts are the things which will finally get me to retire M8, and perhaps bring new users into the Manifold world.

Thanks again and good luck with the next phase.

Mike Pelletier

1,698 post(s)
#10-Mar-20 19:52

This all sounds like a good thing. It might be worth saying that a fair amount of the ease of use issue is related to 9's ability to work with big linked data. Lack of undos and leaving a deleted component in the map layer list are two that come to mind. Perhaps creating allowances for local, single users would be a helpful approach.


9,159 post(s)
#10-Mar-20 20:29

I don't think the meaning in your second sentence is clear. Surely 9's ease of use with big linked data is one of its main strengths, worlds ahead of anything else in the GIS world, and seriously comparable with anything else in DBMS. That is no blockage but a major advantage.

For the rest, I think you are suggesting a more approachable interface for novice and occasional users, maybe at some cost in power and feature set, perhaps also a minor cost in speed. That seems very reasonable... but what would make such a user switch to the approachable Manifold product from, say, completely free QGIS?

If they don't yet know what they're doing, they're not going to know why spending even $100 or $200 is better than spending nothing, are they?

(Then, once they've learned their way through the QGIS mess, why would they start again--unless they've now become a serious user, in which case...)

I think there is an answer to that, probably more than one good answer, but it seems like a tricky marketing decision on the back of substantial engineering investment, which obviously has an opportunity cost. I would be interested in your take on it Mike.

Mike Pelletier

1,698 post(s)
#10-Mar-20 21:59

Thanks for your interest Tim. Absolutely wouldn't want to see 9 dumbed down on performance. What I was trying to say is that certain conveniences have been forgone in order to accommodate working with big linked data. Adam has suggested they are working to improve both the examples I gave, so the value in this thought might be more for justifying why some of the seemingly obvious improvements have not been done yet.

Compared to QGIS, 9 boasts stability, speed with big data, fabulous potential due to underlying infrastructure, SQL flexibility, a tight user interface that allows learning a few moves that will likely be useful elsewhere, assurance you won't out grow the software's abilities, ....

Sounds like soon labels will be improved, vector editing will get what is missing from 8, a relation tool allowing relations not using new versions of the data, registration, GPS, a scale bar, dynamic legend, and saving styles. This would go along way to opening up 9 to more users who need map making software. The track record is though that this is all won't be done for quite a while.

Agreed that a novice isn't going to know what software to use and will rely a lot on recommendations. 9 has the potential to be really easy to use once you learn the common moves and they make more improvements. A thoughtfully done tutorial and video that touches on various key UI commonalities as it goes through a streamlined map making process (comprehensive, not repetitive, and not too simplistic) would go along way.

Adam's post makes it clear they are interested in casting a wider net of potential users. I think 9 is missing key features more than we are missing streamlined workflows to best capture those folks at this point.


9,159 post(s)
#10-Mar-20 22:33

Excellent Mike, thanks, will reread a couple of times then reply. (Reply might be vanishingly short since so little disagreement.)


8,970 post(s)
#11-Mar-20 08:35

Thanks for a great post.

(Regarding leaving a deleted component in the map layer list, we have the Delete Related command which automatically deletes the component from wherever it is referenced, so I suppose we are talking about maybe invoking that command - or a slightly altered version of it - by default when you press Delete in the Project pane. We can do that. Same for renaming a component.)

wvayens54 post(s)
#11-Mar-20 18:17

As someone who falls into the individual user/hobbyist category I like what I'm hearing. I love the speed of 9, especially since (for me anyway) the speed of 8 has significantly degraded over the past 2-3 years. However, I have to spend a lot of time figuring out how to do something in 9 and am not comfortable enough with it yet to move away from 8 for most of my work.

Will look forward to upcoming developments.

181 post(s)
#11-Mar-20 18:57

... but what would make such a user switch to the approachable Manifold product from, say, completely free QGIS?

The completely free Manifold viewer I think will be an excellent start.


5,892 post(s)
#12-Mar-20 13:13

True. Plus those who understand their time is the most valuable cost of all also know that a "free" product which costs you an arm and a leg in time because it is slow has a real cost far higher than a reasonably priced commercial product that works faster.

The fully-loaded cost of a GIS person in the US for most organizations is around $150 per hour. Just one job where Manifold does in seconds what Q does in hours pays for the license. Save a few more hours here and there over the course of a year and Manifold is way cheaper than the "free" option.

Q is brutally slow with mid-sized data. All those videos showing Manifold taking seconds what takes minutes in Arc usually go much slower in Q. Think minutes for what Manifold does in seconds, and those minutes add up.

Those minutes also pile up with personnel unhappiness, something that well-managed organizations care a lot about. GIS people are expensive, and expert analysts in things like petroleum and gas are extremely costly. Smart managers want to keep those people happy. Forcing them to wait around for slow, single-threaded software makes them unhappy.

Not having to worry about project sizes or complexity makes the work day much more productive and easier for operators. Quick opens and saves encourages iterative saves that make it easy to avoid the consequences of human errors.

The sheer speed of the user interface makes for happy operators as well. Nobody likes to sit at a desktop where they click the mouse and wait around for tens of seconds or minutes for the next step. When everything happens instantly, people are happier. Keeping your team happy and more productive is good business. Fast GIS is Fun GIS.

At the low end, there's a stereotype that people flock mindlessly to "free." Internet every day shows there's a lot of truth behind that. But there are also plenty of people who value their time, who are fed up with slow software that they know to the marrow of their bones is using only 1/20th of the fancy new Ryzen they just bought, and who don't mind spending a few bucks to treat themselves to a faster, more responsive experience they know they deserve. They might not spend $600 to treat themselves, but $95 or $145 for a rocket-fast, simplified and easy tool? Sure. That's less than some high end mice. :-)

83 post(s)
#12-Mar-20 14:52

This is great news and a breathe of fresh air. M8 has been and remains such a wonderfully powerful and useful software. I think moving M9 forward with the goals as laid out by adamw are a great step forward and M9 will eventually be an excellent product for all, beginner to guru. Hurrah!

688 post(s)
#14-Mar-20 01:32

Regarding documentation enhancements: I have mentioned many times over the years how much Art's initial video training package helped me get going with Manifold 4. The presentation was basic demonstration for the basics of drawing lines, areas, splitting, labeling, and formatting. His pictures were worth far more than a few thousand words to get someone off dead center when picking up a non-intuitive software. The current offering of YouTube videos from the Manifold Sales channel are great, but should be curated to get rid of the out of date videos. But that is a great place to put the 'get started with Manifold 9' enhanced documentation.


585 post(s)
#20-Mar-20 17:51


There is many years ago when search a way to work on digital map , manifold was the only tool i find for the best functionnalities and not too high price ( compare to mapinfo and arcgis) . Before buy manifold i use postgis on linux ( compiled from source code) but take time , use command line and remember using html page to record data in database since data was only available on paper and not digital ( today perhaps available but only for gorverment) .Manifold 8 with vb script and gui component help me to do this in manifold 8 . In the same time vector data cost a lot X4 the price of manifold.

Now open openlayer, qgis ans osm is available, but even i test Qgis I still use manifold.

Manifold 9 is user friendly all action is available from contectual menu in drawing .

What miss is ( for me)

- easy link 2 tables ( using transform )

-georegister a raster using GUI or predefine code ( library) or transform

-better way manage label position with a way to define size label using style panel ?

- a layout where label size don't change with zoom like in a pdf zoom don't change text size !!

-a way to hide column to focus only on the columns we work and not scroll on the time

( perhaps a SQL select let us show rows columns of table in an edit mode ..... )

-script that support algo library ( manifold and third ) but also GUI ( button input form ....)

I think french support is nice if documentation is available in this language . Perhaps a specific documentation multi-languaqge only for the basic newbies should exist like in osm wiki where documentation is available in many language. i ll still use english since documentation, video , learning course, support are still in english .


!!!!! coronavirus : yes use azithromycine and chloroquine !!!!!


5,892 post(s)
#23-Mar-20 04:09

Great list! Some notes...

- easy link 2 tables ( using transform )

-georegister a raster using GUI or predefine code ( library) or transform

In process.

-better way manage label position with a way to define size label using style panel ?

Label size can already be defined using the style panel. What's a "better" way to manage position depends on what you are doing and what you want to do. Do you mean fully automatically? Manually?

- a layout where label size don't change with zoom like in a pdf zoom don't change text size !!

That will happen.

-a way to hide column to focus only on the columns we work and not scroll on the time

Already there. That's one of the things the Layers pane does for tables. Folders in the Layers pane are also a part of that.

-script that support algo library ( manifold and third ) but also GUI ( button input form ....)

There is huge support for scripting now, in many languages, that allows you to re-cycle algorithms and code from very many sources. If there is something specific you need that you can't use, say what that is and why you need it. The capability might already be there.

ranger.sean85 post(s)
#22-Mar-20 21:50

Regarding the ease of use and quality of life heading in Adam's post, a table that provides a side-by-side comparison with M8 and a timeline for implementationof features in M9 might be useful for those who aren't frequent visitors to the forum.

Before shouting me down, I realise that M9 isn't intended to be a carbon copy of M8, but I think that 8 does provide a reasonable bench-mark in terms of the general functionality that many people look for.

Don't get me wrong, the build-logs posted when each version of M9 is released are great. As are responses to posts enquiring when/if certain features will be implemented, but a betterroad-map could make all the difference for people looking to upgrade.

For example, cartographic publishing is a large part of the work I do, and recent work on legends was the catalyst for me to finally upgrade to M9. Having done so, I am absolutely loving the ability to open geodatabases and connect to data sources such as WMTS. I am now keenly awaiting further work on labels, as well as features yet to be implementedlike system generated text, scale bars and georeferencing.

I realise these things are all fairly insignificant in the context of the effort put into making M9 a Ferrari among GIS software, but having the features needed for M9 to be a daily-driver is also important. With this in mind, knowing when they might be implemented could be appreciated by the user community.


9,159 post(s)
#22-Mar-20 22:20

I think that's a great idea. (And not insignificant at all.)


5,892 post(s)
#23-Mar-20 04:43

a table that provides a side-by-side comparison with M8

8 is a truly great system, and definitely probably the first really big GIS to successfully provide a "something for everyone" package. For all that, 8 also has many features that are rarely, if ever, used.

9, in contrast, has had a much greater focus on building out features that come in sets to fit specific use cases, as driven by the community. Given that the first huge set of capabilities 9 provided (which 8 does not have) revolved around the core, data-centric infrastructure of the Radian engine, those people who were early adopters were the community driving all those features to a very high level of completion and refinement.

Those folks were demanding all those features because those features are essential to ease of use, efficiency, and convenient operation in the work they did. 9 is absolutely the smoothest, most powerful, easiest to use tool if you're slicing and dicing GIS data from a data science, IT, ETL, DBMS perspective. It has a great set of point and click transforms for all that, the interfaces are smoothly orthogonal, you can mix point-and-click with expressions, with SQL, with scripts, and even get previews in cases where other systems force you to cut at your data blind. All that is a testimonial to community feedback where people doing such work steadily and regularly sent in their suggestions and comments.

Starting last year and moving into this year there's been a much greater emphasis put on interactive GIS, which all makes sense. Every time 9 expands the interactive feature set in some area, that expands the user base in that area and those users naturally push for more features in the areas they use. Given the expansion of interactive features for things like style and editing that's really picking up with way more focus in those areas.

But the key thing is not to waste time making matrix lists comparing one system with 5000+ capabilities to another system that has 5000+ capabilities (9 already is very large), it is say what you personally want for your work. We can't all be experts in what other people want, but every one of us is the authoritative expert on what we want.

The most useful way to express that is with "top 5" and "top 10" lists. Mike Pelletier, for example, has contributed lots of insights in the form of compact, consistent lists of top priorities. Besides being clear statements of priorities, such lists are much easier for us ordinary humans to cobble up than universe-wide theorizing that covers very many areas or features at once.

In my personal work, for example, the volunteering I do, I do many projects in 9 that span a fairly wide range of GIS use cases. I always have a 9 project open on the side that is a table of suggestions I want to make based on the real-life work I'm doing (I use 9 as a personal information manager and project manager). That project usually has small things but sometimes bigger things. Things like being able to hide and show fields in tables was one of those.

A recent suggestion I made was an extension of that. I don't like it how in the Transform pane when you have a pull down list of fields it shows all the fields in a table. Instead, I want that pull down list to show only those fields which are not hidden, with a more... choice at the end to show all fields. Why? Because when I work with tables that have dozens of superfluous fields (like those in the Natural Earth data sets) and I'm only using four fields out of fifty, I don't want all the other 46 fields cluttering my pull down menus.

Little things like that add up, and because they are compact and specific, they are easy to suggest. Taking that approach for bigger things also helps. For example, it would be great to have scale bars, but in my view that can be done in two steps: I'd like to have a very basic, one style scale bar done right away, because that covers many of my use cases. A second step to add to that a more expanded set of default choices would be good, and then maybe in some future release the ability to customize, or maybe not.

It's true the approach I'm recommending only works for people who have learned 9 well enough to know what is in it, what works with super ease of use and efficiency, and what needs improving. I don't think that's a bad thing, because whether it is tools for carpentry or a better winch handle for a sailboat or a new edit mode in Manifold, I think you get the best insights for ease of use plus super capabilities from people who actually use those tools.

So... as you get more familiar with 9 I'd strongly recommend sending in short lists of your top priorities for more global direction, and get in the habit of regularly sending in small suggestions as well for various small details as they come to mind. It's all good.


9,159 post(s)
#23-Mar-20 05:35

And your point is...? Only what you say in your last paragraph?

If so, why not put that first? Honestly, no one (except me) is going to read through all the rest.

Which I think is your point. (Maybe you were trying to make it obliquely?)


9,159 post(s)
#23-Mar-20 05:54

The pot calling the kettle black?

Quite right yes.


5,892 post(s)
#23-Mar-20 08:24

If so, why not put that first? Honestly, no one (except me) is going to read through all the rest.

Because that misses the educational value of all the rest of it for someone new to 9 who hasn't been part of the process to date. The better educated people are, the better they can participate in getting what they want. Anybody who knows that info helps them get what they want has no problem reading a few paragraphs.

For example, Ferrari speed is just one of the reasons for doing 9. The infrastructure and huge constellation of capabilities for data engineering / data science is another, perhaps more important reason. If someone doesn't come from the data centric world, they might not realize there are many features in 9 that were added to make it a daily driver in that world, or that those features are in there because people who know their stuff sent in many suggestions.

Knowing that users drove that high functionality in the data centric foundation for Manifold is a helpful guide for anybody now influencing the new interactive GIS features now being added. It's all about sending in the top five priorities you personally have. That's more effective than indirect approaches.

ranger.sean85 post(s)
#23-Mar-20 22:30

Thanks for your response.

I'm well aware of the contribution made by some in the user community. Many of the same folk have been unstinting in helping me with Manifold questions over the past decade.

The intention of my post was to suggest, in what I hoped was a tactful and respectful manner, that some thought be given to how progress with M9 is communicated with also-rans like me. The reference made to features of interest to me just cited some examples already nominated by others.

I'll just keep an eye on build-logs as each version is released.


5,892 post(s)
#24-Mar-20 04:19

that some thought be given to how progress with M9 is communicated with also-rans like me.

Apologies... I got the impression you were more interested in roadmaps of the future than about progress to date. :-)

Future plans are not progress... they are plans for progress, which can and should change as the community reacts to progress and updates priorities. Besides the steady stream of reports adamw publishes on near term outlook for upcoming builds there are fairly regular statements of directionality by adamw and the occasional more global description, like in this thread. All that is in the forum.

The path beyond that to more insights, as discussed in the suggestions page, is to send in suggestions. People who do that on a regular basis naturally get feedback. That's another reason why I recommend suggestions to people who express an interest in futures. It's a "win win" situation with no downside: not only do you actively nudge the future into the direction you want, you also get more lookahead. Much better than letting others decide the future while waiting to hear what they've decided.

As for communications on progress, everybody is equal - no "also-rans" - everybody gets the latest and greatest build at the same time.

Besides the raw notes published in this forum for Cutting Edge readers, there are also release notes in more polished form in Changes and Additions, which often reference new topics, like the Legends topic, plus additions to existing topics, and new videos. It's important to go beyond the raw release notes because those often can be very laconic, where just a few words are used to mention a really big new set of capabilities.


8,970 post(s)
#27-Mar-20 14:40

On a table with a side-by-side comparison of 8 and 9, and a timeline for implementing remaining features from 8 in 9:

First, let me clarify the angle. Is it roughly that both 8 and 9 are big products, who knows which features found in 8 are in the current version of 9 and which aren't, determining this from the documentation is time-consuming and so having a quick summary table would help? That, plus knowing which features that were in 8 but are not yet in 9 are currently being worked on or are going to be worked on soon? If so, then yes, we can create such a birds-eye view with a list of 50-80 items covering all of 8 and a short note for each.


Reading / writing DXF - 8: yes, 9: yes.

Direct editing of geometry coordinates - 8: yes, 9: yes, see Record pane.

Vector / raster registration - 8: yes, 9: no, being worked on.

We can make such a list, put it into a sticky thread, then update it. Or, if anyone wants to make the first pass themselves, they could create such a thread and we can then extend / update it.

409 post(s)
#27-Mar-20 18:19

There are so many modern solutions to this problem, I won't beat a dead horse here (or will I!), but any one of these could be useful.


8,970 post(s)
#30-Mar-20 12:46


The issue isn't collecting votes for what to do - we hear this from the forum threads / email and what we hear pretty much determines what we are then doing and in what order. The request - as I understand it, I asked for a clarification above - is a list of all features of 8 with pointers to equivalent features in 9 plus some notes on features that have no equivalents yet regarding when they might appear. That is, a birds-eye view. Or maybe the request is something else.


6,371 post(s)
#23-Mar-20 13:45

The query builder is a big help in at all steps of the learning curve for SQL users. And SQL flexibility is one of the unique selling points of Manifold.

But I find myself jumping from query builder to SQL documentation, because the query builder reports the expected typ of parameters but not their roll for the process. I would love a query builder that reports more details, at least a combination of parameter type and a self-explanatory name of the parameter as we see in the object reference of Visual Studio for example.

Alternativly it would be helpful to create a jump to the exact position in SQL help of the SQL phrase selected in a query with F1.

Consider a contribution - folding agains Covid 19 -

575 post(s)
#23-Mar-20 18:35

Similar request as Klaus, more prompts with SQL. An example is how the formulas in MS-Excel gives some indications of what arguments are expected. For instance the Payment function is =PMT(rate, nper, pv, (fv), [type]) then as you enter values or pointers to values, when you arrive at [type], a tool tip appears telling you to enter 0=payment is at the end of the period and 1=beginning of period.

The other issue, and it's my learning curve with SQL, is knowing the names of operators and then the arguments. For instance, to transform a real number to an integer, the operator is CASE. I know that is an SQL reserved word. I might need SQL only a few times a year so "CASE' is not always fresh in my mind, I need to search on the Internet. A more common term is Integer, so some way in M9 to arrive at "CAST" by typing "int" or "integer" in the filter box would help. How on earth did someone in the SQL world came up with CAST to mean convert to Integer? But that's another question.

So I tried using CAST today, the screenshot shows as far as I got. I got syntactical help from the W3Schools website. However my field FeatLen_int remains <null>. I'm not saying I don't need to learn SQL however for non-programmers the threshold is too high in M9 to use SQL for even basic transformations such as real number to integer. I end up using RoundDecs as my success rate is higher. The analogy is I shouldn't need to have to learn Mandarin to go to a restaurant serving Szechuan cuisine. The restaurant menu with a few keywords is a help. How to do it in M9? I'm not going to tell M9 engineers how to do it, I'll just describe the desired outcome: make SQL easier to implement in M9 for non-programmers by using more plain English.


181 post(s)
#23-Mar-20 20:56

I think more help with expressions is a pretty important need. I would add to the above, that we need a help page that covered the specific function you are interested in (right-button context menu option?). The help page should include:

  • A short description of the function
  • A description of all the parameters
  • A handful of examples
  • A description of why and when it is useful
  • A description of any special circumstances, things to watch out for, or assumptions

The help page should pop up in such a way that it is persistent until dismissed and does not cover up the transform pane. This is important so the user can work in the transform pane while simultaneously viewing and scrolling around the help page.

Building such comprehensive Expressions Help pages could be a heavy lift but if Manifold provided the infrastructure they might be able to leverage the assistance of the community to help develop it more rapidly and make it more robust.


5,892 post(s)
#25-Mar-20 04:18

SQL is very easy if you take the time to learn it first, the right way, starting with basics and building from there. It can be confusing if the basics haven't been learned.

Start with a Fehily book, like the Quickstart book, and within an hour you'll be functional using basic SQL.

Keep reading (takes surprisingly little time to read the whole thing... couple of days max if you focus on it) and you'll know SQL in no time. Then you're set for life.

the threshold is too high in M9 to use SQL for even basic transformations such as real number to integer.

Well, the threshold for using any language is too high if you don't know the language. Just try ordering something in a French restaurant way out in the country where they don't speak any English, and your results won't be as good as if you have a few words of French.

Luckily, in Manifold there's no need to use SQL for simple things like basic transformations. Use the point and click Transform pane. Have a column with numbers that are float64 and you want a column with those numbers as integers? No problem. Use schema to add a new column that's type integer. In the Transform pane use Copy to copy numbers from the float column to the integer column. Manifold automatically does the CAST.

CAST, by the way, is a general purpose command to transform between many different types of data on the fly. It's a simple enough command, covered in basic SQL guides, but for tips on using it in Manifold the best way is to read the examples that show it in action.

To find examples using CAST, use the Search tab in help. Drill down to the line for cast and you'll see a sequence of numbers after that word. Those are the various pages where "cast" or "CAST" occur in the page.

You're reading the documentation in a Browser, so what I do is a Ctrl-F (for find... works in any browser, I think) to open up a search window for the browser into which I enter CAST. Now, whenever you click one of those numbers in the line for cast the page will automatically show you all the different instances of cast or CAST that you can hop to. In the browser I use (Opera), each instance also appears in the vertical scroll bar as a yellow line. Where there are many yellow lines, there's a bigger discussion involving CAST.

So I just click on the numbers in the Search line for cast and then when I see a topic with lots of yellow lines in the margin I'll read that page, since I know it uses CAST a lot. Here's a good one, for example.

But I emphasize: you don't need to know SQL to work magic with Manifold. The Transform and Select panes go one better in the "Chinese restaurant menu" analogy, because they totally automate a very, very wide range of tasks without any need for any SQL at all. Point and click, pick options from a menu, and off you go.

575 post(s)
#25-Mar-20 06:53

Luckily, in Manifold there's no need to use SQL for simple things like basic transformations. Use the point and click Transform pane. Have a column with numbers that are float64 and you want a column with those numbers as integers? No problem. Use schema to add a new column that's type integer. In the Transform pane use Copy to copy numbers from the float column to the integer column. Manifold automatically does the CAST.

That's great, even easier. Copy float64 to integer and the cast is done automatically. I've bought several hard coy and e-books on SQL, have started in on them. When studying from the books and trying examples I coud do the examples. However I don't use SQL enough to retain or build the memory muscle.

Good tip regarding pre-loading the word or term I'm searching for with CTRL-F then check for a higher density of yellow lines.


5,892 post(s)
#25-Mar-20 07:13

However I don't use SQL enough to retain or build the memory muscle.

Oh, boy, do I know that feeling. :-) Simple things, sure, no problem, but remembering the details of more sophisticated things that seem to come naturally to experts like tjhb and adamw, well.... I need help with those.

My solution to that is to cheat. I don't try to remember stuff but instead I copy from examples and from smarter people that do it correctly. One of the best ways to learn is to use the Edit Query button in various dialogs and panes.

Find a Select pane command or a Transform that does something like what you want, set it up with choices in the boxes and then press the Edit Query button and Manifold will pop open the query that does what you want. It's a real life example of how to do various things in SQL, how to use various SQL functions, and so on.

The new Edit - Join command has an option to Save update query which does a similar thing. The query that it saves is the SQL that powers what the point and click Join dialog did for you. You can open the query and see how the dialog uses JOIN and such. For as simple as it looks, the Join dialog is a marvel of capabilities and when you look at the queries it writes it's a great way to see a lot of practical SQL techniques in action.


9,159 post(s)
#23-Mar-20 22:08

I would like to repeat ranger.sean’s very sound comment above, which was unfortunately shot straight down.

... a table that provides a side-by-side comparison with M8 and a timeline for implementation of features in M9 might be useful for those who aren't frequent visitors to the forum

That would be super useful.

Would anyone like to collaborate, during this common downtime?

No timeline, just feature-feature mapping.

RAR25 post(s)
#25-Mar-20 02:57


I would be interested if you accept please.

Thank you.


8,970 post(s)
#27-Mar-20 14:51

For help with writing queries, we think we need two things before anything else:

1. The API doc similar to the one for scripts (take a look if you didn't see it), with a separate topic for each statement / function with examples, etc.

2. Better error messages for syntax errors.

We have been working on both things in background. The problem with (1) is that we are constantly adding new functions and sometimes new features, so the documentation frequently loses the race. The problem with (2) is that we have a few query features we are considering implementing which could have a big effect on how the query is parsed, so if we do better errors first we'll have to redo it. We agree though that both 1 and 2 have been missing for too long, so maybe we will cook up some compromise which would allow the items to move forward.

bdg56 post(s)
#28-Mar-20 23:28

I heartily agree. It would be most convenient if hovering over a tag in the query builder lower left panel, for a second or two, would pop up a relocatable balloon with particulars of a function. Maybe with a stay on top button and an easy dispose button when done.

598 post(s)
#29-Mar-20 03:58

I have fallen off the wagon, except for the few cases where M9 can do things that other products cannot. M9 has become too heavy for me. I often run into a head-first, head-last type of situation. In other words my thinking pattern is often the reverse of the person who creates the interface so I often struggle to get things working. This often results in me using the wrong operators. This is a slippery topic but I tend not to see what a tool does straight away at a conceptual level or the name of the operator informs me of the tools purpose in an ambiguous way. QGIS often shows what new tools do using animations that run for just a few seconds. These help me a lot. Perhaps that would be a good place to stop. Animated examples of what tools do.


8,970 post(s)
#30-Mar-20 12:37

We do videos demonstrating the new tools and add examples of their use to the online help. Help updates all the time and has its own list of changes where you can see quickly what got added lately.

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