9.0.172.2

Here is a new build.

manifold-9.0.172.2-x64.zip

SHA256: 253d19ef1a72eddf21d564cb049356faf3c1244a4449d2518b69efd75bcedc49

manifold-viewer-9.0.172.2-x64.zip

SHA256: ba231617f2f387d62bab987d755ee0241e1f7b402d6ae04987fde7c9ec0d3ba1

Panes and UI

(Fix) Resizing the Record pane avoids visual artifacts near the bottom.

The Record pane is renamed to Info. The Component pane is reworked into the Component tab in the Info pane. When the Info pane has no picked records, the Component tab is the only tab shown. When the Info pane has a picked record, the Component tab is shown last.

The Info pane separates data for a map and the active map layer using a separator instead of a text caption.

The Info pane shows '(no index)' for a drawing / image / labels with no spatial index.

The Info pane shows the text field used for labels.

The Info pane shows the language for a script.

The Info pane shows the number of lines for a comments / location / query / script text.

Editing a comments / location / query / script automatically saves changes every 5 seconds. Switching to a different component window saves changes immediately. (We don't save changes on every keystroke because this does not work well when a component is stored on a remote database and the connection is slow. Saving every 5 seconds is a big improvement in usability for such connections, and if this will still be too fast in some cases we'll either allow setting the save frequency explicitly or auto-adjust it based on connection performance.)

The comments / location / query / script components no longer support the New Window command, to avoid save fights between multiple windows.

The Info pane shows the page size for a layout.

The Info pane shows the number of fields for a drawing / image / labels / table.

The Info pane shows the dimensions for an image.

The Info pane shows and allows editing the description for any component.

The Project pane reduces the description of a component to the first line for the tooltip. (Previously it was trying to show the entire description.)

Migrating a MAP file created by 8 merges component notes into descriptions.

The command window for a script can be saved to the currently opened MAP file using the Save as Script command.

(Fix) Editing a record in a filtered or reordered table window no longer sometimes shows edits as applying to a wrong record.

Editing whole records in a table window is reworked to use both the table window and the Info pane. Alt-clicking a record cell or a record handle puts the record into the Info pane and starts editing it. Any changes to the record values made in the table window show in the Info pane and vice versa. Attempting to edit a cell for a new record automatically starts a new record and puts it into the Info pane as well. If the table is read-only, Alt-clicking a record cell or a record header puts the record into the Info pane for viewing. Alt-clicking empty white space in a table window clears the Info pane.

The Info pane allows undoing changes to a single value using the Undo Changes command in the context menu.

Changing a value in the Info pane and then changing it back to the old value is interpreted as undoing changes to the value.

Pressing Escape in a table window clears the Info pane if it contains no uncommitted changes, similarly to how this is done in maps.

The Info pane for a table window can move between the fetched records. The Zoom command is renamed to Go, to make sense for a table, the icon is changed as well. (We will likely allow moving beyond the fetched records in the future.)

Reordering records in a table window keeps the picked record.

Filtering records in a table window keeps the picked record unless it does not pass the filter or the filter is applied to the whole table instead of to the fetched records.

The Info pane for a table record allows viewing coordinates for a geometry value using the View Coordinates command in the context menu.

The Info pane for a table record allows viewing pixels for a tile value using the View Pixels command in the context menu.

The context menu for a record handle in a table window includes the Edit Record command which puts the record into the Info pane. (This is an alternative to Alt-click.)

(Fix) Using the color picker on a multi-monitor system no longer sometimes uses an inappropriate color format for the clicked monitor and ends up with a wrong color.

The Info pane allows searching for records in a secondary table that are related to the picked record. To show such records, pick a record, switch to the new Related tab, then click the Setup button in the tab toolbar to specify the relation. The button will open the Related dialog which allows selecting the source table and a pair of key fields. After the dialog is closed the system will search for records in the source table with the value of the key field equal to that in the record picked in the Info pane, and show the first 10 found records in the Info pane. The Refresh button in the tab toolbar repeats the search. The relation parameters are saved in the component window so that they can be used multiple times.

Searching for related records in the Info pane uses a BTREExxx index on the key field if the source table has one.

