Subscribe to this thread
Home - Cutting Edge / All posts - Manifold System 9.0.163.x

8,579 post(s)
#21-Aug-17 18:21

This is the series of the "Manifold Future" builds.

For details, see Transition to Manifold Future Editions.

SHA256: 3bd3bacc77cfd6001726223ddd8e7f1b121a564231b4e49cd068f27087de145d

SHA256: b000fab25406b4dc4eaea83123cec38e42444c540f539dba95b7d156f5357c95

Changes for

Changes for

Changes for

Changes for


8,579 post(s)
#21-Aug-17 18:21


There is a new Contents pane which can contain multiple subpanes. It is going to contain all other panes except the Project pane.

The Info pane is replaced with the Component pane in Contents.

The Component pane shows icons for components and data sources. If a component referred to by a parent component does not exist, it displays without an icon. Clicking a component or a data source selects it in the Project pane.

The Component pane shows icons for fields and indexes. If a field referred to by a component does not exist, it displays without an icon.

The Component pane shows temporary indexes built in component windows.

Switching between component windows updates the Component pane immediately rather than after a short delay.

The Component pane shows info for the active layer in a map window.

Opening a drawing, image or labels creates a virtual map which can accept other layers and work with them. The View - Open Table command is removed as no longer necessary, use the Open Table command in the layer tab menu.

The Component pane shows the coordinate system of a map and the active map layer side by side. Both coordinate systems can be edited directly in the pane.

Settings related to the layout of panes are decoupled from Radian / earlier versions of Viewer to avoid settings made by older builds from affecting newer builds and vice versa.

(Fix) Continuously rendering a preview of a drawing transform using the advanced rendering engine no longer sometimes starts ignoring line styles until the preview is turned off and back on or allowed to complete.

End of list.


3,113 post(s)
#22-Aug-17 00:13

thanks. If you are going to be showing interesting information like the spatial index field, coordinate system, etc., you might want to consider also showing the number of records. Table objects don't really show much of anything in the contents pane, and if you open up a drawing, it seems wasteful to call it the "Active Layer", as it is the only layer. It makes sense for the Map component for sure, but there isn't much use for it with a drawing.

On another note, the pane seems to take up a bunch of real estate, and I wonder if right-click / properties of 8 would accomplish the same goals. Maybe I am just more familiar with 8, but changing coordinate systems with a right-click was really easy, and the Contents pane just seems to take up too much space. It might just be me, but I'm a hot-key guy, so I like that.


8,579 post(s)
#22-Aug-17 06:49

We are going to show the number of records when we can. Some of the controls we previously had in the Info pane are currently being worked on and are going to reappear in a reworked form.

The Contents pane does take a lot of space. We need that space because we want the pane to contain all of the current big dialogs like Transform / Select / Style.


6,319 post(s)
#22-Aug-17 07:43

We need that space because we want the pane to contain all of the current big dialogs like Transform / Select / Style.

I'd love to see, that this transition would be combined with makeing all these dialogs unmodal. Apply wouldn't close the dialog. And a new selection would preset controls with the concurrent properties.

That would however call for a three-state controls or additional checkboxes with the states <apply - don't change>. So we could decide which of the controls in a dialog should overwrite existing properties of a heterogeneous selection.


8,760 post(s)
#22-Aug-17 01:23

File > Import > *.gpkg seems broken.

Nothing happens. No result, no error.

OK with and earlier.


8,579 post(s)
#22-Aug-17 06:50

We cannot reproduce this.

Can it be that used different versions of SQLITE3.DLL / SPATIALITE.DLL than


8,760 post(s)
#22-Aug-17 07:12

That must be it, or just user error, I will check. Thanks.


8,760 post(s)
#22-Aug-17 01:29

I think the idea behind the Contents pane is plain stupid.

What we need to know (but don't) is not per-component. The Info pane did well for that. Don't change it unnecessarily.

What we need to know (but currently don't) is information per object.

We need a pane or window for the current object, with all of its data, and its location, and its rect (zoom), and then active links between all of these. Duh. Obvious. As in Manifold 8 but better.

The Contents pane currently looks like a stupid idea. Good for programmers, useless for users and their data.

Wrong direction. Maybe that will change given different plans.

Manifold can do anything. But is it asking the right people the right questions, in the right way?


8,760 post(s)
#22-Aug-17 01:51

Here's something I always need to be able to do:

  • Filter objects by SQL
  • Save the filtered set for re-use
  • Pan and zoom, to inspect each filtered object
  • Re-filter inspected objects manually (subtract some from the set)
  • Save the re-filtered set for re-use

Basic. Can't.


8,760 post(s)
#22-Aug-17 03:00

I think this workflow may be made more difficult by a streaming data model.

But I wouldn't use Manifold.Next if that workflow were not at least as easy as in Manifold 8.

(Easier, really.)


5,452 post(s)
#22-Aug-17 04:34

The Contents pane currently looks like a stupid idea. Good for programmers, useless for users and their data.

Wrong direction. Maybe that will change given different plans.

Manifold can do anything. But is it asking the right people the right questions, in the right way?

All fair points and good feedback but off the mark due to our fault not yours.

The first cutting edge build is, indeed, a programmer's test, not the final product or even the final iteration for the Content pane. We should have made that clear and explained what it is, what is being tested and what it is supposed to do.

To see where this is going consider one of the biggest ease-of-use differences between Radian and Release 8. 8 has an array of "always on" toolbars for formatting, selection and transformation that accomplish in fewer clicks than what are required in the analogous Style, Select and Transform dialogs in Radian. The 8 toolbars also provide either a visual read out (format bar) or persistent access to last-used operation (select, transform bars).

An example of that is changing the size of points. In 8, click a layer and you see in the format toolbar what the size is. Changing it is one click into the same sample well. In Radian, you have to launch the Style dialog, scroll down to the point size property, change that in a different well (not the sample) and then apply.

For .Next we want 8-style, "always on" reporting and direct manipulation but without losing the greater capabilities of the Radian dialogs. We believe that means switching from dialogs that must be launched to panes that can be always on. The first step in that is repackaging the machinery which alters the relevant properties in Radian from dialogs into panes.

Technically, the big jump is repackaging the code from the procedural world of dialogs to the "always on" always immediately responsive world of panes. Doing that repackaging in a way which is highly responsive and which respects and preserves all SQL-first machinery is not trivial and must be proven to have been done correctly. That is what 163.1 does. Really, it is a classic internal development build that is part of our way of feeling through what it means to be conducting a development process in public. We have to do that part of it differently.

About the interface:

The "component' dark bar in the current Content pane is just a placeholder with the technical read-outs used in development to verify that the dynamic machinery of updating works correctly in the most demanding situations.

The Content pane looks empty because all of the other elements (Style, Select, Transform for starters) have not yet been repackaged from dialogs into Content pane elements. When they are repackaged in the days ahead the Content pane will be populated as a very useful, always on, display.

It will show formatting, have Select capability and Transform capability, and have things like Saved Selections (now hidden too many clicks away in the Saved tab of the Select dialog) immediately at hand and so on.

As a placeholder, the particular makeup of the current Component element is there to verify the machinery has been repackaged correctly. That's why, for example, the readout for indexes is there, because it is picking up a construct on the fly from the drawing's table.

Likewise, the Initial Projection setting is there, not because it is a good idea to expose such a risky setting as a trap for people to change. thinking it is a Change Projection setting, but because that's a good indicator the read-out and then change-on-the-spot writeback machinery is functioning correctly in terms of back and forth dynamism in the floating re-projection world where maps and layers can have different projections.

As far as we can tell, all that machinery is working fast and correctly, both to report the properties and such as they are and also in the writeback machinery to change them from a dynamic pane. It's all synchronized correctly. Open a map with many layers and click any of them and the synchronization of display and writeback is instantaneous and accurate.

People who have participated in Manifold beta programs know that they are not for the faint of heart, one reason being our habit of unleashing totally nerd-alert development builds as part of the process that serve an engineering need but which can seem bizarrely out of sequence from a user interface progression, and to do that without a word of explanation or forewarning but for a few cryptic release note comments.

It's obvious we have to adjust that now that the process is entirely open to the public, that we have to keep artificial engineering builds internal or at least warn people up front what the thing is supposed to be testing and that no, we don't think this is the right idea for the user interface.

As an engineering test console to verify synchronization for the new machinery that replaces dialogs with panes, 163.1 works great. But we should have looked at that and instead of thinking "perfect. the machinery works." we should have thought "wait a minute. can't issue this as a public build without advising what it is, what it tests and what that will look like with the real user interface."

Sorry for that disconnect. It's our fault and in the future we will advise up front if something is an engineering build that is is constructed in an unexpected way because it is supposed test a specific thing.

One more thing (almost forgot): the machinery that replaces the procedural world of dialogs with "always on" dynamism is the same whether you put a pane on it or a toolbar.

Toolbars like in 8 tend to clutter the display and can be confusing as menu bars and toolbars get rearranged on the fly to suit different contexts. That is one of the issues that Ribbons, when done well (almost never), are supposed to address. The Content pane with elements within we think will provide a cleaner display that will be less confusing with user or automatic system adaptation to context and will make better use of real estate. If that turns out not to be true we can alter it, but if the machinery that makes either approach possible does not work, that has to get done right at the very beginning.


8,760 post(s)
#22-Aug-17 04:52

Thanks Dimitri. I'll reread before commenting further but here is an initial comment.

No, no, no, no. (Rough summary.)

You should be asking users (a subset if need be) what works for them (us), before you implement (or care) what works at your end.

I think Manifold has just committed the cardinal error of designing for implementation, rather than designing for use.

Everything in your post suggests that (re-read it, you'll see). A great shame.


5,452 post(s)
#22-Aug-17 05:44

You should be asking users (a subset if need be) what works for them (us), before you implement (or care) what works at your end.

Exactly what's been done. My post talks about developing the engineering infrastructure that makes desired interfaces possible. It says virtually nothing about the specifics of those interfaces other than that

a) they must be "always on" as with the 8 toolbars, reporting the situation on the fly without need to drill into dialogs.

b) they must use few clicks to do their work, for example enabling a click into the same well that reports something to change that thing, not requiring a detour through another part of a dialog.

c) they should use screen real estate effectively and not involve many confusing changes of layout.

