Subscribe to this thread
Home - General / All posts - 10 quick useful additions to Radian Studio

3,048 post(s)
#04-Feb-17 18:42

Some of these ideas may be scattered throughout the forum, either in the main section or the beta section. But, these are things that I believe are not simply "nice to have", but really critical because without them, it places a large target on the back of RS for valid criticism. Now, the heading says 10 quick useful things. I've included 5, and thought people could think of others. I think it is important to make sure they are 'can't live without, vs. nice to have':

1. Info tool - click on an object, see the attributes of that object. This is a natural next-step for data exploration. One of the first questions someone is going to ask looking at a parcel is "who owns that place", or 'what is the name of that river', etc.

2. Show only selected features (Selection Filter in 8) - if we have lots of data in a table, the likelihood of seeing the selected features are unlikely. If I select a few records in a 100,000 record dataset, I would like to open the table and see only the selected records.

3. Modify an existing object (ctrl-alt click in 8) - Radian lets you add a geometry object, but after you do it, you can't modify the vertices if you want to improve the accuracy.

4. Refresh drawings (Alt-F5 in 8) - linked drawings should be able to be refreshed based on changes in the underlying database

5. Right-click geometry column to set coordinate system - or, at least let the Table-Properties interface allow drop-down menus to know what valid properties are available (i.e. FieldCoordsystem) and allow the values for those properties to be selected (copying and pasting "{ "Base": "North American 1983 (mean for CONUS)", "CenterLat": 40, "CenterLon": -76.58333333333333, "Eccentricity": 0.08181919104281579, "FalseEasting": 250000, "LocalScaleX": 0.3048006096, "LocalScaleY": 0.3048006096, "MajorAxis": 6378137, "Name": "State Plane - New York Central\n(NAD 83, feet)", "ScaleX": 0.9999375, "ScaleY": 0.9999375, "System": "Transverse Mercator", "Unit": "US Survey Foot" }" is a pain -would be great to get the coordinate system dialogue to pop up.







4,843 post(s)
#04-Feb-17 19:13

Just my two cents... I think 3 is a GIS thing, not a Radian thing. Love 2 and 5, neutral on 1, think 4 depends a lot on the underlying DBMS.

I've been pushing for sorts on columns like in 8: click on a header to sort by that column. I'd love to see the ability to right click on a column head and change type too, but I get it that is not the way big-time DBMS people want to see schemas modified. :-)

8,009 post(s)
#04-Feb-17 21:52

6. Lack of smoothing when showing shaded elevation images at greater than native resolution, and also when reprojecting images. (Discussed here, here.)

That, and Art's point 1 (an Info tool), are the only two things that fall into the 'target on the back... can't live without it' category for me.

Reducing the threshold slightly, things that are not critical, but obvious gaps (not only for GIS, but for data management as well):

7. View > Go to... location.

8. In the proposed Info tool, Go to the current object, much as in 8.

Regarding 5, I agree about the inconvenience ('copying and pasting [a JSON string] is a pain'), and also agree that allowing right-click on (any) Geom (or Tile) column would be a good way to get at the Coordinate System dialog (with Favorites). That would be intuitive and unambiguous, in all cases.

I think the alternative

let the Table-Properties interface allow drop-down menus to know what valid properties are available

would not be so good, for two reasons. First since properties are just named strings, and can be replaced ad hoc. Adding a special interface to specific properties would be problematic, because we can (if we like) change the name of a property (e.g. 'FieldCoordSystem.Tile' -> 'FieldCoordSystem.Tile.old'), then write a replacement property ('FieldCoordSystem.Tile'), whenever we like, either by the GUI or in SQL. For a special interface (a drop-down list, or buttons to access the Coordinate System dialog) to follow the property name, while not impossible, does not seem very simple.

Secondly, in the case of a drop-down list of available coordinate systems, there are many thousands of them--even if the list were limited only to JSON strings (which would in any case be unreadable).

A further alternative (as well as a right-click on Geom or Tile field), possibly better, might be to add a new table property, named something like 'FieldCoordSystem.Type', whose valid values could be







The default could be 'JSON'--currently the usual Radian format, though XML is used for some Manifold 8 conversions. If we instead set 'FieldCoordSystem.Type' to 'EPSG', for example, then we could enter a simple value like


for 'FieldCoordSystem.Tile'. Much easier than dealing with JSON here.

Regarding 2, there is some discussion, started by Mike Pelletier, here (point 4; see also near the end of the thread). It could be a built-in query, mapped to a (coloured) table interface. The query would only need to fetch enough records to fill the screen (plus a bit), then more if we scrolled down (or moved to the bottom).

The streaming interface doesn't look like a problem for filtering on selection.

On the other hand, how well can Dimitri's suggestion

sorts on columns like in 8: click on a header to sort by that column

work for Radian? Wouldn't that require a full fetch, all records (however many millions or billions)? If so, aren't we better left just to write our own query for that, and to take the consequences.

In other words I think the streaming interface might be a barrier for sorting in the GUI.

Maybe a Transform template, to Sort by field (producing a new table), would work as a compromise?


532 post(s)
#04-Feb-17 23:36


your links are to the beta forum, thus not readable by non beta participants.

8,009 post(s)
#05-Feb-17 00:11

Yes. Art probably wondered whether to post this thread to the beta forum or in public. In public the back-references are useless.


7,903 post(s)
#05-Feb-17 10:02

