Subscribe to this thread
Home - Cutting Edge / All posts - Manifold System 9.0.167.3
adamw


8,216 post(s)
#06-Jun-18 17:58

9.0.167.3

This build contains UI features. The next build should contain a mix of analytical and UI features.

manifold-9.0.167.3-x64.zip

SHA256: ef6478bd222a3b6141e577cd3a0ae627346e0cfce102ba1df152de6348946e64

manifold-viewer-9.0.167.3-x64.zip

SHA256: 5e807693c2296106546bb5a123229efbbe3db462cdfa5f7777a123021945578a

adamw


8,216 post(s)
#06-Jun-18 18:00

Changes

Pressing Ctrl-] in a comments, query or script window moves the cursor to the matching bracket. Symmetric brackets like '' or "" are matched within the same line. Asymmetric brackets like <>, [], () or {} are matched across multiple lines.

Pressing Ctrl-Shift-] in a comments, query or script window moves the cursor to the matching bracket and selects both brackets and all characters between them.

Right-clicking a value of a selected record in a table window allows copying the cell value to all selected records via the new Copy to Selection command (shortcut: Ctrl-F2). Copying the value tracks progress and can be canceled. Total operation time is logged.

The table window disables Copy to Selection and Delete commands for values in a field that belongs to an index used by the window as a key. (If the index used as a key is built on a single field, which is the most common case, none of these commands can succeed anyway.)

(Fix) The Export and Save dialogs correctly detect overwrites in all cases where the filename is automatically extended with an extension. Attempting to save a MAP file as 'data' no longer fails to detect an overwrite if 'data.map' exists, and no longer misdetects a false overwrite if 'data' exists.

(Fix) The Export dialog detects an overwrite of a folder for GDB.

Attempting to overwrite an existing file in the Export or Save dialog displays a confirmation dialog with an option to confirm the overwrite and an option to save data to a file with a different name that is currently unused (the default).

The accept buttons in Export, Import, Link, Open, Save, Select Folder dialogs are named according to the performed action (were previously named either Open or Save).

Deleting records in a layout, map or table window displays a confirmation dialog. The default button in the confirmation dialog is set to Cancel.

Deleting components in the Project pane displays a confirmation dialog. The dialog lists the names of the first few components and the total number of remaining components, this is particularly useful when deleting folders which might have many components inside.

The Tools - Options dialog allows turning confirmations on and off. Confirmation dialogs include an option to turn the current confirmation off ('Never show this again').

The confirmation for exiting application uses the new confirmation dialog and can be turned off from that dialog.

The Location status bar pane is renamed to Position.

The map window reports current scale in the new Scale status bar pane. The scale is reported as an absolute value in either 1:xxx or xxx:1 format, with the number of decimals adjusted for readability. If the coordinate system used by the window is lat/lon, the scale is approximated using the latitude of the center of the data rect.

Right-clicking the Scale status bar pane allows setting the scale of the map window to a fixed or custom value.

There is a new component type: location. Locations are analogous to views in Manifold 8, but are way more flexible. A location is defined by its center in lat/lon, WGS84, and an absolute scale. A location can be stored on any data source that supports writes to MFD_META (eg, on any database).

The File - Create - Location command creates a new location. The New Location dialog allows entering the longitude and latitude of the center, and the scale. The dialog also lists all opened map windows and allows setting the location parameters to the current center and scale of a specific window. If the active window is a map window, the dialog selects it by default.

The map window lists all locations in the data source of the map in the View - Locations submenu. Selecting a location zooms the window to it. (If the coordinate system of the map window is such that the center of the location cannot be converted to it, selecting the location does nothing. This only happens with coordinate systems that hide hemispheres, like orthographic.)

The View - Locations submenu for a map window includes the Windows submenu which lists all other opened map windows. Selecting a window zooms to its current location.

The View - Locations submenu for a map window includes the Save Current Location command, which saves the current location into the data source of the map.

Opening a location by double-clicking it in the Project pane displays its definition as text (JSON) and allows editing it.

Locations can be copied and pasted.

Locations can be exported to MML or TXT.

Locations can be created, altered and dropped using a query.

The Project pane allows filtering the list of components to display just locations.

(Fix) The Edit - Save Layout, Edit - Save Map, Edit - Save Query commands save new components into the data source of the opened component, instead of into the MAP file.

End of list.

drtees30 post(s)
#07-Jun-18 16:38

From the sounds of it, Locations would address an issue with M8's Views that I have always had troubles with. Creating a view for use in a layout often required me to go back to the map, reposition the center point of the image, delete the previously-created view, and recreate it (I always name the view with the object of the view and the zoom level, i.e., "Wetland (1:1200)" for a 1" to 100' layout).

