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

7,102 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


7,102 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.


2,818 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.


7,102 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,010 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.


7,364 post(s)
#22-Aug-17 01:23

File > Import > *.gpkg seems broken.

Nothing happens. No result, no error.

OK with and earlier.


7,102 post(s)
#22-Aug-17 06:50

We cannot reproduce this.

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


7,364 post(s)
#22-Aug-17 07:12

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


7,364 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?


7,364 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.


7,364 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.)


4,107 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.


7,364 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.


4,107 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.

apo15 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



4,107 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.

apo15 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.




7,102 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.


7,364 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.


7,364 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?


4,107 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.


2,818 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.


7,102 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.)


7,102 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.


2,818 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 


7,102 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.


2,818 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.


7,102 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.


2,818 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.


7,102 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.


2,818 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.


7,102 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.


4,107 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?


2,818 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.



2,818 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.


7,102 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.


2,818 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.

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

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


2,818 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).


7,102 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.)


2,818 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.



7,102 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.


2,818 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.


4,107 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.


2,818 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?


7,102 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.


7,364 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.)


7,102 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.


7,102 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.


4,107 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!


7,364 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.


516 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.


7,102 post(s)
#19-Sep-17 09:56

We will start a new thread with the next build.

Mike Pelletier

1,369 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,369 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.


2,818 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,578 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 |

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