Regarding FieldCoordSystem.Type (would have to be FieldCoordSystemType.<fieldname>, but that's not important) which then tells what FieldCoordSystem.<fieldname> contains - we had that before for a long time, that was our initial design. We didn't like it because then the coordinate system is defined by two strings, not one. Having it be just one string with all the info contained is very useful. We are absolutely going to add means to set the coordinate system of a field via a dialog or something similar, so you won't have to copy / paste property values by hand anywhere. You can specify EPSG 4326 simply via 'EPSG:4326'.

Regarding sorting (of table records) being at odds with streaming - yes, they are at odds with each other, sorting requires fetching all records (at least when the table does not have an index on the sorting field / fields), but if the table is small, nobody cares if we fetch it all, and if the table is large and takes a long time to fetch, we just have to make sure the process can be cleanly canceled. Obviously, there is some threshold after which the table becomes big enough to require preparation for various operations - including sorting - that's fine.

Agree with everything else.


7,903 post(s)
#05-Feb-17 11:11

To expand a bit on being able to set the coordinate system to 'EPSG:xxx' with an arbitrary EPSG code, we recognize coordinate systems defined in the following ways:

  • JSON - { ... } - that's our native format, lists of keywords / values can currently be mined via the query functions, we will publish a doc as well,
  • XML - < ... > - that's the format used by Manifold 8 and earlier, documented in the online help for Manifold 8,
  • WKT / PRJ - [ ... ] - used by many GIS products and many databases, you can just put the contents of a PRJ file into the desired coordinate system property and it should work without modifications,
  • EPSG:xxx - EPSG code,
  • SRID:xxx - database-specific code for a coordinate system stored on a database, we also expose coordinate system definitions in database-neutral way via MFD_SRID / MFD_SRID_xxx tables,
  • urn:ogc:def:crs:xxx - modern OGC reference, it's defined in an open-ended way, but usually contains EPSG data (which we recognize) or one of the older OGC notations (which we recognize as well),
  • AUTO:xxx / AUTO2:xxx / CRS:xxx - older OGC notations, normally used with WMS / WFS data,

We also recognize various codes appearing in OSGEO:xxx / OpenLayers:xxx / similar notations for tiled web data.

For the moment, we don't want to use the IDs that coordinate systems have in our classification (MANIFOLD:xxx). There are too many codes already so until we absolutely need to pass them specifically (ie, because coordinate system info *has* to be encoded as an integer value for some scenario and that value *has* to be our internal code), we will use other definitions.


3,048 post(s)
#05-Feb-17 14:22

A couple of things:

Coordinate Systems

just wanted to follow-up, after having spent a lot of time making drawings in all different kinds of ways in preparation for the training video I'm putting together.

As you indicate in the Help file, EPSG is the gold standard, and people should get to know it. In fact, I probably use the EPSG version of a coordinate system 90% of the time. Over the years I have memorized the top 5 or 6 EPSG codes that I use. I think others will be able to do the same. So, that is an easy thing for a user to type in.

Also, having typed in FieldCoordSystem.<fieldname> more times than I care to mention this weekend, I would say:

  1. it gets tiresome typing it in
  2. it really isn't that bad - muscle memory begins to take over

So, while having a drop down to facilitate it would be nice, it isn't really too much of a chore to just type it in. It would mostly help new people to have a drop down. Also, 'EPSG:4326' is easy to type. For those other times, I suppose a right-click on the geometry field should yield a sub-menu of things with Add FieldCoordSystem being one of them.

Info Tool

Again, after spending hours on the videos, I have such a knee jerk reaction to wanting to double click on an object to find out what it is. I don't think this is a GIS thing, but rather a data exploration thing.

Modify an existing object

Dimitri may have a point here - let the GIS guys do sophisticated data entry, and let the RS people do data exploration. I just wonder if it is better to remove the feature altogether, as being able to add a garbage sketch of an object without the ability to improve it is too much of a temptation, and would result in disappointment. I would like to hear other people's thoughts on it.

Thanks for keeping an eye on this thread. I think we have 2 or 3 no-brainers to implement.


7,903 post(s)
#05-Feb-17 15:12

One last thing regarding coordinate systems (everything else is completely clear) - why type anything at all? Why not open the drawing / image and use Edit - Initial Projection to specify the coordinate system you want? The command does what Edit - Assign Projection was doing in 8, we just altered the name a bit (to prevent a common mistake and emphasize that normally you specify the projection using that command and then leave it alone, and when you want to change it, you should use Edit - Change Projection). Is it that you don't have the drawing (why not) or that you didn't notice the command (understandable, it came pretty late) or what?

I am not saying we won't be adding other ways to specify projection, just want to better understand reasons for specifying it using Properties. (Maybe now that we have the command, we should alter some examples in help?)


3,048 post(s)
#05-Feb-17 17:32

Yes, I was aware of the Initial Projection, and I love that feature - I especially love the skull and crossbones in the help manual! Finally, someone has given that kind of feature its due warning :-)

Initial Projection Uses

I was thinking more in line with a spatially enabled table, where a series of coordinates are inserted into a geometry field, with someone having no desire to make a map - just a table with some geometry that they want to do some spatial analysis with.

At the moment, what I would do in that case is also a hack, but I'd probably create a drawing from the table, then set the Initial Projection, and then delete the drawing - what is left is a table with the appropriate coordinate system property for the geometry field. So, in this case, a workable solution is there, moving this request into "nice to have" vs. "can't live without". But, if we could right-click the geometry field and access the Coordinate System information that would save a step.

Spatial Index

One another note, right-click a geometry field and add a spatial index would be convenient, but the schema interface is really nice, so that is a "nice to have" feature, and not a "can't live without".


6,170 post(s)
#05-Feb-17 17:54