Dimitri

5,082 post(s)
#07-Jun-18 20:38

Yes, Locations are way more flexible than saved Views in 8. See the example of editing the text in the Example: Locations topic. I also love the ability to just copy/paste between projects. You can have an archival project with lots of your views in it, for example, that you could just copy and paste from for the ones you want.

That same text you see and can edit directly if you like is also the text property of the location component, which, of course, appears in the mfd_meta table along with all the other properties of other components. So you can manipulate it with SQL, do your own addins, etc. Suppose you want to redo all your locations so instead of having a scale of 1200 you want them to have a scale of 3000... no problem. Use the select and transform panels to change hundreds of them at once in the mfd_meta table.

Locations in 167.3 are just the first framework. Upcoming builds will add some more conveniences to working with these, like invoking them from the Project pane, etc., and leveraging them will be a continuing theme.

tjhb

8,348 post(s)
#08-Jun-18 03:46

I'm loving Locations, deceptively simple and almost too useful--one of those things that is taken for granted just as soon as it is invented. The new example is good too. And the icon.

Dimitri's comments are encouraging ("leverage" is exactly right).

One question that will have arisen I think is whether a Location component should contain only one location. "Atomic" locations can be enumerated unambiguously in the View > Locations menu, and the 1:1 mapping makes it easy to match them over in the Project pane (especially with filtering). Potential clutter can be managed by using folders.

On the other hand, having one location per component feels a bit... unwieldy is not the right word. And I just repeated that clutter can be managed with folders.

How would it be if a Location component could contain multiple locations, in nested JSON? (Then the location name would perhaps be an extra JSON property, rather than the component name.)

A Location component in the Project pane could then take a [+] icon, analogous to a folder. Expanding it could show a list of child locations by name, clicking any of which would take the active map/drawing window (if any) to the saved location and scale. Or we could open the component to see and edit the JSON.

I also imagine (eventually) some way to move from the result of a query (a table, containing at least a geom field, a scale field and a name) straight into a new set of locations, for follow-up visits and further analysis. Or perhaps that is something better handled by the Record pane. (Or both.)

I should shut up. It's obvious that a lot of thought has gone into this feature, or "continuing theme" as Dimitri puts it, and it will be fun to see where it goes. Already seriously useful.

dyalsjas96 post(s)
#08-Jun-18 16:23

To expand your questions; which is a more relevant path to follow for the Manifold Locations theme, discrete locations that support UI operations in a granular way (single location, labelled in a project, potentially stored / shared in nested project folders) or discrete location sets more analogous to having multiple geometries stored in a single table? Probably a synthesis of both.

The options that Locations can add to analysis functions will be especially interesting to me. Precisely repeatable shortcuts to analysis visualizations could really accelerate some workflows.

I really enjoy the Cutting Edge build, discuss, refine process.

tjhb

8,348 post(s)
#09-Jun-18 23:10

You put that very well, just what I was trying to get at, but much clearer.

dchall8
512 post(s)
#08-Jun-18 17:21

Locations would be a good topic for a video.

Dimitri

5,082 post(s)
#08-Jun-18 20:25

Agreed. That should happen next week after a few more interface tweaks get tossed in for locations.

KlausDE

6,232 post(s)
#10-Jun-18 11:18

I hope that it will soon be possible to apply locations to layout frames - perhaps per drag/drop.

KlausDE

6,232 post(s)
#10-Jun-18 10:11

German UI-file for 9.0.167.3

'Location' is translated into 'Standort'.

Open for other recommendations. Is there a counterpart in other GIS/CAD software?

Attachments:
ui.de.txt

Bernd Raab33 post(s)
#11-Jun-18 12:35

hallo Klaus,

may be "Ausschnitt" is better, because Location is part/section of a map-window, "Standort " means a single point at a specific location.

KlausDE

6,232 post(s)
#11-Jun-18 17:47

I was thinking of "Ausschnitt" (-> clipping, extract), too.

But you and me are paper oriented while 'location' in manifold is used in a wider context and actually still is missing for layout frames. A manifold location technically has a center and a scale, it's not a box! It's more like the 'You are here' mark on a street-map.

Well, I asked because I'm in doubt. I don't have a word with the meaning of position and scale (nor seems 'Location' to cover both aspects.) and I don't know what other application might use.

Bernd Raab33 post(s)
#11-Jun-18 18:51

so with the aspect of "you are here" (usually in the center of the map-window), the translation to "Standort" is acceptable.

by the way: your ui.de.txt is really good.

KlausDE

6,232 post(s)
#11-Jun-18 21:57