Searching for related records in the Info pane tracks progress and allows canceling. If the search is canceled, it returns however many records were collected prior to the cancel.

Specifying the source table and search criteria for the related records in the Info pane allows specifying fields to show for the related records.

Switching the Info pane to a different record automatically refreshes the related records if the Info pane is shown and the Related tab is active.

(Fix) Resizing the Properties dialog avoids visual artifacts near the bottom. The minimum size of the dialog is increased to avoid clipping controls.

The layout window allows zooming a layout frame for a map to a location, either stored in a component or that of a different opened window. To zoom to a location, double-click the frame to make pan and zoom commands apply to the frame rather than the layout, then use the location commands in the View menu or in the toolbar.

The layout window allows saving the location for a layout frame for a map. (This is useful when you want to zoom a different window to the same location as in the layout.)

Input / output

Dataports for databases detect disconnects and automatically attempt to reconnect once. If the attempt to reconnect fails, the Project pane shows the data source as disconnected. (Most database drivers automatically close connections after they were not used for some time, to conserve resources. Previously this was putting the data source into the state where it could not return any data and the only method to get it working again was to recreate it or to close and reopen the MAP file. Now we detect such cases and reconnect seamlessly.)

The Project pane allows reconnecting to a data source using the Reconnect command in the context menu. The reconnect is forced: the existing connection, even if it is alive, is shut down and a new connection is established.

Refreshing a data source using the Refresh command from the context menu in the Project pane automatically reconnects to the data source if the connection has been lost.

(Fix) Reading a TIFF no longer sometimes creates extra images for files with pyramids.

(Fix) Exporting a GPKG writes application ID and user version values according to the GPKG spec, to mark the file for third-party clients. (We support the latest version of the GPKG spec available and are creating files of that version. The latest version of QGIS appears to only support this latest version of GPKG partially at the moment, and notifies the user about the partial support.)

Connecting to a GPKG no longer loads spatial extensions like Spatialite and always uses the built-in version of SQLite.

Exporting an image to a GPKG performs significantly faster. If the image has intermediate levels, they are exported as well, otherwise the export only writes the base level.

Creating a geometry field in a GPKG table sets the field type to the appropriate flavor of geometry instead of to 'binary', to conform to the GPKG spec and allow creating spatial views.

Attempting to write to a geometry field in a GPKG table rejects values of disallowed geometry types if the field has type restrictions. (Previous versions of the GPKG spec relied on triggers to reject such values, the latest version of the spec requires filtering without triggers, so we do it - this is a good change, much welcome.)

(Fix) Linking an ArcGIS REST server no longer sometimes leaks memory.

End of list.

Next in the plans are improvements to the Select and Transform panes and to the previews.

The layout window allows zooming a layout frame for a map to a location, either stored in a component or that of a different opened window. To zoom to a location, double-click the frame to make pan and zoom commands apply to the frame rather than the layout, then use the location commands in the View menu or in the toolbar.

It works perfectly, Adam. Thanks for the fast implementation of this feature!

The new arrangement of the Component as a tab in the Register pane (as well as allowing to edit the description in this this pane) also looks fenomenal. Congrats for the great work!

Beautiful build.

A very tiny glitch (I think).

Edit Description text, press Enter to close. Now press the spacebar (maybe by accident)--the Description dialog is reopened. I doubt this is intentional, but it might be.

P.s. now that the Description box is in my face, I will actually use it! This will tidy up my notetaking and in the long run save a lot of work.

P.p.s. I had been meaning to a similar comment about the previous build as well.

I have been using M9 for most of the day, most days recently, and have absolutely loved it. The revised UI is a very pleasant place to spend a lot of time. Splitting the panes between left and right really makes a difference. And we have so much choice about the details. For example I prefer to put Project on the right, mainly because dragging components into the query builder feels more comfortable from there. (But everyone can do whatever makes sense for them.) I won't miss the Contents pane--it no longer feels as if the tools are tucked around a corner.

I seem to have more room on the screen now, not less. Possibly more space in my head as well. It's just plain easier to use.

This is expected behavior.

The '...' button is a standard control, it responds to the Space key. When you click the button, the focus moves to it, so when you exit the dialog, pressing Space presses the button again. We are trying to make panes work similarly to dialogs - the main thing we are currently missing is that you cannot use Tab / Shift-Tab to move between individual controls, but we'll add it in the future as well.