I couldn't get friends the funktions to add object geometries, too. Mostly because I can't remember the keys to invoke the 'Edit new Object' dialog on a german keyboard (<cntrl><#>). And if I try to handle the promissing features I always fail to control the direction that curved segments bend let alone spline controlpoints.

Perhaps there could be a way to include hotkeys in localization files so that they can be configured corrospondig to the online user manual, the only place where this well hideen dialog is introduced AFAKI.

However I think its usefull to have rudimentary ways to add objects with all the geometric properties like curved segements that RS supports for test purposes and not only during program development. Editing seems much less important to me for RS.


7,903 post(s)
#06-Feb-17 06:48

Regarding accessing the New Object dialog when adding new objects (which is not easily discoverable, one currently has to press a shortcut key combination as you say), we are thinking of either adding a visual prompt or a menu command to show it.

What does not work well when editing curved segments?


6,170 post(s)
#06-Feb-17 07:27

For Mfd 9 we definitely need the Edit Existing Objects dialog and that is the only way to control splines. For new objects they always will appear in some Picasso-mode. Thus no expectiation for new spline objects.

But generally we'd need a way to move the additional points that control curved segements before the new object is finished. For me AutoCAD is state of the art in this respect with lots of possibilities to define curved segmens: 3 points, center and radius, by default start in direction of the previous segment, ....

This is clearly heading towards Mfd9 and we would have to expand the Mfd8 Coordinates dialog (<CTRL><INS> during editing) to cover the curved segements. I currently don't see how the present RS dialog can offer such a variety of editing functions. Yet it's a key feature for everyday work.


4,843 post(s)
#06-Feb-17 08:40

For me AutoCAD is state of the art in this respect with lots of possibilities to define curved segmens

I agree, but that goes to how curved segments are more of a CAD thing than a GIS thing. With CAD, for example, there is one and only one coordinate system ever used or that even exists in concept. And even with that vast simplification dealing with NURBS and such is a very big challenge, especially for 3D systems.

I'm not saying it cannot be done, because it can be done, but more saying that the question is at what cost, with the implied question if that huge cost is worth what you get in exchange for the opportunity cost of many other things left undone.

With GIS in a fully-implemented system there is no option to forget about the possibility of re-projection. To allow generalized use of splines you have to be able to take the specification of some curvilinear thing using a limited number of points and then transform that into an abstract object in the new coordinate system space from which you can reverse-calculate what would be used to specify it in that new space, so then you can put handles on those inflection points for editing. At all times the visualization of an object that is computed at every level of detail is a real challenge, as is every aspect of spatial relationships involving other objects.

Think about it: it is easy to tie oneself into knots considering what exactly the shape of some curvilinear equation should be in a different coordinate system and whether or not it intersects with other curvilinear things might well depend on the coordinate system chosen, not that such things are simple computations in any coordinate system. It is orders of magnitude (literally... not ten times but hundreds of times) more demanding than what routinely is done with classic non-curvilinear objects. On the one hand I suppose such massive computations are exactly why Fate handed us GPUs, but on the other hand we are talking about a lot of very difficult code.

It can be done, but to be done well for GIS you are probably talking about a level of work that probably is equal to and which might be greater than the man hours required for all the existing rendering systems in Radian (for raster and vector) plus what would be done for good 3D rendering, all put together. Even the far simpler case that AutoCAD and other CAD systems apply, that of one and only one coordinate system, is a really huge amount of work. You can see that in action if you work with a well-established NURBS system (Delftship comes to mind...) that for all of its high quality and capability still has surprisingly many holes in how one works with splines.

For that reason, I'd probably recommend a focus for 9 editing as a first priority of matching and slightly exceeding the editing capabilities of ESRI's latest ArcGIS Pro (a very well implemented and appealing system overall, despite weakness on the data side of things) together with a roster of basic, classic CAD editing tools from the simplified forms of AutoCAD. Only after that is well and truly done would I suggest considering a fully NURBSesque system.

By the way, since we agree AutoCAD is great in CAD, are there any GIS systems you might recommend that do a really good, the whole life cycle, job with splines and other curvilinear segments?


6,170 post(s)
#06-Feb-17 11:07

... I'd probably recommend a focus for 9 editing as a first priority of matching and slightly exceeding the editing capabilities of ESRI's latest ArcGIS Pro

I totally agree. For me splines are dispensable and I wouldn't use Mfd to construct a highway with clotoides. The only aspect relevant for RS is that I have no idea how to select from the set of possible curved segments with no way to address the additional coordinates that are displayed during edits. I thus end with the feeling that I haven`t created the form I intended. It's just puzzeling.


4,843 post(s)
#06-Feb-17 08:18

the only place where this well hideen dialog is introduced AFAKI.

Which dialog? If it is important but hidden it should be bumped up.


6,170 post(s)
#06-Feb-17 11:12

I'm speaking of the dialog that allows to insert curved segments for a new object. Hotkey <cntrl><?> on your keyboard layout, <cntrl><#> on mine.

And no, it's not very important as RS is not my tool for editing grafics. Just puzzling.


4,843 post(s)
#06-Feb-17 13:08

Still, if it is hard to find that should be easier. We'll add some context hints such as maybe a prompt on the status bar, etc. Nothing to clutter up the interface but just to make it a bit easier.

128 post(s)
#05-Feb-17 22:26

I total agree with the info tool....... vote 1 for this; Also vote for number 2.

This is total a nice to have (but it is about work flow efficiency).... Given that there is an emphasis on code in radian studio. It would be good to have the ability to divide up windows with a little more flexibility. Below is a screen shot of how I might use pycharm....

Also given one of the benefits of radian is ability to see the spatial data and produce sql with the transform.... it would be really neat to see the code in a window next to the spatial element.... Or for that matter 3 windows next to each other -- spatial element, table and code.... See screen grab two – but there are lots of configurations depending on the work….

My point being is that it super useful to be able to move windows around.


1,863 post(s)
#05-Feb-17 23:29

Another vote for the Info Tool. Also a summary of the items in any field. Often a new drawing with many components is opened and you would want to know what items are in a field and if what you are looking for is there.

Aussie Nature Shots


7,903 post(s)
#06-Feb-17 06:54

By a summary of the items in a field, do you mean somehow showing first 5 or so different field values, or, say, min / max / mean? That looks like a table window tool, right (right-click a field, select 'Statistics...', get a dialog with the readouts)? Or are you asking for something like 'I know I have city names in some field, let's find out which field has a value of Melbourne'? Then that's more like Edit - Find.


1,863 post(s)
#06-Feb-17 07:28

Something like in the Style dialogue or M8 thematic formatting using unique values. Supposing I have a vegetation map with ~1 million polygons I could get a table listing the names of vegetation communities and how many polygons of each. Ideally a table summarising the content of all fields other than intrinsic.

Edit: actually just selected fields since there could be some with unique values.

Aussie Nature Shots


7,903 post(s)
#06-Feb-17 07:47

Understood. I will insert a couple of items into the wishlist.

(This looks like 'data mining' - before that became a generic term. Trying to make sense of a big pile of data, creating data axes, splitting the whole data set into parts with those, computing some statistics over subsets, etc.)


1,863 post(s)
#06-Feb-17 10:53

Thanks Adam

Aussie Nature Shots

8,009 post(s)
#06-Feb-17 02:35


Quick check. It's easy to miss things in the large new manual.

See this bit in the section under the third image.

Undock any window or pane by Alt-clicking its tab. We can dock an undocked window or pane by Alt-clicking its title bar.

Essentially, window placement and arrangement are up to you. (Except that panes are always on the right, and you can't currently save a window layout, but you can't have everything. Yet.)

128 post(s)
#06-Feb-17 03:42

Thanks for the clarification. I obviously missed this.... :).

It is nice that you can move the windows out of the map area onto another screen.


4,843 post(s)
#06-Feb-17 08:14

[same comment / threads crossed]

8,009 post(s)
#04-Feb-17 22:14

By the way I think it was an excellent idea to open this thread. No reason to stop at 10! :)


7,903 post(s)
#05-Feb-17 09:38

Great thread, just wanted to say that we are monitoring it and will absolutely add some of the proposed things.

Mike Pelletier

1,492 post(s)
#06-Feb-17 16:23

It would be great if RS became the go to database tool for small data, as well as big. Without some of the tools we are used to in mfd 8, RS will take a slower adoption path for people not working on huge datasets. Here are my thoughts, some of which go beyond mfd 8's tools:

1. Info or hover over tool for drawing objects as discussed by others.

2. As in mfd 8 a selection filter, sort, and display # of records for data where this can be done. If this isn’t possible, perhaps a dropdown list of these in query form for a user to initiate.

3. Some undo option beyond manually saving as a new project every so often. You don't want a small screw up to waste work since the last save. Obviously this would not exist with some complex datasets.

4. Going beyond mfd 8, add a one or two click bookmark option for table rows and drawing objects. Saved selections can do this and way more but take more time. Plus sometimes it’s nice to bookmark while you have a selection in process and you need to go back to a single record. Maybe Cntrl B or right click on the row or object to bookmark. Then to return to the Bookmark you retrieve the list of bookmarks and click on the one you want to zoom to.

5. When searching a table and narrowing down the selection with selections for the current selection, it would be nice if there was a handy dialog that tracks each selection request and allows making modifications to it and rerunning it. As we learn the data in the table we get smarter about how to query it, but it would be nice not to have to start from scratch. Perhaps the selection steps are recorded in a History pane that allows rerunning the desired steps. We can save the selection but it would be nice if it automatically saved the steps to get there.

6. Could we get a "search all columns" option in the Find dialog for tables. Perhaps add it at the bottom of the list of fields.

7. Add line numbering and text wrapping in query dialogues to make them easier to read, with the idea that eventually it would be something like how Notepad++ does it.