d) they can be adapted to what the builds show work best, if not panes then toolbars, etc.

That's a fairly generic, non-controversial list, right? :-)

My post discusses the intention of 163.1 for verifying the machinery that makes possible pretty much any constellation of elements that fit the above characteristics. All of those characteristics reflect user opinion, by the way, either as expressed as praise of what people like in 8, what they find lacking in 8 or what they like or dislike in Radian.

Let's take your other post as an example:

Here's something I always need to be able to do:

  • Filter objects by SQL
  • Save the filtered set for re-use
  • Pan and zoom, to inspect each filtered object
  • Re-filter inspected objects manually (subtract some from the set)
  • Save the re-filtered set for re-use

Basic. Can't.

That's exactly what UI elements must do that the new machinery makes possible. Except for the pan and zoom to inspect, all the above is already in Radian, but in a clumsy way that involves too many clicks through a hidden tab (the Saved tab) in the Select dialog, and too many clicks through the Window tab to transfer selections made in tables to drawings or vice versa, and too many detours through SELECT as opposed to selection.

Conceptually, doing what you write above in 8 is much easier because of the "always on" nature of things like the Saved Selections pane, the "always on" acknowledgement and persistence of selection sets in the Selection toolbar (and also in the Transform toolbar) and in the linkage between those selection sets and other facilities and between windows.

What you are asking for in the workflow you cite above is what an "always on" set of controls gives you. You don't have those in 163.1 but the machinery behind the scenes that makes it possible to take many dialogs and to make them "always on" panes or toolbars, and to provide that synchronicity of context *is* in 163.1 ... how is it that providing "always on" read outs, a direct means to change something you see in a single click, and synchronicity of context is *not* building the means to give you what you want? I agree it is not the full set of controls that enable what you want, but it is the foundation that is required to give you those controls.

Given that foundation the move to dynamic panes or toolbars is a snap. Add to that a few minor controls (like the pan/zoom to inspect a particular object), an element equivalent to Saved Selections in 8 (nothing more conceptually than pulling the Saved tab out of hiding and into its own, well-designed and responsive element) and a tightly coupled selection state between a table and a drawing, so you don't constantly have to transfer selections between windows, and you have all the elements to do the workflow you propose with few clicks, as fast as or even faster than it can be done in 8.

A word on selection state: the current system in Radian of allowing each window to have its own selection is very powerful and good for lots of table windows but too abstract and indirect for the way most people use GIS. What Manifold introduced in earlier releases, did in Release 8 and which everybody who does a GIS these days has copied (including ArcGIS Pro, Q and others) is to have a default link with one selection between selection in a table and in every window that showed data from that table. That's the way the GIS will be as well, by default.

apo64 post(s)
#25-Aug-17 10:25

Bouncing on the filter and selection topic, a nice feature just arised on our side playing with Radian for few weeks and Manifold for several Years. The idea is to enhance the theme component with two new dimensions of freedom for the user.

Today the theme allow us to set a another visual scheme but what about allowing to work only on a subset and moreover on a geometric transformation of of the original geom. An example, If I have roads in a Drawing and I want to display only Motorways using a buffer for the daily traffic I need today to duplicate the Drawings. This is not a problem in itself and can be quickly done but any update in the data needs to recompute the whole. Another way to do it today is using queries and linked drawing, smart and useful but a bit more tricky to remember in time because of the dependancies between components. Our idea is to propose something similar to the new transform dialog for the theme dialog merging the selection, the geometric transform and the visual aspects in one.. Just a centime to the discussion.

Best and thank's for the very good work 'til now



5,452 post(s)
#25-Aug-17 14:24

Our idea is to propose something similar to the new transform dialog for the theme dialog merging the selection, the geometric transform and the visual aspects in one.. Just a centime to the discussion.

A very interesting idea. What is now the transform dialog will become a transform pane element. OK. Suppose instead of a choice between Update Field / Add Component there was also a third Add Query. You could then create a drawing on that query. So, if you wanted to work on buffers about a given set of roads you could have the dialog generate a query providing the results in a form that could be consumed by a drawing.

Much (not all) of that is possible now. To not write a complete query from the ground up you can use computed fields in a table. For example, if you want to work on buffers about objects, have the computed field be called Geom2 and be populated with something like GeomBuffer([Geom], 20, 0), and then you create your drawing on Geom2.

It's something to look at once we get the GIS published - the basic infrastructure can support such things.

apo64 post(s)
#25-Aug-17 16:20

Yes it is true we can do the whole today already both in radian and M8 using the queries. But speaking of GIS functions it was more to add some "less SQL" approach for the dummies merging the theme idea with the transform dialog/pane. What I find smart is to have the components "liked" in the project pane.

By the way using a lot of themes in our mapping work we have to export and re-import themes as xml files to apply the same theme accross the Drawings/Themes. For the Layout templates / coord systems you provided the possibility to do the same but you also allow us to import it directly from an existing component without passing by the file. I will find nice to have the same with the themes, what we have done using a script until now. Sorry I should maybe have used a new post for that but it just came to my mind.




8,579 post(s)
#22-Aug-17 06:52

We need a pane or window for the current object, with all of its data, and its location, and its rect (zoom), and then active links between all of these.

And we are going to have it. This is just the first build.


8,760 post(s)
#22-Aug-17 01:59

To repeat: is Manifold asking the right people the right questions, in the right way?

The first build towards Manifold Future is not only disappointing, but goes in the wrong direction in my opinion.


8,760 post(s)
#22-Aug-17 02:14

A better question perhaps.

Will there be a runtime build for Radian Studio (should be), or for Manifold Future?

If we write a dependent application, how can we distribute it?


5,452 post(s)
#22-Aug-17 06:12

Will there be a runtime build

Yes. The current trend in software is to tie users to purely server-based product (Software as a Service, 100% cloud based, web applications, etc.) but Manifold will continue, at least for this next generation, to offer standalone products in the classic manner, including runtimes that support the development of non-server based applications.

By the way, moving everything to server-based product is not a bad thing for many developers. It solves a lot of problems for value added developers such as always-fresh and current installations, eliminating distribution and installation woes, getting paid (less piracy), professionally securing critical data, providing flexible procurement for users, etc.

There is some pushback right now from users to how some vendors are forcing web-based applications onto their users in a way that clearly is more in the vendor's interest than the user's. Sometimes it is obvious the intention is not to provide a better experience for the user but to a) eliminate piracy, b) lock the user into the vendor, c) force the user to spend more, and d) convert the user into a product that can be sold to advertisers and other third parties. But that doesn't mean that when done right a web-based scenario is not very good for both user and vendor.

Manifold's approach will be a continuation of what is done now: provide strong IMS capabilities for those who want to do web-based applications and also to provide runtimes for those who prefer standalone applications.


3,113 post(s)
#22-Aug-17 00:31

The moving of objects from one database to another works really well. Much safer now.

One issue I found: I tried to move a table that had a geometry column in it (no index or coordinate system, just a geometry field and a couple of other fields) over into SQL Server, and got the following error:

Table dbo.testtable does not have a clustered primary key as required by the spatial index...blah, blah, blah