As a general note on descriptions, we are considering extending what we are doing with them and will likely generate them for new components created by tools. We will likely show them outside the Project pane as well.

Very nice changes to the panes! Especially like the ability to pull data into the Info pane from a secondary table/query. That is huge user friendly jump forward and I've never seen it in any other GIS. Very cool.

Perhaps the Info pane could also display the number of records filtered and the number selected? So using made up numbers, something like 100,345 records, 50,000 filtered, 13,331 selected, and 25 fields.

Looking forward to what is coming with the Select Pane. I'm hoping it makes searching for data in maps/tables faster!

We will consider showing the number of filtered records, thanks! We are planning to eventually show the number of selected records as well. The issue with the number of selected records (and the whole reason we do not show it yet) is that we frequently don't know the exact number and computing it on demand automatically is expensive for tables on remote databases. But we have some ideas on how to tackle this.

Some thoughts in case they are helpful. Perhaps show selected records for local tables and for remote/big tables say something like greater than an approximate (>X) or say unknown with a button to calculate it. If it is a really big number of selected records, often an exact number isn't needed.

I'm a bit late to the party, but I'd like to second Mike's proposal to show the number of filtered and selected records in the Info pane. And to better navigate large tables, it would also be helpful to show a table record number in the grey row handle on the left. Thanks!

The second para was a bit backwards. Reordered and edited:

The Record pane is renamed to Info. The Component pane is reworked into the Component tab in the Info pane. When the Info pane has no picked records, the Component tab is the only tab shown. When the Info pane has a picked record, the Component tab is shown last.

Works smoothly, no thought required.

Yes, that's much better, thanks. I'll edit the original.

Is this expected?

New Drawing. Open the drawing. Draw an object, then pick it.

In the Info pane, we now get a Style tab. It can't be used to change formatting. If we change formatting in the freestanding Style pane, changes are not immediately reflected in Info > Style, but only after re-pick the object, then activate Info > Style again.

Moreover this tab seems surplus to requirements--it doesn't seem to add any functionality not provided by the Style pane itself. I may be missing something, or this might be work in progress.

[Added.] This "extra" Style panel has been there for a long time, until 172.0 as part of Contents > Record, then from 172.1 as part of the freestanding Record pane, now in 172.2 within Info.

Does the UI need it? Does it add something that the Style pane itself does not do?

That's the per record style formatting option. Another great Mfd option!

As Mike noted, that's for per record formatting (style overrides). It also shows the style used by the picked object, which can be helpful in complicated settings.

But... what I don't like is that if style overrides are not enabled you get a style controls display where it is not immediately obvious that it is read-only. There should be some visual indication that style overrides are not enabled.

One possibility is to duplicate the "Use style overrides" checkbox and Schema button from the main Style pane. In that case, if the checkbox was not checked, you'd know that style overrides are not on.

the new info pane, especially with records details works perfectly. Just a thought. Using massive tables, in terms of number of fields is eased by the layers pane enabling folding, sorting, etc the fields. I would find really usedful to have this table "layers" structure reproduced in the info values both in terms of order (why the values pane is not using the forced order of the layer pane?) and of grouping in folders. Just a wish.

For the rest I'm just impressed by the improvement of ease you bring to this product at each new build, Congrats.

That's an interesting idea! We'll consider it.

Just generalizing your own ideas. As long as you gave us a taste of excellence in sorting data tables we use it. Further on the same subject we might consider expanding this concept to the new "related" wonderful tool especially for me dealing with numerical categories and linking the dictionary table giving the definitions of the categories. It opens new ways to be more productive, excellent

a.

Just a question about the "lifetime" of the related parameters. My primary interest in that is the possiblity to add side informations about classes for example a bit like a value dictionnary, but I saw that this type of relation is not persistent when closing the project. A bit like if in M8 the viewbots were flushed at each closing. Any chance to made those to be more persistent? or may be I'm doing something wrong