8. Don’t be shy about adding some color to the GUI. Tastefully done it will help our mental state during the huge number of hours we will be looking at it.

454 post(s)
#06-Feb-17 17:50

#9. Building expressions by clicking on field names and functions

I'll post a separate thread with an example. I've been trying out RS9 the past couple of evenings and this morning. One routine task I do in Manifold 8 is to add a field and calculate hectares to use in labels and exported tables.

In RS9 I can generate a field showing hectares in two steps using two fields but should be able to do it in one step in one new field. So for the 2 step process I use the Transform function and first add Area as a field, that gives me sq metres which I label Sq m. Then I add another column in which I take Sq m and divided by 10,000 to get hectares. So that is two steps and two fields. If I try to use the Expression tab, there is no longer a field for Area that I can see. There is [Geom] but when I try to divide by 10,000, I get the error message "/: Type mismatch". I suspect there is more to [Geom] as I have seen something that looks like a subset as in Geom.Area.

In RS9 and later in M9 my wish list is to be able to click my way through a menu and build up an expression in a matter of minutes. The templates with operators in Expressions look promising but they don't actually build up a working expression for me. I've tried substituting field names but no avail. See separate thread with the title "Radian Studio 9. Example map, trying to calculate Hectares in one step, in one field" (I will have to try posting the example map later as I got an error message from the forum site when posting the .map file and lost all the explanatory text I had typed. I need to get back to work now). However I'll post the screen shot here when I try to build an expression.

So a request for RS9 and M9, let the non-programmer user build expressions by clicking through menus and selecting fields.

Show hectares in one step in one field.JPG

8,009 post(s)
#06-Feb-17 21:01


That is already built in, in a much more flexible and powerful way than in 8: computed fields.

This is a new concept in Radian, combining the features we know ifrom Manifold 8 as intrinsic columns (e.g. Area (I)) and active columns.

There's an excellent example in the manual of how to add a computed field using the New Field dialog from a table window. It also explains a lot of concepts and controls.

There are at least two other ways to do it. The second is to use the Table > Schema dialog, the third (of course) to use straight SQL (ALTER TABLE).

Here's how the Table > Schema approach works for your example.

Open the table, and press Ctrl-E (or use the menu) to open the Schema dialog.

In the upper pane, select <new field>.

In the Field box, type a name, e.g. 'hectares'.

Adjust Type for the result value, e.g. float64 (corresponding to Floating-point (double) in Manifold 8).

Now make it a computed field. This is done just by supplying an Expression. If you leave the Expression box blank, the new field will be an ordinary field. If you fill it with a valid SQL expression, its value will be computed on the fly for every record in the table. And dynamically recomputed.

The expression here, to get hectares, is just

GeomArea([Geom], 0) / 10000

Now click Add, then OK.

If OK gives you the message 'Can't parse query', your SQL has a syntax error. Just select the new field name, edit the Expression, press Update then OK. (You can do the same any time to change the basis for the calculation.)

Now this field will behave like Area (I) in Manifold 8, except expressed in hectares. Values will be added for new objects, and updated for any areas that are changed. (It will give NULL for line or point objects, rather than 0 as in 8. You can Coalesce the result if you prefer zero.)

You can do anything you like here. Length (I) (in metres, feet, miles...) is another simple example, but we can also do quite complex things--whatever SQL syntax can give you, using any combination of fields from the current table, plus literals.

8,009 post(s)
#06-Feb-17 21:46


It's really worthwhile going through the example in the manual (link given above), getting familiar with the New Field dialog. Here, you can choose to populate the new field with values computed either dynamically (Add Computed Field, the same as adding an expression using Edit > Schema) or statically, just once (Add Field, the default).

In the Expression tab for the New Field dialog, there's also the huge advantage of a syntax builder, with a list of operators and functions, controlled by a search filter; and also live preview of resulting values in the new column, shown in blue.

Plus, you have the Edit Query button, which shows you exactly how to add a new field using the chosen options, using raw SQL. Learning from the machine itself.

454 post(s)
#06-Feb-17 22:27

Thanks Tim. , I did go through the example in the link. The example used fields that part of the user's database "Unit Price" times a markup. Where I had fields specific to my data, e.g., site index, then I could do transformations. What I couldn't find was how to write out (or better yet click-to-select) the syntax for using the Geom function or feature. Clicking on the menu options to add a computed field for hectares, I could get as far as generating this syntax:

GeomArea(<geom>, <tolerance>)/10000

I couldn't find info on what to put in place of <geom> and <tolerance>.The help Index for now returns a list of page numbers ranging from 1..55, I randomly read some of those pages but didn't hit on anything I could use.

Manifold team, I'm not getting the expression builder. I should be able to build my expression by clicking on context sensitive menu options without lifting my finger off the mouse. The expression for Area should drop into place without having to type in [Geom] in place of <geom>. If <geom> gets dropped into the expression builder, can [Geom] also get dropped into the expression builder without typing it in manually?

8,009 post(s)
#06-Feb-17 23:00

The expression for Area should drop into place without having to type in [Geom] in place of <geom>. If <geom> gets dropped into the expression builder, can [Geom] also get dropped into the expression builder without typing it in manually?

No, it can't. First because you might have more than one geometry field (many, if you like), secondly because you can call a geometry field anything you like. 'Geom' is the default name for tables made inside Radian; 'Geom (I)' will come through for projects migrated from Manifold 8; ...; and you can rename them at will.

(OK yes, if there is only one geometry field, then the builder could detect that and look up its name. But would this be best, or would it make other cases more confusing?)

What should be thrown in for <tolerance>? Always a default value of 0? (That would have consequences.)

There might be a danger of doing too much automatically, so that the operator does not have to think.

And there are many other fields and parameters which can not meaningfully be guessed.

I should be able to build my expression by clicking on context sensitive menu options without lifting my finger off the mouse.

You don't need to lift your finger off the mouse! Double-click the specification for GeomArea, select '<geom>' in the SQL text*, then double-click the '[Geom]: geom' field underneath to substitute its name.

*It would be nice if a simple double-click somewhere on '<geom>' for example would select just that text, without leading or following parens or comma. Rather than having to do an accurate drag-selection.

454 post(s)
#07-Feb-17 00:10

Got it, didn't lift a finger and now have Hectares in one step. For others, the attached image shows the step sequence in the Transform dialog box. Remember the 7th step to Update Field. While the preview shows results in the field, you still need to update field to keep the results.

Then I applied a second Transformation to Round to Decimals to get my 2 decimal places. Excellent. Thanks Tim, looking forward to your book.

I feel like I'm visiting a space centre but I'm only in the visitor's centre right now, working through the learning curve and new paradigms so I can move into the real control room to make some stuff happen with RS9 and M9.

No-lift fingers.JPG

8,009 post(s)
#07-Feb-17 00:37

Great, and by the way this is perfect:

I feel like I'm visiting a space centre but I'm only in the visitor's centre right now, working through the learning curve and new paradigms so I can move into the real control room to make some stuff happen with RS9 and M9.