I was able to move a table without a geometry in it, and I was able to move a table with a geometry and spatial index, but not a table with a geometry and no index.


8,579 post(s)
#22-Aug-17 06:55

We are going to look into it.

(In general, the error seems related to a limitation of SQL Server: spatial indexes on SQL Server operate off other indexes and so if you don't have those other indexes that can be used to uniquely identify records, the database cannot create a spatial index. But you are saying that the table did not have a spatial index, so we are going to check why are we asking SQL Server to create it.)


8,579 post(s)
#22-Aug-17 09:38

We cannot reproduce the error.

If I create a new table in a MAP file with a geom field and a geom value using:



INSERT INTO v (g) VALUES (GeomMakePoint(VectorMakeX2(5, 6)));

...and then copy and paste it into a SQL Server data source, I get no errors.

Does the copy and paste of such a table not work in your case? If copy and paste works for this table, but does not work for your table, we'd like to look at the schema of your table.


3,113 post(s)
#22-Aug-17 12:20

Hi Adam. I took an existing table and used SQL to create a new one:

SELECT geom, oid 

INTO newtable 

FROM sometable 


8,579 post(s)
#22-Aug-17 13:10

...and this statement failed. Correct?

If so and if sometable is on SQL Server, and geom has a spatial index, that table should have a non-spatial index as well (otherwise the spatial index would not be there). Could it be that the non-spatial index uses some field other than oid? If so, just SELECT that instead of or in addition to oid.

We can make SELECT INTO create a new table without any indexes, but since that's a big time-saving feature (which allows you to, say, select a subset of records in a table into a new table and have that new table be immediately editable / usable as a drawing or image, etc), managing it will require additional syntax. Which we aren't afraid of adding, but you will still have to write it / keep in mind that it is there.


3,113 post(s)
#22-Aug-17 13:24

I'm sorry if I'm not clear - writing this from a hotel in Korea.

I wrote the query in Radian. Then, tried to copy the table into SQL Server. That's when I got the error.


8,579 post(s)
#22-Aug-17 13:44


I cannot reproduce the bolded bit here:

I was able to move a table without a geometry in it, and I was able to move a table with a geometry and spatial index, but not a table with a geometry and no index.

Maybe I misunderstood or misinterpreted.

Here is how it should work - using a table (newtable) set up like in your example, with a geom field and an oid field, and some values:

1. If the table contains no indexes at all, it copies to SQL Server without issues.

2. If the table contains a btree index on oid, it copies to SQL Server without issues.

3. If the table contains an rtree index on geom, it fails with the error you describe. Because of a limitation of SQL Server - you cannot have a spatial index without a unique index, see my prior posts.

4. If the table contains both a btree index on oid and an rtree index on geom, it copies to SQL Server without issues.

If you are hitting case 3, that's expected. If you are seeing anything else, then yes, something is wrong.


3,113 post(s)
#22-Aug-17 14:18

Yes, it is purely case 3.

At least this is now on the forum for others to find if they get that error message.


8,579 post(s)
#28-Aug-17 17:41


The table window supports the View - Refresh command which refreshes record values. Being able to refresh record values is useful if the table is changed outside of Manifold - for example, from a different machine. In this case, refreshing record values allows seeing changed values without having to close and reopen the window.

The View - Refresh command in the table window re-reads table schema. Re-reading table schema also refreshes virtual components based on the table.

The keyboard shortcut for View - Refresh is switched from F5 to Shift-F5 to avoid conflict with View - Run.

(Fix) Raster dataports no longer fail to apply world file coefficients to coordinate system data supplied via a PRJ file.

Coordinate system pickers merge favorites and edit buttons into a single button.

The coordinate system picker for a map layer in the Component pane supports changing coordinate system in addition to assigning initial coordinate system. The main menu no longer includes commands related to coordinate systems (all of them are available in the Component pane).

Dataports mark components with incomplete coordinate system information using a specialized coordinate system property. Coordinate systems marked as incomplete display in red color.

The coordinate system picker for a map layer in the Component pane disallows reprojecting a component from an incomplete coordinate system.

Coordinate system pickers detect coordinate systems with YX axes or with axes corresponding to 3d Cartesian space (used for intermediate coordinate systems - for example, in EPSG) and signal the unusual order of the axes by printing it on the right side of the control.

The coordinate system dialog displays the order of the axes at the bottom of the dialog, allows selecting it for a custom coordinate system, and allows forcing it to XY for all types of systems (on by default). Forcing the axes order of a coordinate system to XY keeps the original definition (eg, EPSG code) of the system whenever possible. (The only two cases where a coordinate system definition has to switch to JSON is PRJ and XML. EPSG, SRID and other codes stay as codes and get a small extension.)

Coordinate system pickers allow switching axes of the current coordinate system from YX to XY via a command.

Altering the coordinate system of a map via a script or query makes map windows displaying the map zoom to fit.

The system provides a default favorite base coordinate system for WGS84.

The system provides default favorite coordinate systems for Pseudo-Mercator and lat/lon.

The favorite base coordinate systems dialog and favorite coordinate systems dialog allow readding default favorites in case they have been deleted. Attempting to readd default favorites for a second time will select existing favorites.

The favorite base coordinate systems dialog and favorite coordinate systems dialog allow adding a new favorite from within the dialog.

(Fix) Exporting an image to ECW no longer sometimes closes application in case of a failure.

The DGN dataport exposes a btree index on tables with geometry data.

The DGN dataport supports more types of vector data and more types of curves.

(Fix) Various file dataports support Unicode filenames, including references between files.

Database dataports better recover from partial failures during making changes to table schema. (Previously it was sometimes necessary to close and reopen the database to correctly detect all changes.)

End of list.


3,113 post(s)
#28-Aug-17 18:51

thanks, Adam. I'm not sure where to put this, so I figure it is best here. When you use the GeomClip with mixed coordinate systems, as you know, 9 does not return anything because the GeomClip function does not support mixed coordinate systems. In PostGIS, when you try and use ST_Intersection on mixed geometries, it says "cannot perform the operation on different SRIDs", or something like that.

Rather than returning nothing from a GeomClip, if there are mixed coordinate systems, I think you should alert the user that they need to change the coordinate systems of one of the drawings.


8,579 post(s)
#29-Aug-17 06:38

Using GeomClip with mixed coordinate systems is like summing miles and meters - the function itself cannot tell if the values are compatible, it just receives two sets of coordinates (GeomClip) or two numbers (sum) with no additional data.

We understand the desire for the system to detect a mismatch in an arbitrary ad-hoc query written by hand, it is usually tied with the desire to automatically convert data between coordinate system for the duration of the operation (queries generated by dialogs include additional code to do this). We might actually be able to do this when the query is compiled, we preserve plenty of context to make this and other sanity checks possible. We will look into it.


5,452 post(s)
#29-Aug-17 08:06

In PostGIS, when you try and use ST_Intersection on mixed geometries, it says "cannot perform the operation on different SRIDs", or something like that.

That's useful, for sure, but simple cases are usually simple to implement. I'm curious how PostGIS handles the general case since that is what we must do. How does PostGIS handle it when you try to use ST_intersection on a query involving three mixed geometries where none is resident on PostGIS but one is, say, in SQL Server, the other is in Oracle and a third is a drawing in an ESRI geodatabase or a linked DGN using a legacy way of specifying coordinate systems, not an SRID, but exactly equivalent albeit phrased in a different way?


3,113 post(s)
#29-Aug-17 14:04

that of course is the beauty of Manifold 9 - you can run queries on data sources from all kinds of places. In Postgres, all the data has to be inside of Postgres.

Now, as far as ArcGIS is concerned, it doesn't really care. Of course, you aren't using SQL in that case, but ArcGIS commands, but you can overlay a shapefile with an SDE database or with a layer from PostGIS, Oracle, or whatever. In the attached image, you can see that I have layers coming from a geodatabase AND a sqlite database, and ArcGIS is perfectly happy to run an analysis on it.

Also, you can use Arcpy to run the geoprocessing functions as well. It's not worried about the coordinate systems, and simply does the projections on-the-fly in the analysis.



3,113 post(s)
#29-Aug-17 14:13

Just in case anyone was interested, in QGIS it is the same thing. I just brought in a .shp and a PostGIS source, both with different coordinate systems, and was able to perform a spatial query.


8,579 post(s)
#29-Aug-17 14:15

...with an interactive tool.

Not with a query.

The interactive tools that we have also take care of coordinate systems automatically.


3,113 post(s)
#29-Aug-17 15:46

yes, absolutely. That is a good thing, but there is a wonderful flexibility offered in the SQL (see some recent correspondence with Dimitri and another contact at Manifold for background on this). And, the transforms are faster at the moment, so that is good too.

136 post(s)
#29-Aug-17 00:04

Cool that you can now refresh a table updated in another source with shift-f5.


3,113 post(s)
#08-Sep-17 13:59

The content pane is getting better. However, I have a drawing with the following coordinate system:


however, this is simply reported as:

Transverse Mercator

Now, when I attempt to make the "Transverse Mercator" a favorite coordinate system, and then change the coordinate system of a new drawing to match it, anytime I use a SQL spatial construct (i.e. GeomClip), it returns nothing because it thinks the coordinate systems are different. However, Manifold 9 understands this when using the Transforms.

So, workflow:

1. Drawing A has the NAD_1983_UTM coordinate system, but it is reported as Transverse Mercator in the Content pane.

2. I save the coordinate system (Transverse Mercator) as a favorite.

3. I then reproject Drawing B to match the Transverse Mercator system.

4. A GeomClip returns nothing, but a Transform does the actual Intersection.

5. After changing the coordinate system in Drawing B to Transverse Mercator, I copy the FieldGeom.CoordinateSystem value from Drawing A to Drawing B (using the table obviously).

6. Now, GeomClip works as expected.

So, two things:

1. The reporting of the coordinate system is doing something odd in the content pane

2. In something like PostGIS, if the SRIDs don't match, PostGIS tells you, and then doesn't try to issue a ST_Clip. I think you should report that the coordinate systems are different, and not simply return a null table (that is confusing and might cause someone to think that nothing actually intersected).


8,579 post(s)
#09-Sep-17 15:36

How do you do steps 2 and 3, click by click?

We cannot reproduce this as written, quite possibly because we are filling in missing details differently from what happened in your case. (Can it be that you are selecting 'Transverse Mercator' from the list of coordinate systems in the Standard tab? That would be an issue.)


3,113 post(s)
#11-Sep-17 15:39

Sorry I don't have my microphone, so you'll have to just read the slides. But, the attached video shows the process:

1. I am connected to a geodatabase as read only

2. Since it is read only, I can't even copy the information in the FieldCoordSys

3. But, when I look at the coordinate system in the Drawing, it is different than that reported in the Table

sorry for the sloppy video. But, it should give you enough to recreate things.



8,579 post(s)
#11-Sep-17 17:57

The Change Coordinate System dialog starts with both the source and target systems being the same so that the default action is to do nothing = safe. "Transverse Mercator" is the type of a coordinate system, the coordinate system controls display it when the system does not have a more specific name (like, say, "Universal Transverse Mercator Zone 3N"). I don't see from the video that / how you switch the initially provided coordinate system to the one desired, so I am guessing that you might not have changed it - and if so, the Change Coordinate System did not change anything either.

Now, we will allow copying the definition of the coordinate system even from a readonly component, that's a no-brainer. We will also allow projecting a component to the coordinate system of another component just by specifying that other component, without having to alter favorites. And it would perhaps make sense to indicate in the Change Coordinate System dialog whether there will be any actual changes to the coordinates so that nobody forgets to specify the target coordinate system. This should make it easier.


3,113 post(s)
#11-Sep-17 18:27

it really would have helped if I had a microphone - ha, ha.

I should have been clearer. Here is the issue:

1. I had a drawing (Drawing A) in say, lat/lon, and I wanted to move it into the same coordinate system of "Drawing B".

2. Because Drawing B is read only, I cannot actually see what the coordinate system is (you get the first 10 or so letters, but the RO status won't allow me to scroll to the end to read it, or copy it).

3. When I go into Drawing B, I can select the coordinate system pane and I see that it is Transverse Mercator, but nothing else. But, I don't actually know the coordinate system at this point because I can't read it from the FieldCoordSystem and the coordinate system in the Drawing is abbreviated to only show Transverse Mercator. Therefore, I don't really know what to project Drawing A into.

4. Now, this is where my mistake came in. I selected the coordinate system from Drawing B, and made that a Favorite coordinate system (but, sadly, it just says Transverse Mercator): when reprojecting Drawing A, I simply selected Transverse Mercator from my Favorites. I knew it was wrong because the GeomClip returned nothing. I see that if I just select UTM Zone 18..... that it will move Drawing A into that coordinate system.

Perhaps we have to check how Future is handling the coordinate system when I make it a Favorite.

I like how in 8 you could assign a coordinate system from an existing component. That was real handy.


5,452 post(s)
#11-Sep-17 20:13

Because Drawing B is read only, I cannot actually see what the coordinate system is (you get the first 10 or so letters, but the RO status won't allow me to scroll to the end to read it, or copy it).

No, you can get the whole coordinate system easily enough. What Adam says is the right way, that we'll add quick and easy, one-click "use the same coord sys as this" capability, but until then here is what you can do:

Open the read-only data source. You'll see a System Data folder in there... open that.

Copy the mfd_meta table out of the read-only data source's System Data folder.

Paste into the main part of the project. You now have a mfd_meta 2 table that is fully read/write.

Open that mfd_meta 2 table and copy the Value for the FieldCoordSystem.Geom Property for the read-only table of interest (the table for the drawing you want). Now you have the full specification.


3,113 post(s)
#11-Sep-17 21:32

Thanks. That will work to circumvent the read-only issue. Also, I noticed you don't need to copy or paste the table - you can copy the actual coordinate system directly from the mfd_meta table.

In my case, the .gdb had hundreds of layers in it, so the one-click solution will be great when you get it.

On another note (I hope it's ok to ask it here): the "Create Drawing" from a table right-click is so much nicer now. Very easy, as easy as 8. The one problem is that if there isn't an index on an id field, you can Ctrl-Alt-Click the object and get information. Is there any reason why it would not be a good idea to automatically generate a unique ID and index when you create a new Drawing from a table with geometry in it?


8,579 post(s)
#12-Sep-17 07:54

The identity index is something that should perhaps be added in dialogs related to tables, not drawings.

The Create Drawing dialog includes an option to add a spatial index if one does not exist, because it is logical to be thinking of a spatial index when creating a drawing - you might easily not have one in the table, say, because you just created a new geometry field using the Transform dialog, and because creating a spatial index cannot really fail as long as the data source can have spatial indexes. None of this is true for an identity index - it is weird not to notice that you don't have an identity index until you go to create a drawing, and creating it can easily fail due to duplicate values.

Perhaps we should signal that the table does not have an identity index and suggesting adding one when you open it.


8,760 post(s)
#11-Sep-17 22:43

Let's not forget SQL.


? ComponentCoordSystem([GDB]::[Drawing 1])

shows the full coordinate system of [GDB]::[Drawing 1] in JSON format.

The same for local [Drawing 2]

? ComponentCoordSystem([Drawing 2])

Reprojection is a bit wordy, involving a special table object (which we can't inspect like an ordinary table). But the Edit Query button in the Change Projection dialog gives an exact template.

This is based on the auto-generated query, but using component names throughout for readability (rather than raw JSON):



    CALL CoordConverterMake(

        ComponentCoordSystem([Drawing 2]), -- target

        ComponentCoordSystem([GDB]::[Drawing 1]-- source




-- reproject geometry...



    SELECT [mfd_id][Geom], CoordConvert(CALL Conv(), [Geom]AS [Converted]

    FROM [Drawing 2]

    THREADS SystemCpuCount()


SET [Geom] = [Converted]


-- ...and update metadata

ALTER TABLE [Drawing 2 Table] (

    ADD PROPERTY 'FieldCoordSystem.Geom' ComponentCoordSystem([GDB]::[Drawing 1])

    -- new property overrides old property with same name



(In the UPDATE statement, we need mfd_id in the target table, otherwise the records literally can't be addressed for updating, just as we need a BTREE index for editing records in the GUI. I am pleased the template reminded me of this, I easily forget.)


8,579 post(s)
#09-Sep-17 15:27


Generating unique names for new components (as well as fields and everything else) treats a name consisting of a single numeric value as a valid name and appends a unique postfix after it. (Previously, inserting a component named '2017' into a MAP file already containing a component with such a name was renaming the second component to something like '2'. Now, the second component is renamed to '2017 2'.)

The system provides default favorite data sources for image servers (Bing Street Map, Bing Satellite Map, Google Street Map, Google Satellite Map, OpenStreet Maps Base).

The Favorite Data Sources dialog allows readding default favorites in case they have been deleted.

The Favorite Data Sources dialog allows adding an arbitrary new favorite data source without having to create it outside first.

The names of favorite base coordinate systems, favorite coordinate systems and favorite data sources are forced to be unique. Attempting to set the name of a favorite item to be the same as the name of another favorite item of the same type adds a unique postfix.

The Project pane and the Contents pane are made slightly wider. Both panes have a bit of padding at the border to make them work better when undocked.

Context menus in panes and dialogs display the description of the active menu item in the status bar.

Dialogs for favorite items use a new list control similar to the control used for tables. Clicking Enter on a cell starts editing it instead of closing the dialog. Reordering selected favorite items using toolbar commands or Ctrl-Up / Ctrl-Down keys no longer sometimes loses the focused item.

(Fix) The Component pane under Contents no longer fails to update when switching between different windows showing the same component. (Some parts of data, like temporary indexes, are specific to window.)

The Properties dialog uses the new list control. Filtering items no longer sometimes loses selection state for the focused item. Changes to filter text that do not affect the filter criteria (ie, changing the case of filter characters or adding leading or trailing whitespace) are ignored. New properties are inserted using a special item at the bottom of the list instead of via a toolbar button.

The Layers pane is moved under Contents. The list of layers is displayed using the new list control. Making changes to layers outside of the layers pane no longer sometimes loses selection state for the focused item. Deleting the layer for the producing component in a virtual map created for that component is disallowed. (If the user opens a drawing and drops some other components into the window showing the drawing, the layer corresponding to the drawing cannot be deleted - although all other layers can.)

The list of layers in the Layers pane includes a virtual layer for background color. The controls for background color outside of the list are removed. The layer for background color can be turned on and off.

The list of layers in the Layers pane shows layer opacity and allows editing it.

Editing the opacity of one of the selected layers in the Layers pane applies the new opacity value to all selected layers. Same for toggling layers on and off.

The Record Values dialog is reworked into the Record pane under Contents. Alt-clicking a drawing object or an image tile automatically switches to the Contents pane and the Record pane under it, and moves the input focus to the list of values. Alt-clicking an empty space clears the Record pane. Opening a dialog like Select or Transform clears the Record pane. The list of values shows NULL values in gray, similarly to a table window.

The Record pane under Contents includes a toolbar with Move Previous and Move Next toolbar buttons that can be used to move between drawing objects or tiles. The new object or tile is automatically highlighted the in the map window. (We will also autoscroll to the new object, allow moving the window to it, etc.)

Right-clicking the caption for the active pane in the Contents pane opens the next pane. (This saves a lot of mouse movement when switching panes. The cursor is usually near the captions at the top and being able to right-click the caption for the active pane to move to the next pane saves moving all the way to the bottom of the screen.)

Creating a new MAP file or opening an existing MAP file switches to the Project pane. If the Project pane is hidden, it is opened.

Importing or linking a file switches to the Project pane and selects the first new component. If the Project pane is hidden, it is opened.

The new grid control and the table window paint record handles and field headers with a flatter look.

Ctrl-clicking any cell of a record in the new grid control or the table window toggles the selection state of the clicked record. (Previously the user had to click a record handle.)

Pressing Ctrl-Space in the new grid control or the table window toggles the selection state of the current record.

Undocking a window reduces its height more. The undocked window is put into a more predictable position. (The window could previously jump a bit trying to snap to edges.)

(Fix) Closing a MAP file no longer sometimes fails to unlock the file.

(Fix) The DWG dataport no longer sometimes repeats the same label multiple times.

(Fix) The DWG dataport no longer sometimes fails to keep Z values.

The DXF dataport returns all geometry values as 3D instead of returning a mix of 2D and 3D values. (The mix corresponds closer to what it stored in the file, but is generally harder to work with after. We are considering making similar changes to several other dataports.)

(Fix) Attempting to change the schema of a SQLITE table with geometry values no longer sometimes fails.

(Fix) Dataports for 000 (S-57), SID and other files correctly omit setting the coordinate system when there is none provided. (Previously the coordinate system could have ended up set to the default Pseudo-Mercator system. The change allows the UI to detect when the coordinate system is missing and has to be set prior to performing other operations.)

The GRD Surfer dataport adjusts the coordinate system for the image resolution.

The GRD Northwood, MIF and TAB dataports recognize many more coordinate systems used by MapInfo.

(Fix) The image library dataport no longer sometimes fails to render any tiles except the first one.

End of list.


8,579 post(s)
#18-Sep-17 19:59


Attempting to edit a geom, tile or varbinary value in a table window by pressing Enter or F2 or double-clicking a cell does nothing. (Previously, the table window was opening an edit box with "<varbinary ...>" text, starting an edit that could not succeed.)

The context menu for a text value in a table window includes the Edit command which allows editing the value in a dialog. If the value is read-only, the command still allows seeing the value in the dialog.

Attempting to edit a text value that is longer than a pre-defined limit (1024 characters) or contains multiple lines in a table window automatically edits the value using a dialog instead of an inline edit control.

The Properties dialog shows properties for read-only components with gray background.

The Properties dialog highlights changed property names and / or values.

The Properties dialog provides a context menu for names and values with commands that allow copying, pasting, deleting names or values or editing them using a dialog. Attempting to edit a value that is long or contains multiple lines automatically edits it using a dialog.

The Record pane hides the list of values until it gets a record.

The Record pane allows editing values. Editing values enables the Update Record button at the bottom of the pane which saves changes to the record table.

The Record pane shows read-only values with gray background and disallows editing them.

The Record pane highlights changed values.

The Record pane provides a context menu for record values with commands that allow copying, pasting, deleting values and editing text values using a dialog. Attempting to edit a text value that is long or contains multiple lines automatically edits it using a dialog. Copying a value preserves its type, pasting a value converts its type to the type of the target field. It is possible to copy and paste typed values between the Record pane and table window.

Alt-clicking a drawing object shows object coordinates in the new Coordinates tab in the Record pane. The coordinate list shows X and Y coordinate values as well as icons for coordinate types.

The coordinate list in the Record pane highlights the current coordinate in the attached map window.

The coordinate list in the Record pane may include an insert location. Selecting a coordinate and pressing Insert moves the insert location after the current coordinate. Selecting an insert location and pressing Insert removes the insert location. If the insert location is present, clicks in the map window add coordinates to that location.

Starting a new object in a map window automatically switches to the Record pane, selects the Coordinates tab, adds the clicked coordinate and creates an insert location after it. (Further clicks in the map window will add more coordinates. The Values tab in the Record pane allows specifying field values for the new object. The old dialog with the list of coordinates for new objects is removed.)

Adding a coordinate to a geometry value in a map window using Shift-click attempts to end a branch. Ending a branch of a line or area is only possible if the branch is at the end of the value.

Right-click in a map window accepts changes to the current record. Accepting a new point object with right-click creates a separate record for each coordinate, copying entered values from the Values tab of the Record pane to each. Accepting a new point object with Shift-right-click creates a single record with a multipoint.

Pressing Ctrl-Backspace in either a map window or the Record pane cancels changes to the current record. Canceling changes to a new object clears the Record pane. Canceling changes to an existing record re-reads the record and refreshes the Record pane. Pressing Ctrl-Enter accepts changes to the current record.

Pressing Escape in a map window cancels changes to the current record and clears the Record pane. If there is no current record, pressing Escape resets the cursor mode to the default mode.

The Record pane shows coordinates for read-only geometry values with gray background.

The Record pane disallows changing the value of a geometry field that produces the coordinates in the Coordinates tab from the Values tab.

The Record pane disallows changing the values of the primary key fields for an existing record, but allows changing them for a new record.

Clicking a coordinate handle in a map window selects it in the coordinate list in the Record pane. The default click tolerance is increased from 4 pixels to 6 pixels to coincide with the size of the handle for the current coordinate.

Pressing Insert in a map window that edits coordinates moves the insert location after the current coordinate or deletes the insert location, similarly to pressing Insert in the coordinate list in the Record pane.

The coordinates in the Record pane can be selected (using Ctrl-A, Ctrl-I, Ctrl-Space, Ctrl-click). The map window displays selected coordinates using solid dark color. The Record pane allows deleting selected coordinates using a toolbar button.

Dragging a coordinate handle in a map window moves the coordinate. If the dragged coordinate is selected, all selected coordinates are moved together with it. Shift-dragging moves the entire object (without having to select all its coordinates first). To cancel the unwanted drag operation before it completes, press Escape.

The Record pane locks editing coordinates in the attached map window until the Coordinates tab is active. The map window displays coordinates that cannot be edited using a cursor using smaller handles.

Entering coordinates in a map window automatically snaps to other objects in the active layer. Space toggles snap on and off. If snap is turned on, the map window draws a rectangular snap reticule near the cursor. The snap radius is capped to avoid snapping to objects far away from the cursor.

Snapping to coordinates in big layers and / or layers coming from slow data sources captures snap data in background. The map window changes the color of the snap reticule to a lighter shade until all snap data is captured.

The Record pane allows editing coordinates directly in the list. Editing a value of the blank coordinate in the insert location inserts a new coordinate filling the missing values from the coordinate above the insert location.

The Record pane shows Z values for geometry values that have them, and allows editing them.

The Record pane highlights changed coordinates. (There is no separate highlighting for X, Y or Z values, the entire record is highlighted.)

(Fix) E00, FLT, GRD and several other dataports no longer sometimes fail to work with files with non-ANSI filenames.

End of list.


5,452 post(s)
#19-Sep-17 03:04

Just a quick comment by way of look-ahead...

There's a lot in 163.4 that begins the process of editing, but it is important to understand this is just a first big step. We want to be very careful to merge in capabilities, taking it step by step, so that at each level there is a chance for feedback. Taking it step by step very carefully also ensures the product stays totally bulletproof.

The big systems merged now are going to be a kind of spiral approach, getting closer and closer to what we propose to issue as product. 163.4 brings in a big first step to editing. The next build will bring in a big first step to formatting, and so on for a couple of more steps and then we'll come back to editing in the second turn of the spiral to take a final step, a final step for formatting, etc. At each step and at each turn of the spiral intrepid Future users can provide feedback and the engineering team can ensure total reliability.

The core focus on editing in 163.4 is about the "quiet cockpit" approach to editing. It's a lot calmer than 8 and, I think, significantly faster. But it depends on nuances about specific click actions and such to be efficient, so feedback is good (just give yourself a chance to get thoroughly used to it first, as it is a new approach).

The more fully articulated editing will keep that but will add accessory functionality such as more snap types (beyond the snap to vertices now in place), more drawing instruments (draw rectangle, constrain drawing of lines to vertical/horizontal, etc., etc.) and some helpful expansions of instruments (showing what lines would hit if extended, etc.). There are many good ideas ready to be merged. But first we introduce the core style and most basic elements and workflow going back and forth between map window and readouts in panes.

Hope that helps!


8,760 post(s)
#19-Sep-17 03:42

It is excellent, beautiful design. More to test obviously, but so far it is excellent.

Snapping (toggled with space bar) works so intuitively.

The Values|Coordinates panel is fantastic.

Everything is right there, we barely have to think.

This is really really good.


535 post(s)
#19-Sep-17 07:07

Could we split the thread into build iterations? The thread may become unwieldy as more functionality rolls out.


8,579 post(s)
#19-Sep-17 09:56

We will start a new thread with the next build.

580 post(s)
#21-Sep-17 23:31

I am looking forward to a new thread for each build. I use the forum in reverse chronological order with the most recent posts at the top and that puts the links to the latest build right at the bottom of the tread. I know that the original post is updated now but got confused when the download links were not associated with the announcement of the new release, the first time I went looking for the next release. It is a small things but I spend most of my day figuring out small things.


8,760 post(s)
#21-Sep-17 23:32

I spend most of my day figuring out small things.

Same :)

Mike Pelletier

1,602 post(s)
#19-Sep-17 16:55

Well I must admit that until I have a use for something it doesn't stay in my head. While I've tried to roll RS into my workflow it has too many holes to make it truly useful so end up forgetting how to use it. Maybe it's because I'm building a house too! Anyway, I'd like to give feedback on the new editing features but its not intuitive enough without some basic help. I understand that the help manual needs to trail the new features. Perhaps a good alternative is a video that demonstrates the new tools and asks for feedback. On the other hand, perhaps I just need to get back in the game and relearn what I've forgotten.

Mike Pelletier

1,602 post(s)
#19-Sep-17 19:14

Okay, I've got my head around the editing some. I guess the idea is to give feedback on what is there rather than what is missing since this is a "first step". I'm not sure the emphasis on displaying coordinate values is all that useful. My workflows pretty much never involve typing coordinate values. Perhaps very useful to others though. If the coordinate values displayed COGO info (distance/bearing) that would be useful.


3,113 post(s)
#19-Sep-17 20:41

While I've tried to roll RS into my workflow it has too many holes

Personally, I think these are the best things to report about. I have done this on many occasions, and that is how the holes get filled in.

In fact, I think these are equally or more important than bug reports because they prevent a project from getting completed due to a missing functionskirt.


1,698 post(s)
#19-Sep-17 20:58

I find myself pretty much in the same boat as Mike (though I have now finished building my house). I also agree wholeheartedly with Art's comments regarding holes and this is something that I have been woefully negligent in doing.

What I do want to do however is to applaud the design of the contents pane. I already find this incredibly useful and I love where it is going. The design for 'quiet cockpit' is superb and though I still need to get to get to grips with its subtleties, I feel that once I do, it will be a revelation in ease of use and elegant design.

Landsystems Ltd ... Know your land |

Mike Pelletier

1,602 post(s)
#20-Sep-17 20:41

Agreed it's best to suggest rather than complain and I feel good about my contributions to the collective thought on bettering Mfd. Also agree that the contents pane is very much welcome addition.

With regard the new editing tools, it is challenging to offer good suggestions without seeing the bigger picture of how new tools will get bolted on. No doubt engineering is thinking through this in detail. Generally, I like how it works on a simple dataset at this point. I'd urge Mfd to design it around projects with lots of layers to get a sense how it will work.

For example, having to click on the tab to activate the layer you want to edit works great unless there are lots of layers in the map. Many suggestions have been given on how to make the tabs easier to use in the last beta. Perhaps one of those implementations would make this new method function well.

Clicking on the coordinates tab to start editing is nice to avoid unwanted edits but I don't like having to move cursor across the screen to activate it. Perhaps a keystroke to activate would be good.

I'd love under help a simple list of keystrokes for quickly referencing them. This seems doable during the software's growing pains vs a full blown help manual.

The coordinate info is marginally useful in my world. I haven't been able to think of ways of making it more useful other than having it display distance and bearings. If that takes up too much resources, then make it an option. I do like the idea of any box in the software containing a number allowing a user to type in simple math expression to change the value. For example, "xxx*2" or "xxx+2". Still don't see using it much in the coordinate tab.

Make sure we can select groups of coordinates of an object in the map rather than just in the coordinate tab.

The space taken up by coordinates could rather give some statistics on the object such as number of branches and coordinates and how many are selected. With very large objects it would offer some reassurance that you are not deleting coordinates you don't see on the map because of the zoom level and location.

Thanks Dimitri for the editing video! I think it's very valuable and lets people get up to speed quicker. Perhaps it's a way to ask specific questions of us as well.


535 post(s)
#21-Sep-17 02:31

I've had a good drive around editing, and concur.

A couple of standouts for me is firstly the consistent use of the preview before committing a change. That's a really slick approach.

Secondly, 've been editing and inspecting area boundaries. The coordinates pane with its tabular approach, and full editing is great. Cut and paste between is good. Filter on coords would be useful ( select records with identical X values etc)


5,452 post(s)
#21-Sep-17 11:07

Perhaps a keystroke to activate would be good.

Agreed. I've written up some possibilities and have submitted them as a suggestion. Engineering has to sort through available combinations considering what is coming.

Make sure we can select groups of coordinates of an object in the map rather than just in the coordinate tab.

Agreed. I love being able to select more than one vertex for common action like moving them all together, but I don't like having to do that only in the Coordinates tab. I've suggested some ideas as to how that could be done in the map window.

The space taken up by coordinates could rather give some statistics on the object such as number of branches and coordinates and how many are selected

I don't use coordinates much myself, either, but they have their uses, especially with point locations, and when you need to edit coordinates, you really need that. The Coordinates tab today is there for such cases and, more importantly, as a signal that the object is "in play" for viewing and editing the geometry, as opposed to the Values tab that signals the data values part of the object is "in play" for viewing and editing.

We intend to have a variety of Coordinates views from appearing in that tab space, quickly and easily available to the user depending on what aspect of the geometry they want to see, what tool they are using and so on. For example, you could switch to a COGO presentation, or a more Info/statistics presentation as you write above. For a tool-based use, you might want to draw a circle with readouts for radius and such, or create a line using COGO progression of bearing and distance to the next coordinate.

The suite of object creation tools right now is very simple, but there will be a few more added, just necessary ones and not any of this "kitchen sink" stuff with lots of weird tools that nobody uses. :-)

Perhaps it's a way to ask specific questions of us as well.

Glad you mentioned that. :-) There are two specific questions:

1. I would love to see lists of the top three or five editing tools you would like to see. Assume that motions can be constrained to orthogonal (vertical or horizontal), since that's coming. So, what is the necessary, minimum set? Draw box? Draw circle? Draw box on center? Draw ellipse? I think for example, that a draw box is good but people don't use a draw box on center so much. In contrast, a draw circle on center is necessary but a Draw Circle where the circle fills in from one corner of the marquee box to another is not as useful. Drawing ellipses is very rare and perhaps better done by first drawing a circle and then reshaping it. Just thinking out loud as I don't want to influence anybody but giving illustrations of what I mean as top five tools.

2. Right now once you create an object, say a line, you can later choose it for editing to change the geometry. You can insert new coordinates into a line, for example, by choosing the insert vertex and the pressing Insert on the keyboard. But... you cannot extend an existing line that way because if you choose the last vertex and press Insert that starts a new branch. It's critical to be able to start new branches, if for no reason than to draw area objects with holes in them. Right now there is a cumbersome way to extend a line which is perfectly logical once you do it a couple of times, but nobody likes that. The right way to extend an existing line, current thinking goes, is to just add a branch to it where the first click snaps to the end of the line and then you join the two branches together into one. That can be a one-click deal given a toolbar button. Also, doing it that way generalizes to multi-branched objects such as lines with several branches. I'd be curious to hear people's thinking on this for ways that a) don't require opening up some new dialog or additional tool (like the Extend tool in ArcGIS Pro, I believe...), b) work within the existing interface, c) minimize the number of additional clicks required, ideally to just one click in addition to whatever clicks are required to draw the extension desired, and d) generalize to all types of objects and geometries.

I'd be curious to hear what people think of the above and what their preferences are. Thanks in advance!




6,319 post(s)
#21-Sep-17 14:52

Orthogonal editing is great as not-orthogonal buildings are so rar that unclean editing is stiking.

However orthogonality should start aligned to a selected objet or mor important last added segment of any bearing of a line or area object. I.e. this mode would have to be toggled while editing an object.

We might want a "magnetic" 45° direction as well similar to the new coordinate snapping mode (as known from AutoCAD) but +-90° is most important.


5,452 post(s)
#21-Sep-17 15:06

A quick clarification first: By "orthogonal editing" I mean constraining the next segment (of line or area) to a horizontal or vertical or (may as well...) 45 degree angle, not relative to the prior segment but relative to the window.

I also agree that constraining the next segment to being perpendicular to the prior segment (called a "right angle" constraint in some systems) is a great tool, as you point out, for drawing building outlines. Would you put that ahead of a general horizontal/vertical constraint relative to the map window? How about ahead of snapping to grid intersections?

One can imagine a whole zoo of snaps and constraints and other tools. For example, when extending an existing line you might want to force a continuation of the same segment. You might want it to snap to the first intersection it encounters with another object in that layer. Or, to the first intersection with any visible object in any layer, not just the active one. That's a common duality for other snaps as well, with a choice of snapping only to objects in the same, active layer or snapping to any visible object in any layer.

Over time, of course, everything can be added. The key thing is to know what everyone would prioritize to get first. I have my own list, of course, but I am very curious what everybody else's lists look like. :-)


6,319 post(s)
#21-Sep-17 23:31

Would you put that ahead of a general horizontal/vertical constraint relative to the map window?

As editing tool? Definitely. For objects orthogonal to the map window I use snapping to the grid or create tiles in Mfd8. That's not what helps manual digitizing in the map window.

Some of the editing tools you mention are known from AutoCAD and I thick Radian could do better than they do. Have to think about that list and how to implement functions - like for instance: extend a line to the next object when you hit <E> in editing mode and continue the line to the next object with another <E>.

Priority layers I see to lead snapping but possibly more important to lead an Adjust Topology Command, that never changes the priority layer, say a survey layer.

Mike Pelletier

1,602 post(s)
#22-Sep-17 05:19

How about have drawing toolbar with 5 icons: point, line, area, edit, and select tools. After selecting area you can press B for a box, C for a circle, etc. Select point and press M for multipoint, Have the icon change a bit after pressing the letter. Maybe make the various options of each tool available by dropdown as well.

Have Edit tool function default to adding vertices by a click on the line/boundary and drag the new vertice in one smooth motion to the desired location. That is the best method I've ever seen. Like above press keys to modify the edit tool to various specialty tools. One of those could be pressing C to change it to a continue tool that would continue drawing a multipoint, line, or area object from the location/segment it is clicked. Snap to the end of the line would continue the line. Click on a segment of an area and it would act like that was the point the area was last being worked on.

Likewise have a select tool with options to change between a single point, clicking out a shape, freeform, rectangle, or elipse. When editing an object the select tool then selects vertices. Along with the point select, how about the contents pane indicate when multiple objects in the selected layer are hit and then provide a means to tab through them (displaying their data values) and then stop when you find the one you want to see info on or to edit.


8,579 post(s)
#21-Sep-17 14:38

Thanks a lot, this helps.

Regarding this:

For example, having to click on the tab to activate the layer you want to edit works great unless there are lots of layers in the map. Many suggestions have been given on how to make the tabs easier to use in the last beta. Perhaps one of those implementations would make this new method function well.

If it is not too much trouble, could you outline what specifically you think we could do to make this easier? I remember various suggestions regarding the tabs, but I am not sure I remember any that would help avoid first switching to the active tab for editing whatever it contains. Or are we talking about clicking on an object from any layer and having the map window automatically switch to the tab containing that object? This is certainly doable. Maybe there was something else?

In general, we tried to make working with tons of tabs easier through the Layers pane. It now has a lot of vertical space to use for the list of layers, it allows doing various things for multiple layers simultaneously, it allows doing everything from the keyboard and keeps the focus after each operation, etc. We would absolutely like to improve the horizontal tabs as much as we can too, but if you have tons of tabs, the Layers pane will probably work better because there is just more space plus scrolling plus possible filtering.

If there is a specific idea for improvements in this area, we'd be happy to implement anything.

Mike Pelletier

1,602 post(s)
#22-Sep-17 04:40

How about creating a 2nd line of tabs above the first that is user generated for special tabs that one wants to edit or turn on/off often. Maybe mark those tabs with a right click option and have the option to give a short alias name. Or maybe still have one line of tabs but a way to toggle between displaying special marked tabs or all tabs.


8,760 post(s)
#22-Sep-17 04:57

How about a Hide tab/Show tab option for each map layer? As for columns in Excel (and other spreadsheet software).

With a fatter, darker or extra divider between layers when intervening layers are hidden.

It might be possible to select multiple tabs/layers at a time, to hide/show all of their tabs at once.

The important thing for me is to be able to reduce horizontal scrolling across the layer bar when there are many layers. To see, and activate from among, the subset of layers that are currently “most active”, most relevant, while still seeing data from layers whose tabs are hidden (as context).

Data in layers whose tabs are hidden should be locked.

(We have talked before about collapsible layer groups, and maps within maps (Klaus’s idea), but maybe being able to hide tabs without hiding their data would be really enough—and familiar from spreadsheets.)

Mike Pelletier

1,602 post(s)
#28-Sep-17 16:50

Nicely said Tim. Lot's of ways to do this. The fix should be simple and get done.


5,452 post(s)
#29-Sep-17 08:58

Ah, but what is wrong with the layers panel as the fix? There is more room there for all you want, for example, hierarchical tree representations of layer groups, like folders in the file system.

I think the main issue here is that horizontal tabs are not a great way to organize many items. They are fine for just a handful, but not for dozens or hundreds. That's the core issue. To redesign the horizontal tab metaphor to try to force it to do something it is not, as an intellectual/visual construction, very good at just ends up replacing one issue with a different issue.

The file system in Windows Explorer and such is not a bad analogy. If you have hundreds of files you don't want them all lined up in a single line, because then you'd have too much horizontal scrolling to do. Vertical lists or arrays work better. But those, too, are not enough, so Explorer has a left hand pane to show hierarchies of folders.

I get it that people want to create maps with many layers. Part of me says that is a fundamentally wrong thing to do, like creating databases that are not in normal form is a fundamentally wrong thing to do, but part of me also acknowledges that sometimes you just need to get something done and if the way to see something you want to see causes you to end up with a hundred layers in a map, well, so be it.

But I don't think a legitimate wish to manage so many layers should tempt us into forcing a very good control, the tab paradigm, that is so effectively used in so many different applications, into becoming a less good control because it is being distorted to fit a purpose for which it intrinsically is ill-suited.

Can I see the value in having a "super tab" or "group tab" that might expand into a collection of other tabs that are all grouped within that one tab, so you can turn all those layers on/off by clicking that one tab on/off? Sure. I think that is a reasonable stretch of the paradigm. But to get the most value out of such a group tab I think it is best to leverage *in addition* the strong points of something like the Layers panel, where you can show a hierarchy like the way Windows Explorer and similar can show a folder hierarchy for the file system. It's not the tab strip alone we take into combat with us strapped to our belts, it is also the Layers panel as well.

By the way, avid readers of the documentation may have noticed a subtle shift in nomenclature for the Contents pane. There are only two "panes" right now, the Project pane and the Contents pane. That left the issue of what to call the various sub-parts of the Contents pane, like Component, Layers, Record and now (well, very soon...), Style.

"Sub-pane" was just awful so for lack of anything better the previous usage was "section," as in "The Record section of the Contents pane." More recently, a very good word that Tim first used, "panel," has become the word of choice. So now, those sub-pane parts of the Contents pane are called "panels." It's a great word because there is no connotation of "cross-section" or other possible meanings that might confuse, and it brings to mind words like "control panel." Thanks, Tim!

Mike Pelletier

1,602 post(s)
#29-Sep-17 15:47

Thanks for your post Dimitri. It really helps to hear Mfd's thinking on suggestions to encourage us to submit more.

Absolutely the layer pane can suffice but it's not as friendly to use as the tabs so lets make tabs the best they can be. In my work, projects constantly grow with more and more layers. At some point it makes sense to reorganize but to be efficient working with lots of layers is a must. It's what makes GIS so great!

This latest round of discussion on the tabs is spurred by the new editing mode that requires selecting the layer first. That is good but often its nice to jump around and edit various layers one after another. That when it would be nice to use tabs without difficult horizontal scrolling. A command like Alt T to toggle between special marked tabs and all tabs would be invisible to all those who don't need it and would be great for those who work on lots of layers.


5,452 post(s)
#29-Sep-17 18:46

Absolutely the layer pane can suffice but it's not as friendly to use as the tabs

I agree the horizontal tab strip and everything else should be the best it can be - no dispute and in total agreement. But... the above raises a key question: when you really do have very many layers to manage that deserves a worthwhile, purpose-built capability to make that fast and easy, not trying to force a square peg into a round hole by pushing a user paradigm (tab strips) that were not conceived as a way of handling lots of items.

I'm not too proud to admit the best ideas I've used in my life were stolen from smarter people. On the contrary, I'm proud of having the common sense to steal a good idea when I see one. :-) So without fail I'd be happy to steal any good idea for making tab strips more useful as an interface for many items. But that's a movie that's been re-run very many times. I think it's now been decades since people started using tab strips and pretty much any application where they get used a lot sooner or later hits the wall with people accumulating way too many tabs. I look at my browser right now and... there it goes again... dozens of tabs, so many it is really hard to figure out exactly what pages they all point at.

I've seen very many approaches by many smart people to extend the tab paradigm to cover very many items and so far they all ended up being unsatisfactory, just unsatisfactory in a different way with a different way to have to remember besides the universal unhappiness you get with too many tabs in terms of too-small tabs and too much horizontal scrolling.

On the other hand, there are many curating/organizing/hierarchical sorts of things people do with grouping and visual display in things like the layers pane that seem to provide genuine utility. It is out of humility and an interest in pursuing leads to things that seem to help that leads me to say, "if the layers pane is not as friendly as the tabs, maybe the solution is to make the layers pane friendlier, since if you do that you are making a mechanism easier that potentially can provide real muscle in terms of simplifying management of hundreds of layers."

the new editing mode that requires selecting the layer first.

Well, that's a safety measure that helps zero in on what you want to edit in crowded situations. An unfriendly part of 8 is that if you have objects overlapping or many objects from many layers in close proximity you can click away to select something for editing and you can too easily end up selecting something in a layer other than you want. It is much easier if you have that first level filter of "only stuff on this layer." You get something very similar in Adobe applications in terms of their actions within active layers.

Suppose in addition to an Alt-click to select something for editing in the current layer there was, say, a Shift-alt-click to select whatever the mouse cursor hits regardless of layer and then automatically whatever layer that was in becomes the active layer? That's planned, and I suspect would reduce the need to scroll around with layers.

[I'm not sure where that is in the merge plan, but if I recall correctly it is grouped with other "superlayer" functionality like snaps that don't just snap to objects in the current layer but can snap to anything visible regardless of layer.]

That is good but often its nice to jump around and edit various layers one after another.

I hear you on the above and your paragraph that follows, but managing all that from a tab strip is non-trivial. You need controls to specially mark tabs, unmark them, see which are marked within zillions of others and so on. Seems to me all that would be way more convenient in something like a layers pane where you could easily choose filters that just showed what you were interested in, provided hierarchies for grouping sets of layers and so on. If the facilities aren't there to make that easy, what should those be? ...and, if you want to do that in the tab strip what would those facilities look like?

Heck, even right now if there are some layers you need to work with all the time back and forth you can just select those layers and with a single click move them to the top of the stack, turn all others off for display and so on.

Again, since tone doesn't come through I'm not resisting any ideas. I'm just thinking out loud and probing for what the different possibilities could be like.


8,760 post(s)
#30-Sep-17 00:49

I was pleased to get to your last paragraph Dimitri, since I think there is broad agreement that some grouping/filtering of tabs in the tab bar would make like easier, and workflows smoother.

Perhaps there's a slight danger of being distracted by a straw man argument. I think everyone can probably agree that working with (say) many tens or even 100s of map layers is usually a mistake. In these cases it's better to make a second map, and use different maps for different subsets of tasks. Especially since maps are essentially free (even more so in SQL9 than in Manifold 8). Just as it is often a great idea to open more than one browser window (each with multiple tabs) for online tasks.

So let's imagine working with some reasonable number of map layers, the sort of number that might normally be required for an extensive editing task for example. Everyone will have different ideas about this, but looking at some hydrology projects in Manifold 8, I often need 25 layers per map, occasionally 40.

Many layers have descriptive names, made up of say three or four words plus a number and sometimes a letter. This is also an important point. (By the way the more components are present in a project, the more detailed their names must be to make clear sense, although use of child datasources in 9-series products certainly helps a lot here.)

So the question from my perspective is whether it would make life significantly easier, when working in a map with 25 to 40 layers, if we could group/filter/hide tabs for layers which are currently used mainly as context.

In other words, would these changes make it easier to focus, and to switch between small tasks, especially in a complex workflow. Bearing in mind that the Layers panel in Future already looks great and will no doubt become more powerful and convenient over time (some further ideas here of course).

For me the answer is yes.


6,319 post(s)
#30-Sep-17 09:21

I think I'm going another way of working with different layers at the same time - not working in one map but in different maps with synchronized views.

My example and a really old feature request for Mfd8 may make sense for those of us that use topology factory to create REALLY clean topologies.

I don't know how often I have solved problems of desperate ArcGIS co-workers in a few minutes. For those of you that don't have Mfd8 Business Tools: Have a look at the corresponding help topic. You can very easy find and repair all sorts of topological anomalies in one layer on click. And you can decide which object should be changed to match the rules.

However in real life the base of these decisions is often not in the edited layer but in other background layers and it may be more convenient to correct another layer than the one that is currently analyzed by Topology Factory.

So you need to see not only Topology Factory but at least one customizable map with all relevant and formated layers and the possibility to look up attributes of objects in this map(s). As it is now Topology Factory is pinned on top off all windows and must be closed before any other window can get the focus for panning, zooming and selections.

The solution would be 1st. to synchronize views in different maps/drawing windows as the world pane allows now for pan only and 2nd. to make editing tools and tools like Topology Factory unmodal dialogs that allow to switch between windows and keep the state when you come back.

In times of multi monitor cockpits it's much easier to work with different coupled windows than to overload layerbar or layers pane functionality.


8,760 post(s)
#30-Sep-17 21:44

This is absolutely great Klaus, not just an idea for incremental improvement, but something really new.

I've re-read a couple of times so far--there's truly a lot in there--and I would only add a few words, to the second-last paragraph (cheekily).

...keep the state when you come back, plus allow topology to be manually refreshed, to take into account changes made in other windows/threads.

The work that Manifold has put into real-world parallelization is obviously ground-breaking. Perhaps modal dialogs are almost an option for them now. It would be great to see that power used as leverage to enable a workflow like this.

Mike Pelletier

1,602 post(s)
#30-Sep-17 22:34

Agreed, Klaus's ideas would be very welcome additions and I hope Mfd 9 heads that way. I'll just add that the solution should work for the range of simple to complex projects. Sychronizing maps extends the range of map functionality. Filtering and grouping in the layer pane extends the range of its functionality. Being able to hide/toggle tabs extends the range of functionality for tabs. Flexibility to do what makes sense for your project!


8,579 post(s)
#22-Sep-17 08:42

(Just want to say that we are hearing these suggestions and the suggestions in other posts from you and Tim and others in this thread. They are great! Keep them coming.)


6,319 post(s)
#22-Sep-17 07:24

Here is the german UI file for manifold-future|-viewer



8,579 post(s)
#04-Oct-17 17:43


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