Currently, dynamic relations are the property of a window. This has both good sides - eg, you can use relations with read-only components, can open multiple windows for the same component and use different relations in different windows, etc, and bad sides - the moment you close the window, the relation is gone and if you want to use it again, you have to re-select the source component / key fields. We might move to saving relations to component properties in the future, but this requires some thinking through because we want to still allow using relations with readonly components. Maybe we shouldn't be saving anything to component properties and should instead keep last used relation for a component in the current session (until the MAP file is closed).

Regarding value dictionaries - we are planning to add a different feature similar to lookup fields in 8 and that information would be saved in the component properties.

Thanks for the explanation with your bird view of the problem, always interesting to confront this to my scope view. Your plan for new lookup fields sounds interesting to me. I'm used to the statistical software linking a definition part to the numerical part of class like a category alias, and this plan might go to this direction

It would be great if a solution could be found to keep the relation active permanently (even after closing map file) and keep accessing read only data. With Mfd's low cost and capabilities, I think this feature will get used a ton by viewer type people who don't want to set the relation up every time they start up.

Could there not be some other internal table/script that gets added to the project and revives connections as needed. Seems like there is other areas that could benefit from this capability, such as the ability to style read only drawings and maybe even undo capability. My gut thinks the time overhead associated with these tools would be less than the time lost not having them.

The problem is that usually the entire data source is read-only, ie, it's a MAP file opened in read-only mode, because you don't want to alter it in any way at all and / or you want to open it simultaneously from multiple other data sources. Or it's a database which you don't have any write permissions on, only read. When the entire data source is read-only, there's no way to create any extra components, even internal ones.

For relations, we can perhaps do a compromise and still allow using them (which involves setting them up or making changes) without saving.

For things like styles though, the best that could be done is introducing some other data source which would be writable and save the changes there - eg, link the read-only data source into a writable MAP file. And if we have that writable data source, we can just copy / paste the drawing / image / labels component into it and edit the style of that component. (There is a way to override properties associated with a table, eg, the coordinate system, too, by the way: in the writable data source, create a query with TABLE <readonly>::<original-table>;, then link components off that table, this way you can set the coordinate system of the field in the query.)

We'll add undo in various places, yes, that's in the plans.

To add another opinion, I think Mike was onto it when he asked whether there could be some table/script added to the project to revive connections as needed.

What would this be like? Like a Location component, but procedural rather than geographic.

We could save the current set of relations for a table, maybe also the full config for a datasource, or many similar things for web resources (in the future), to a JSON string of links for the current component.

This could appear in the Project pane as a new Links compohent (very like Location).

These could be loaded to any compatible components in future, copied and pasted between projects, and so on.

(Not fully worked out. But many basically similsr things here.)

Hm.

We could also have means to show a graph of all related components, that would be a good thing to include into the documentation for the data set.

We could also make relations symmetric - if I open Orders and establish a link to Customers to see customer data for the picked order, when I open Customers I should be able to already see orders for the picked customer because the link is already there.

We'll think about it.

Some sort of visual representations of the linkages sounds great. That might allow away to quick way to understand a project's structure. To the extent that the solution can avoid creating additional components all the better or perhaps. just tuck them away into a nice location.

I'm finding that my projects are growing into long ugly lists of components that can take awhile to wrap your head around. Perhaps helpful would be a few more options under the project pane filter dropdown.

1. Items related to each table

2. Items related to each map.

Once sorted, perhaps add a tool to move related items to a new folder. Since many components can't or shouldn't be physically moved, perhaps folders could sometimes be virtual for purpose of seeing relations.

We have the Show Related command which shows components related to the clicked one. That's not the same as expanding nodes, agreed, but it might prove useful in some cases. We also show producing tables / queries for map layers in the Info pane, clicking component readouts in the Info pane takes you to the component in the Project pane.

We will likely add means to show related components directly in the Project pane in the future. We had good discussions about that on the forum before. The main issue is that anything that shows related components will necessarily have to show some components multiple times (if a table has multiple drawings referencing it, the organization that shows tables under drawings will show the same table under each such drawing, and that would happen fairly often because, eg, multiple drawings based on the same table are a common way to have different styles). With that the picture might easily become less organized instead of more.