Remember how hard it was to learn SQL the first time though? This is a new language, and it's hard. But it's not as hard as the first time!

In your excellent diagram, you can omit step 1.

I mention this in case you are missing something that I also initially found unintuitive, a new type of control used in several places in Radian Studio, the drop-down button.

In summary, you don't need to create the new field and then change (update) it. You can create the field you want in one step. It's only a tiny change but I'll spell it out.

You have your table open. Now launch New Field..., then:

  • Type a name in Target, e.g. 'Hectares'.
  • Change Type to e.g. float64.
  • Enable 'Set field values'. This visibly changes the dialog, but also (more subtly) the drop-down list on the 'Add Field' button (lower left). Now you also have 'Add computed field'.
  • Press the triangle on that drop-down, select 'Add computed field'. The button now changes its label and effect.
  • Activate the Expression tab, and do what you did before to build the expression.
  • Now press the 'Add computed field' button.

(This is the same as what I did above using Edit > Schema, except for the help and visual experience.)

8,009 post(s)
#06-Feb-17 23:04

GeomArea(<geom>, <tolerance>)/10000

I couldn't find info on what to put in place of <geom> and <tolerance>.

You are right that there is as yet no detailed function-by-function help, explaining parameters and giving examples.

BTW I am working on this, among other things, for a book. No date yet.

454 post(s)
#06-Feb-17 22:41

#10. Deleting records and fields by clicking 1st record/field and shift-click last record/field to select all in between

In RS9, I wanted to post an example project by reducing the file size. One of my wish list item in Manifold 8 was the ability to delete fields or records by clicking on the first to delete and shift-click on the last to select all records or fields between the two end points. The behaviour in RS9 seems to be the same as in Manifold 8, when in a table view, can only delete one field or one record at a time. For records I can write an expression to select records to delete, that's OK. What I'm unable to do is sort by a field and delete a collection of records by clicking on the first record then shift-click on the last record to select all the records in between. Still on my wish list!


7,903 post(s)
#07-Feb-17 08:04

We will try to add Shift-click to select a range - there are complications with big tables (by the time the Shift-click arrives we might no longer have the first record in cache).

You can select multiple records visible on the screen by Ctrl-dragging the cursor over the table - that works similarly to drawings, you get a selection box, Ctrl-drag selects, Alt-Ctrl-drag unselects.


4,843 post(s)
#07-Feb-17 08:24

One of my wish list item in Manifold 8 was the ability to delete fields or records by clicking on the first to delete and shift-click on the last to select all records or fields between the two end points.

? You can do that in 8. No need for a wishlist item as it is in there already. Select a swath of records and then choose Edit-Delete.


4,843 post(s)
#07-Feb-17 08:41

What I'm unable to do is sort by a field and delete a collection of records by clicking on the first record then shift-click on the last record to select all the records in between. Still on my wish list!

Not sure if you mean by "Still on my wish list" that you are referring to 8 or to Radian. But, if you meant 8 you can do that in 8 today.

If you meant Radian, you can also do it in Radian even for very large tables in many ways, perhaps most easily using the Select dialog if you want a closer analog to how 8 does it.

If you want to select on the basis of ordered values you can then use the Select dialog with the Between template right away if the ordered value is a numeric value. It's instantaneous. So if in a field of wells you want to select by depth you can select all between -2000 and -1000. No need to even sort the table.

It's tricker to use Between on text, so I'd recommend that if ordering by a text field is important to you that you first create a table that is ordered using Select Into Order By using whatever ordering you want, including multi-level ordering. If you are working with such small tables that you'd consider click to select and then shift-click to select you're probably not talking about huge data so that too would be instantaneous. Add a field that's populated by an arithmetic series and then use Between on that to select whatever you want within the ordering you used.

Using the Between template on a numeric field is a one-step process while using Between on text is multistep if you follow my recommendation. But, it generalizes to far larger tables and more general ordering than simply sorting on one column as in 8. Using the Select dialog also has the advantage that it is less error prone.

As adamw notes it's likely that in addition to sorted columns Radian will get shift-click to specify a range. Why not make it easy for small tables, right? But don't let that lead you into missing a very powerful and more general tool that extends your reach into far larger tables in potentially a less error prone way.

gjsa10 post(s)
#13-Sep-17 03:38

Not sure what the status of the info tool request may be 6 months on?

Anyway, to give some context for why improvement in the ctrl-alt click info tool is a must:

I have just added 459 drawings into a map, and each drawing has a label tab, so over 900 tabs at the bottom of the map. Is it still not possible to get info on any feature in the map unless I identify and select the drawing tab it belongs to ?!

I'm using manifold viewer and if this feature is added I'll buy Radian Studio.

One of the great advantages of Radian now is its speed by using multi cores - loading this many layers in QGIS takes a long time. But once they are loaded, QGIS can identify any feature without the user having to select which drawing/layer/source it belongs to.

It's not imperative that the info is displayed immediately. I can imagine there is some processing overhead to identify which feature in which drawing has been clicked on. I'm willing to wait a minute or two for the info to be displayed given that the speed elsewhere is so good.


4,843 post(s)
#13-Sep-17 06:50

Not sure what the status of the info tool request may be 6 months on?

Have faith in your ideas. If you have an idea you want to advance, have faith in the rightness and value of that idea. Do not weaken the presentation of your idea with posturing that distracts from your credibility and the clarity of what you want.

Take the above: Art suggested "Info tool - click on an object, see the attributes of that object." Everyone knows that suggestion was quickly implemented, none of this "6 months on" stuff about it. Skip that and just say what you want.

Likewise, don't lose credibility by failing to take advantage of resources. The path to getting what you want into any Manifold product is simple and clear and set out for all to use in the Suggestions page. Review that page carefully if you want to influence the direction of the product.

As the Suggestionspage makes clear, use discussions in this forum to sharpen your thinking, but don't mistake talking stuff out with friends with sending in a suggestion. Art knows that very well, so that's why what he posted here wasn't a request, it was kicking off a discussion thread to sharpen any requests he might eventually make.

It's a good process: it results in higher quality suggestions that people really want and it helps people build more credibility and greater influence by saving them from sending in ill-considered suggestions. When your friends help you in the forum it is much easier to send in suggestions that are really sharp and well thought out, and which have compelling influence. Always good!

I have just added 459 drawings into a map, and each drawing has a label tab, so over 900 tabs at the bottom of the map.

The above reads like an arithmetic error, which certainly you did not intend. If each drawing has a label tab, and you add 459 drawings, should there not be 459 tabs? Let's work on that so that when you do send in a suggestion any errors do not detract.

While we are at it, we should not weaken a perfectly good idea by wrapping it in a pathological example of highly inappropriate use.

You may have your reasons for putting 459 layers into a map. That Radian can handle that OK is a credit to the technology. But normally it is a very, very bad idea to do such things that are highly contrary to effective data management or data presentation. There are many very useful tools and concepts in database to help better organize your data. If you are trying to consume 459 separate items of anything in a single swallow, that is almost certainly a very deep administrative or data design mistake. There are better ways you should be using.