Suggestions always welcome. And there are some strings concerning projections important for satellite images that I can't translate. They are mark with a leading # and thus manifold chooses the default english string.

adamw


8,216 post(s)
#14-Jun-18 09:40

FWIW, we might add an option to make the location a box, this is useful sometimes.

Bernd Raab33 post(s)
#14-Jun-18 11:28

this would really be usefull,

KlausDE

6,232 post(s)
#14-Jun-18 11:52

Switch off location is especially useful to guess the correct keyword when searching in help. This problem made me add the original Merge, Union ... to the translated Transforms because this important differences are not obvious in every case.

Would this solve issues on export of XLS(x) and CSV where a German system expects a decimal comma and a separating semicolon. Now you'd have to change the systems localization or all fields of a table export concatenated in the the first row of the excel sheet.

BTW I love the consistent use of decimal point in tables and transforms in Mfd9. We still have the problem that windows dialogs use located formats with decimal comma. But in Mfd8 the table displays local formats while Transforms and Selections expect the English version. To forget this produces errors which aren't easy to fix.

adamw


8,216 post(s)
#14-Jun-18 13:03

If you mean adding an option in the UI to force a specific localization in order to test it / switch off temporarily, we were planning to add such a thing, yes. We didn't plan for it to affect the exports though, but that might make sense. Although whenever a particular export is sensitive to the localization, it is probably best to add an option to it to force a specific localization and set it to "auto" (take the current UI setting) by default.

walter
20 post(s)
#10-Jul-18 14:09

Hello Klaus,

other systems call it "Bookmark" or "Lesezeichen"

KlausDE

6,232 post(s)
#10-Jul-18 23:46

Yes, but that not really it, isn't it? We store a location (the center) and a scale. Manifold could have chosen 'bookmark'. But they haven't - probably for the same reason.

I was looking at google maps. They allow to store exactly what manifold calls 'location'. But I can't find a name that people might be used to. Google maps allow to store these locations in a list of 'Markierte Orte', bing has 'Meine Orte'. So 'Ort' might be another option but I still prefer 'Standort'.

What I'm missing is the aspect of scale.

tjhb

8,348 post(s)
#10-Jul-18 23:56

Are you not over-thinking it?

"Location" has no sense of scale either.

The name of the feature does not need to prescribe its use, just refer to it clearly.

People will learn to use it--perhaps no two users in exactly the same way.

For the word, in English, I would be equally at home with "location", "place", "placemark", "marker", or "bookmark", without thinking of "cairn" or (Dimitri?) "menhir".

In French I expect "repère" is clearly the best choice?

A dog would just pee.

Dimitri

5,082 post(s)
#11-Jul-18 05:56

"I was looking at google maps."

A useful place to begin. The reality is that these days Google drives much of language and culture. May as well leverage that. Google tends to use two words: "place" and "location."

Google's use of "place" tends to mean a named location like a town or other named geographic feature. For example, if you right click on a Google Maps display in your browser the context menu offers "Add a missing place" as an option. There is also a sense of named locations, named in the sense of a town name or forest name, in Google's use of phrases such as "Places I've been..."

For Google, "place" means more than just an X,Y location somewhere. When they just mean an X,Y location somewhere they use "location." The notion of "location" as being an X,Y position, without any embellishment as to something named being there or not, is also fairly widespread in computing / GIS terminology.

I think that is a useful distinction: place is a named feature, while location is just a particular X,Y spot. Manifold uses "location" and not "bookmark" or "spot" because a) Google leans towards "location", and b) it does not come with the other meanings or associations some other words have.

"Bookmark," for example, has an association with text. "Marker" would be a useful term for an annotation, but it has a sense of an arrow pointing at a location more so than the location itself. "Spot" has an alternative meaning in graphics, as in a blot or dot figure. "Pushpin" seems too much forcing of a physical metaphor - it means a tangible object, and a dated one at that. Young people don't know what that is ("maps on paper? wow! How does your telephone use them?").

In English, "location" seems to be wearing well. It fits very well with accessory functionality, like upcoming use of location services to automatically generate your current location (moving map and all that...) and so on. "What's my location? Cool. Let's save it." Having used it a lot I like it better and better over time, always a good sign.

I tend to agree with Tim. Scale is a useful part of Location components but it is not something to over-think. [Should there be a hyphen in over-think? Maybe not... Maybe yes...]

As time goes on and JSON in Locations acquires more dimensions, such as bearing, altitude and so on, you could make an argument that a term such as "view" would have been better. That, too, was considered, especially given that 8 uses it, but the term "view" has too many connotations in DBMS to be as neutral as location. By the time such additional dimensions appear in Locations we'll all be so familiar with the word we won't want it to change.

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