For me too, the Project pane can be a big mess when you have more that a dozen components. Many times a drawing isn't shown next to the table containing it's Geom. Especially when you produce Drawings from other drawings using the Transform Pane, you sometimes end up with 10s of drawings and tables having similar names, shown in a confusing order. I usually put them in folders to tide up, but the way 8 had to show relationships was better.

I think that at least there could be nodes that expand to show 1-to-many relations between components in some cases. Each Drawing could be a child to the Table that saves it's Geom, and each Label could be a child to the Drawing that has it's position. In that way at least Drawings, Labels and Tables could be better organized.

Maps and Layouts, could be shown without nodes (parentless and childless), since they often participate in many-to-many relationships.

Hi Adam, while trying to importing a tif file to the latest build (manifold-9.0.172.2 x64) I came across an unexpected behaviour, when after selecting the tif file nothing happened. The log file states "2020-06-07 19:10:02 -- Import: D:\AEREHS\K_new_crop.tif (0.001 sec)" but the project pane is empty. I tried with previous builds (manifold-9.0.172.0/1-x64) and the import was successful and everything went as expected. Is this a possible bug in the latest build?

It might be. Could you post the offending file? Alternatively, contact tech support and send it to them.

Hi Adam, in this link you can find the the offending files: https://we.tl/t-ms1li2CAgB

(they refer to ESDAC Dataset for Rainfall Erosivity and Soil Erodibilityin the EU)

I agree -- tif import in cutting edge build 9.0.172.2 does not seem to be working. I tried it on a half dozen tif's from different sources without success. No success with viewer either.

ArcGIS, QGIS, and IrfanView all work without a hitch.

tif import in cutting edge build 9.0.172.2 does not seem to be working.

Not so. I just tried over 40 TIFFs from various sources, including some exotic TIFF variations like fax format TIFF, and they all imported perfectly.

For example, the Venice 1 meter ground surface TIFF (about 32.5 MB) and the full resolution Venice ground surface TIFF (about 132 MB) exported by ArcGIS Pro are here:

http://www.manifoldgis.com/files/Venice_1m.tiff

http://www.manifoldgis.com/files/Venice_Ground_Surface.tiff

Also importing OK are tiffs from the Indianapolis site that is listed in the notes to the sub-pixel reprojection topic.

Could you specify some URLs to TIFs that don't import?

By the way, PhotoShop doesn't import the TIFs in the https://we.tl/t-ms1li2CAgB link, throwing an error message "Could not open... because the TIFF file uses an unsupported bit depth."

In general, if a particular variety of TIFF or other format file does not import, the more details the better: 1) link to an example. 2) What is it supposed to be? (photographic image, etc.) 3) What type of TIFF is it? (bit depth, etc).

TIFF is a very broad format and it's easy to find TIFs that a given package won't import. If you want Manifold to add support for a particular type of TIFF, follow the tips in the Suggestions for New Formats section of the Suggestions page.

I've had no trouble either.

I don't think the TIFF images I rely on have any pyramid layers. I wondered if the issue might depend on that, or briefly even on whether the number of pyramid layers is even or odd.

A probably stupid thought that I am only throwing in the air.

Again, I have no problems with TIFFs with this latest build.

It does not open the North Island, NZ tiff images used in the thread "Reclassify image using GPU" -- I'm having trouble attaching even a small one such as TA.tif -- here's the thread with links to the data.

http://www.georeference.org/forum/t148873.33#148946

Here is a site and a link to a very large tiff that I have previously downloaded that will not open for me.

https://www.boem.gov/oil-gas-energy/mapping-and-data/map-gallery/boem-northern-gulf-mexico-deepwater-bathymetry-grid-3d

https://www.boem.gov/sites/default/files/Bathymetry/BOEM_Bathymetry_West_meters_tiff.zip

NB: It loads in 9.0.172.1 -- need to figure out the styling.

http://www.georeference.org/Forum/t146630.22 references the following tif that will not open.

cc_cogt_jpeg-ycbcr_mask.tif

NB: It works in 9.0.172.1 -- loads desired image.

We did make some changes to the TIFF dataport recently and there might be absolutely be issues related to those changes. We have some example files now that don't behave well, thanks for sending them in. We will fix the behavior in each case. In the meantime, if you have a file that doesn't show how it should, please send it in as well.