Now, I agree that on a "one off" basis sometimes we need to do something quick and dirty. For example, there are legacy formats (some US military formats come to mind) that will bring in a map showing a region as hundreds of small drawings/tiles. The format was organized that way because of the restrictions of hardware in software many decades ago. If you just want to take a quick look, then, sure it is great that Radian can give you that look even if a map ends up with hundreds of layers.

But to actually use that data the first steps are to union it into more coherent form, to reduce the infrastructure craziness that prevents efficient, modern use of the data.

It's true there are facilities in Radian, such as the Layers element of the Contents pane, which make it much easier to work with maps that have many layers. But those are not intended to make it efficient to use hundreds of layers at once, as trying to apply hundreds of layers at once is intrinsically inefficient and wrong. If there was an application where that was really necessary, you would need a different user interface completely.

What you are asking is very simple and should not be weakened by saying it is necessary to handle weird pathology of 459 layers.

QGIS can identify any feature without the user having to select which drawing/layer/source it belongs to.

That's a design decision that cuts both ways.

The point of having layers in a map is to be able to organize and use your data in sensible, efficient subunits. When you have too many subunits to keep track of them all, the use of subunits is no longer helpful, not being either sensible or efficient. it is time to combine some of them.

Rational use of layers in a map also means they should, ideally, have some visual distinction to them. That's why formatting is usually tied to layers, because that way you get natural efficiency in terms of "what you see is what you know" (WYSIWYK... just invented the term, thank you for future credits... :-)

If a map is so cluttered with so many layers you don't know in what layer the objects you see are located, well, you've done a lousy job of designing your map. We all do that, of course, since sometimes "quick and dirty" is the convenient way, and sometimes maps and their layers have a way of growing way out of control. Every one of us has probably many times ended up with a map with zillions of layers, most of which aren't even turned on, and thinking, "OK... time to clean this up..."

Now, a key, absolutely essential way to keep order with many layers is to have precise tools for picking those things that are only in the layer of interest. It is essential that an alt click operates only on the active layer so that when you click on an object of interest in the active layer you do not have to worry about data being reported for an overlapping object in a different layer. This is non-negotiable, as it is a massively important filter function.

The right solution is to have a modified command, such as a Shift-Alt-Click, that will reveal what is clicked underneath the mouse without considering whether what is clicked is in the active layer or not. That's a perfectly sensible thing which maps having eight or twenty or whatever reasonable number of layers might benefit from.

I think we could all agree on the above, but even so the user interface design task is not done yet. To go from a "talking out loud" conversation here in the forum where we can casually write things we haven't really thought through to a razor-sharp suggestion that will have the impact we want, we need to think through at least two aspects of the matter:

