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

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


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


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


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


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


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


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

tgazzard117 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,791 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,102 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,791 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,102 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,791 post(s)
#06-Feb-17 10:53

Thanks Adam

Aussie Nature Shots


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

tgazzard117 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,107 post(s)
#06-Feb-17 08:14

[same comment / threads crossed]


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

382 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


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


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

382 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?


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

382 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


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


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

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

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

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


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


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

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