1. What about overlapping objects? Consider a "let's overlay everything on the planet" format like S57 where the illustration in the topic show routine use of dozens of objects overlapping. (Click on the link to read the topic and you'll see what I mean.) For which one of them does a "super alt click" display attributes? Would it not be better to have a "super select" that selected all objects from all layers on that spot which you Shift-ctrl-clicked? You could then see in Select - Window which layers are involved. Something to think about.

2. Think about how this feature will be useful to the greatest number of other users, and what that implies for how it should work. If you ask for something specific that is a big interest only to those people who create maps with over 400 layers it may be a perfectly fine tool for such situations, but if it is only of interest to one in ten thousand users it is not going to get as high a priority for implementation as a feature that virtually every user might want. So think about how the broad base of users might do something like this.

I'd be curious to hear what your suggestion would be based on the above. How should a Shift-Alt-click work given the above two issues? Are there better ways than a Shift-Alt-click? Are there other issues besides the above two?


4,843 post(s)
#13-Sep-17 07:52

If each drawing has a label tab, and you add 459 drawings, should there not be 459 tabs?

Ah, I see the meaning: for each drawing you add both a drawing and you also have a labels component for each drawing that you add to the map. So that's the multiply by 2 effect.

What is your data set and application that ends up with 900 layers, half of which are labels? It's cool that Radian can handle 900 layers in a map, but it seems there must be better ways to organize the data.

436 post(s)
#13-Sep-17 16:19

He's using Qgis. Isn't he limited to one data type (lines, points, polygons) per drawing? Perhaps simply moving to Manifold or Radian he could scrunch that down to a total of 306 layers. I, too, am curious as to the application that requires so many layers all in one map.

I routinely have 23 tabs open in my working map. The application is maintaining parcel maps for a county appraisal district. In all the 256 counties in Texas, I'm the only one using Manifold. ESRI has those other people locked in tight. In my 23 tabs, only 3 are live all the time (Google Earth, parcels, and labels). I have several labels for the same parcel depending on the end user and what info they want to see in a label. Some other tabs are historical reference maps used weekly but not daily. I have others used at least annually but are not in my map of 23. Two of my tabs are simply tools I use to straighten out the parcels according to field notes in deeds. Nobody sees these but me. 3 layers are provided by the community and vendors as reference to help me to find objects on the ground.

I have two other .map files which only get used twice a year. I update the parcels from my daily map and print specialty areas for others in the office. I never print anything from my daily working map, but the entire reason for these secondary map files is to export to Adobe Acrobat and print to our plotter. There are only a handful of layers in any print job, but there are probably 100 layers and labels in the file. I created the secondary files to keep from changing colors and styles back and forth from what I use and what they want. With the separate files I can print their stuff without interrupting work on the master files.


3,048 post(s)
#16-Sep-17 12:44

Another one:

A View-> Grid type function that was in 8 that allows you to create points, lines, and Tiles for a window extent.


3,048 post(s)
#17-Sep-17 14:25

- Raster / Vector interaction:

a. select raster values touching selected vector objects

B. Transfer summary statistics to pixels that are touching vector objects

In actuality, the Surface functionality in 8 is great. All of those functions are "nice to have", but these two above are really critical if you want to call what you have a raster GIS.

I must say, it would be cool to see the watershed tools parallelized. That is much harder than he focal functions like slope and aspect.


7,903 post(s)
#21-Sep-17 09:06


I take it you meant transferring statistics from pixels to touching vector objects, not the other way around in B (although both ways make sense and we will likely allow both, using more or less the same functions).

dyalsjas95 post(s)
#27-Sep-17 02:30

The Radian Studio and Manifold future releases offer very impressive data engineering capabilities. The benefits parallel and GPU processing add to the processing and visualization is amazing.

As a long time Manifold user (my first serial number was issued on 02 January 2002), I’ve also been pleased at the continuing stability of the user interface. This is a subtle but important feature. As Manifold matured and increased in capability, the Manifold user interface retained much of the basic look I became familiar with years ago and my proficiency between versions increased.

In Radian Studio, data Tables became the primary data representation. The explosion of structured data sources that include geographic referencing information and variety of available data management systems makes it imperative to portray those sources as the foundation of data exploration. Unfortunately, some of user interface clues that supported user understanding in Manifold system have not been implemented in Radian Studio or Manifold Future yet.

With the Radian Studio focus on data engineering, the user interface was less functional for me. In fact, it brings to mind the data engineering studio (I cannot recall the name) that was developed by the Manifold team back in ‘00 to ’04.

I believe that the key concept for any GIS software is the “graphic” part of Geographic Information System, not just graphic in data representations, but graphic interface clues about data relationships. In Manifold System 8, the drawing is the primary data representation that supports understanding; tables are the background information that the user exploits to support improved visual understanding.

A simple example; in the Manifold System 8 project pane, a table is indented under its associated drawing and can be collapsed. There is no visual association between drawing and table in Radian Studio or Manifold Future project pane.

I’ve long wondered why (in Manifold System) changes to the name of a linked object (table or drawing, etc.) did not propagate to the other associated items; e.g. if the user changes the drawing name, the associated table name should follow. Table queries should follow the table name as well. Comments and scripts should also be able to be linked to an object.

I’m sure the arguments about “crapping up the interface” with too many toolbars will be… hmmm… effervescent… but I’ve always felt the Manifold design team found a great balance between “just enough to help a user function” and aggravation at having too many functions and capabilities hidden or scripted.

For several years, I was the ARCINFO command line interface expert in my shop (yes, I’m showing my age). I’m happier when I have many teammates with enough proficiency (developed quickly) that they can contribute to the group effort.

I know there will be an impressive effort needed merge the Radian Studio technology with the mature Manifold System interface. After this much time invested in Manifold, I won’t be abandoning the product, but I hope I don’t have to wait until Manifold System 10 to have the graphic usability I have with Manifold System 8 today


1,863 post(s)
#27-Sep-17 02:50

if the user changes the drawing name, the associated table name should follow

Shift/enter after changing the drawing name updates the table name. On rare occasions I have wanted them to be different.

Aussie Nature Shots


4,843 post(s)
#27-Sep-17 09:19

There is no visual association between drawing and table in Radian Studio or Manifold Future project pane.

Agreed. That will be improved as the Project pane morphs into a better system for viewing and curating assets.

On changing the names of drawings and having that rename the table:

On the one hand that's good and obvious to want. On the other hand the greatly extended capabilities of the new technology open up many, many issues as to how you want that to happen. So sure, some of that will happen with future improvements to the Project pane. But the details are very important and raise many non-trivial questions. For example:

Many drawings can use the same table, either based on the same geometry field or based on different geometry fields. You can see this in action by copying a drawing and pasting it. You've just created a second drawing based on the same field in the same table, but which can be independently formatted, host independent selection sets and so on. If a table has more than one geometry column, you can right click on the table and create a drawing using any one of those columns.

So... suppose we have a table with five drawings that are all copies of each other but with different formatting. If we change the name of the table should all of the drawing names change? If we change the name of one drawing, should the name of the table change? Should the names of the other drawings also change?

Table names are used in queries and scripts... should those also change automatically if you change the name of a drawing? How about queries in other projects into which the current project is linked? Should those be opened and the links automatically adjusted? Clearly it's possible to draw the line somewhere in all of this but such decisions have to be made.

Changing the name of a table in a big DBMS installation is a really big deal. If you are working with an enterprise class DBMS like Oracle in some big-time IT application you don't just change the name of a table as an automatic side-effect of changing the name of something else, because changing the name of a table can have huge cascading effects in an installation where man years of effort have gone into queries, scripts and other things that expect a particular name to be used. In such installations you don't want some automated dialog pouring through all that work product making changes.

[Besides being extremely risky from a "breaking things" perspective, it is also very difficult to do in an automated way correctly... big-time IT groups write queries with extensive comments in them... can the automated tool correctly understand the difference between the name of a table used within in-line SQL and comments such as "this table used to be called wellheads_03 but has been renamed wells_inventory3" to know not to change the old name that must be preserved? ]

Radian is now an enterprise class DBMS. It is shaped for spatial data work, not transactions, true, but all the same it has a truly staggering range of sophisticated features that can be used, and are being used, to create enterprise-class constellations of queries and such in organizations that are sophisticated in their use of DBMS. Those folks do not want automated changes to the names of tables.

This brings to mind...

With the Radian Studio focus on data engineering, the user interface was less functional for me. In fact, it brings to mind the data engineering studio (I cannot recall the name) that was developed by the Manifold team back in ‘00 to ’04.

... I'd agree with that but only with the adjustment "the user interface was less functional for me for GIS." After all, Radian is not a GIS. It is a DBMS tool with an interface for DBMS users, not for GIS users.

The product way back when was Database Commander, a product I've used right up until this summer, when I finally switched from Commander to Future, mainly because Commander uses .mdb, a far more fragile format than Radian .map. Commander was basically the table manipulation capabilities from the GIS, with a few additions, and intended as a personal information manager, interactive DBMS utility, analytics tool and a Swiss army knife tool for database users operating at the sub-enterprise level (can't really consider .mdb a suitable format for Enterprise class IT users).

The comparison is spot on, since Commander is not a GIS either and would drive GIS people nuts if they tried to do GIS things with it. Likewise Radian, which originally was intended to not have any GIS stuff in it at all. But for all that, even to this day it is very hard to beat Commander for table/personal information manager/casual database uses. I use it for very simple things but it has an astonishingly broad range of capabilities.

Anyway, I guess my point is that for GIS things look to the GIS, which is what Future is becoming, not to the DBMS tool. For anything DBMS, then the DBMS tool is fair game for revision, adjustment, etc. For example, suppose somebody wanted a package not for the DBMS overlords in IT but a more pre-packaged deal for us normal people, like a modernized, simplified Commander based on Radian... well such a Personal Radian might not be a bad idea. I say "simplified," by the way, because too many gadgets can get in the way of ordinary people being able to use a tool.

I hear you, by the way, and totally agree on the nice balance between a visual connection and getting things done in 8. 8 is really exceptional in that way, and Future as a GIS is not yet there. But it will be and it should be significantly better than 8, because the technology provides better support for a more fluid relationship between visuals and doing stuff.

One small example of that: with 8 you have to think about what projection a map uses and what projections layers use. With Future you can go a long time before you realize, "hey... wait a minute... I haven't thought about projections and layers in maps at all..." It's that smooth. Whatever the map's projection may be, you can drag and drop a Bing or Google layer into it and that gets reprojected on the fly, instantly. With 8 you had to think about it and use only a map with the Bing or Google projection. Just that one thing saves so much hassle, but because it is so built-in you don't notice it or that the former hassles are no more.

That's also transformative for work flow. So many of the examples in the doc now use imageserver layers because those are so easy they've become the default standard. The end result looks a whole lot better with a fraction of the effort. That goes for many other cases where the new capabilities take what used to be a worrisome hassle with 8, like thinking about whether using a big raster would kill the effort, and now you don't even think about it but just use what you want.

StanNWT62 post(s)
#27-Sep-17 14:40

Is there a way to use aliases for table names instead of the real table name so you're not messing with ask the other databases and linked projects that require that table's name to be unaltered? Perhaps making an optional "use table alias" function? If the tables true name is still there but allowing the user to set an alias based on changing the drawing name. Yes I can see that you would then have to keep a related take our the sun total of all alias table names linked to that table and which map files, drawings, copied tables or databases linked to it, but it's a suggestion.


4,843 post(s)
#27-Sep-17 08:43

Thank you for the very thoughtful post. Some questions...

I hope I don’t have to wait until Manifold System 10 to have the graphic usability I have with Manifold System 8 today

... There's a big GUI difference between a DBMS tool for spatial engineering (Radian) and a GIS (Manifold), even if that GIS is based on the same engine so it can benefit from the increased capacity and speed of new, parallel technology.

So far the only glimpse of what a GIS based on Radian technology might look like is in the Future series of builds. Everybody should be on Future. As noted in my other posts, those builds are following a cyclic, spiral approach to zeroing in on a GIS. Each turn of the cycle touches on major areas where the GUI for a GIS is significantly different, more visual as you correctly say, than for a DBMS tool.

The first turn of the cycle is straightforward. It began with the introduction of a fundamentally dynamic approach - panes, not dialogs - that provide an "always on" capability. It's easy to underestimate what a big change that is until you see it being applied as is now starting to happen. The first step in the cycle was new, more interactive editing. Coming now are major steps for formatting, smooth interactivity 8-style for selections between windows and tables, print layouts/legends and a few other things. And then it will be another turn of the cycle through editing, formatting, etc., to fill in holes, make adjustments, etc.

Doing all that in public can cause confusion, for sure, but it brings the overwhelming benefit of gaining real-time feedback from experienced users like you. The key thing we need is specifics, specific lists of items in priority order that you want or that should be altered. Don't worry about waiting to see what is coming before commenting. Speak up now without fear that will be redundant or impatient. :-)

So... with that desire for specific feedback in mind, what is your top 5 items for graphic usability you have with 8 today that you want to see in 9 as well?

dyalsjas95 post(s)
#28-Sep-17 03:05

Hmmmm… You don’t ask easy questions, do you Dmitri?

I’ll start with the easy ones.

1. Graphic selection tools.

New selection, add, subtract, and select from. A toolbar button reminds a user of options that a keyboard modified mouse click does not.

2. Scale drop-down and Zoom Box.

These are geo and graphic (yin and yang, Laurel and Hardy, Abbot and Costello).

3. Insert new geographic features; point, line, and area.

Again, nearly required toolbar buttons that remind users in a way that a keyboard modified mouse click does not.

Users of a data engineering studio may prefer or expect a reliance on keyboard input to execute their work. Graphic is the distinguishing element of Geographic Information Systems. Manifold has done this exceptionally well for years.

4. Contents in the project pane should have graphic indicators of relationships (established on data import) or deliberately by user action.

Art Lembo already suggested a comparative standard for geographic feature editing ease of use; (better than feature editing than ArcGIS Pro 2.0). I’d prefer the goal that feature editing interface be as robust and just a bit more intuitive than Manifold System 8.0.

5. This will be a challenge. I love the selection toolbar and the transform toolbar at the bottom of the Manifold System window.

That’s five suggestions for graphic interface. I suspect the most challenging integration effort will be in the project pane. There are so many visual clues that could be integrated to lead users to logical and intuitive organization of their data within a project.

As an interesting thought exercise; if a full extent display of a drawing (with no selection) is a graphic representation of a full data table; a user defined change in display extent of a drawing is effectively a visual query of a portion of the data table. Should user defined changes in display extent be recorded in the system data tables or as a type of query?


4,843 post(s)
#28-Sep-17 07:19

Some items already there...

Zoom Box.

Right-click and drag. It's very convenient, way faster than 8 and once you experience it you cannot go back to the old way. See the User Interface topic and various videos.

Insert new geographic features; point, line, and area.

? Already there. That is what the cross cursor buttons on the main toolbar do. See the Editing Drawings topic.

Should user defined changes in display extent be recorded in the system data tables or as a type of query?

Could be. The question would be how useful that might be given that window sizes change all the time as people move and resize windows, work on different machines, can have multiple different windows of different sizes showing the same thing, will be able to have live views appearing as frames in print layouts, etc., etc.

It seems to me to be the sort of interactive thing that would be used on the fly, like the check box to restrict to selection in the operation of transform templates in the current transform dialog... you could have a check box to "restrict to current view" when using an interactive transform template. Like everything in such cases you would be able to push a button to open the query that implements the task given the restriction to what is in view (I suppose that would require a new function to on the fly generate a bounding box for the current view of a specified window...).

Mike Pelletier

1,492 post(s)
#28-Sep-17 16:47

Dimitri - why not add under the Help dropdown a cheat sheet of commands such as the above Zoom > Right-click drag? For those who use the software infrequently it would save lots of time and would be easy to keep current. It can be very frustrating not knowing how to do simple stuff without diving into a big manual.

Restricting transforms to the current view would be very low on my list. I know Arcmap has that for topology tools but a simple selection can be done quickly.

Speaking of 5 items, just wanted to be sure you saw this post.

StanNWT62 post(s)
#27-Sep-17 03:04

I think a useful feature for attribute tables would be a checkbox or button or option in sql code or a written transform that allows on to see just the attributes from the visible objects in the drawing / map or from the full list of attributes in the layer. As one zooms in the list of objects shown in the attribute table shrinks. And a record count in the attribute table box would be useful that reflects the listed records of the total records.

StanNWT62 post(s)
#29-Sep-17 03:47

Another useful couple of features are:

  • The ability to draw geodesic polylines. Geodesics are used all the time in the air traffic or shipping / navigation route maps. Also generating great or small circles accurately in all coordinate systems would be a useful thing.
  • The ability to have a field which calculates areas based on a coordinate system different from the data set. I mostly use equal area projections, specifically Canada Albers Equal Area Conic for Canada. The EPSG code: 102001. Most of my data goes beyond a single UTM zone, and geographic coordinate systems are horrible for area calculations. I know that I can transform the coordinate system of the data layer to CAEAC create the geometry field do the area calculation then set a different coordinate system, but it would be nice to allow for the user to pick the coordinate system at the time they calculate the area. Yes I'm assuming you can write a script for this... I just think this would be a nice option for those of us that use area calculations in different coordinate systems than that of the data. I use XToolsPro with ArcGIS all the time with this capability and it drives the Esri tech support nuts when I state why I use XToolsPro, they hate XTools..., and the fact that XTools does things so effortlessly that they themselves don't do simply from their toolbox or menus irritates tech support.
  • Creating the equivalent of a fishnets as polylines of polygons, or hexagonal grids as polylines or polygons; based on x, y bounding box coordinates, and cell spacing or number of rows and columns.
I know I may be completely missing functions that are already there but just an observation of things I use very regularly.

For example generating a rectangular or hexagonal polyline or polygon grid with a cell width / height of 10 m with a bounding box of 60N, 140W, 85N, 100W. Yes a very massive rectangular or hexagonal grid.

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