Subscribe to this thread
Home - Cutting Edge / All posts - Manifold Future - Functionality that is needed to make Manifold Future part of my daily work process
Sloots

414 post(s)
#24-Sep-17 08:42

So far I'm impressed by Manifold Future. Beatiful editting capabilities and enormous speed gain, WFS-support etc. etc. But there are still some functionalities that I use on an almost daily basis that are not implemented yet. In random order:

  • import of ESRI-ascii grd files (or am I missing something?)
  • Kriging, i.e. the equivalent of Paste as Surface in M8
  • Information about (a) developing plugins and (b) creating my own GeoCoder
  • Layout Component (as I produce many maps with Legend, annotations etc. in an automated way)
  • Scripting acces (API) to all of the above (I've got the feeling that scripting is not fully in operation right now, correct me if I'm wrong)
  • Linking drawings to a query (in the same project).

This is it for now. Post some more when it crosses my mind.

Cheers


http://www.mppng.nl/manifold/pointlabeler

Dimitri


4,278 post(s)
#24-Sep-17 16:36
  • import of ESRI-ascii grd files (or am I missing something?)

? Already there. See the data sources page or just go straight to file import and choose the esri grid type or let it autoselect.

Attached is an example import.

  • Kriging, i.e. the equivalent of Paste as Surface in M8

You'd do that in SQL, now, but smoother Transform style ways of vector to raster will appear.

A list of what you want to see by way of one-click or similarly easy vector to raster or raster to vector operations, ideally in priority order, would be great to get. Anybody else who wants to chip in with their lists for that, that too would be great!

  • Information about (a) developing plugins and (b) creating my own GeoCoder

Tons of scripting info, but creating a module like the image server interface or geocoding server interface in 8, not yet. I suppose to some extent that's less necessary given that your geocoder could simply use the same interfaces that one of the nine supported geocoders use and you could point the URL at your own geocoder. Have you considered that?

  • Layout Component (as I produce many maps with Legend, annotations etc. in an automated way)

Part of the "becoming a GIS path for Future," coming soon.

  • Scripting acces (API) to all of the above (I've got the feeling that scripting is not fully in operation right now, correct me if I'm wrong)

Scripting is very massively and very fully in operation right now, with extensive documentation and even simultaneous examples in C#, VBScript and IronPython. See http://manifold.net/doc/api/scripts-net.html

  • Linking drawings to a query (in the same project).

Already supported. There is an illustrated example of that.

Future is moving along, I agree, and also I agree things need to get added or made easier, so please keep those lists coming. What you use on a daily basis is exactly what needs to happen first.

My own list of what I want is: faster and easier formatting using the new always-on "panes" approach, selections that are automatically bound between drawing/table 8-style without requiring any transferring of the selection from window to table or vice/versa, and, of course print layouts. We need to take a turn of the cycle through all those, and then another turn of the cycle through editing, formatting, selections and tables and print layouts to fill in holes and provide some more smoothness and richness.

Attachments:
esri_grd_eg.png

ColinD


1,818 post(s)
#26-Sep-17 10:05

For a start here's a few priority features from my regular M8 usage:

1. GPS console

2. AddIns e.g. Join Selected Points; Assign Projection; or Edit Go To. For example I have an M8 WMS served state-wide aerial photograph. When I need to have a look at a target area I overlay a polygon, select it and hit the EditGoTo addin to instantly get me there.

3. Use of selection for data exploration. Needing to examine the distribution of records for a particular species from a points drawing of say 50k records I theme points on Selection (I) = 0 as invisible then select the target species which become the only ones showing on the map.


Aussie Nature Shots

Dimitri


4,278 post(s)
#26-Sep-17 14:07

Thanks! Some questions..

GPS console

How do you use the GPS console? Is it for moving map? Is it for acquiring points recorded by GPS?

Assign Projection

You can specify a projection to be used now. How is what you want different from what is already in Future?

When I need to have a look at a target area I overlay a polygon, select it and hit the EditGoTo addin to instantly get me there.

You could do that now in Future. Drop a layer with the polygon into your map, right click on the layer tab and choose zoom. Is what you want different from that?

ColinD


1,818 post(s)
#26-Sep-17 20:50

GPS console is for moving map in a vehicle collecting data over an aerial image. Thanks for the tips, I am at early stages of exploring Future as most of my available time is taken up using M8 for immediate work needs.

Expanding on GPS console: points are added to a drawing overlying an aerial image with data added to the drawing table using instant edit.


Aussie Nature Shots

Dimitri


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

OK. I can see how that would work in 9 once GPS interaction is added. Moving map based on a feed of positions from GPS would definitely expand usage scenarios for Viewer as well. :-)

By the way, in a related note, Radian/Future/Viewer now read GPX so if you have info acquired with handheld GPS, etc., in GPX format you can use it.

mihalynuk3 post(s)
#08-Oct-17 07:55

Congratulations on Radian; a revolutionary product. It is reminiscent of the quantum leap from MS4.5 to MS5, but with more technical significance. Regretfully, Radian functionality is still too limited to be of real use in the everyday workflow of producing maps at our Geological Survey. You ask: “What functionality is needed to make Manifold Future (MF) part of our daily work process?”

One key feature would create instant MF adoption: enable updates made within MF to contained linked MS8 maps to be persistent. WHY has this functionality been intentionally omitted? MS8 maps link flawlessly, but changes made in MF cannot be retained, even if the intrinsic MS8 ID field is manually edited. Providing this functionality would allow MS8 addicts to shell out of Beta MF and update drawings (creating bounded areas, registering images of archaic paper maps using control points, navigating a helicopter to a specific sample site using the GPS console, fixing error-ridden imported linework using topology factory, snapping to grid/graticule, drawing freeform lines, and printing maps -approx. in that order of importance (to us)). If we could edit linked MS8 drawings in MF, we could enjoy the benefits/strengths of both products until MF evolves into an all-purpose GIS tool (MS9?), supplanting MS8 (hopefully the new GPS console won’t be prone to crashing the future MS as it does MS8).

For geological maps, we need two other features: custom line types and the ability to easily apply formatting to areas bounded by those lines (geological contacts). More than a decade ago, we created and published a geological symbol set for Manifold (including key line types and some area patterns in Computers and Geosciences) http://www.sciencedirect.com/science/article/pii/S009830040500258X ; to our knowledge, the first peer reviewed reference to Manifold System ® (e.g. as per Web of Science). We’ll need to convert the symbols to a font set to be of use in MF, but treatment the custom line types remains a question, as does the fate of custom patterns. Implementing MS8 color formatting themes in MF can be done using the StyleAreaColorBack entry, but the MF color reference seems unnecessarily arcane (there is probably some code efficiency reason unknown to us): it would seem that the color values are base 10 equivalents of hexadecimal representations of the RGB values.

A fundamental philosophical issue that we have dealt with is polygon maintenance. Polygon maintenance is expensive and error-prone, and because polygons are defined by lines, each of which may have different attributes in geological and other maps (e.g. unconformity, intrusive contact, fault, inferred contact, etc.), polygons are redundant. We don’t bother to store them, but create them as needed (mainly to convey information to a human viewer) from lines and a centroid. Geological maps are not unique in this regard. In our view, the GIS world would be better off without polygon baggage. The ability of MS8 (and earlier versions) to very efficiently and rapidly create bounded areas from lines and to apply thematic information based upon attributes of a point within the bounded area, allowed us to significantly streamline our spatial databases and their editing and maintenance. We suspect that MF could benefit from less reliance on polygons which on their own are inherently redundant because of shared boundaries (leading to unnecessarily swollen Geom coordinate lists because of redundancy with adjacent polygons). Regardless, easy access to the “create bounded areas” function is critical, as are spatial overly functions.

In another thread, Georeference.org contributors contemplated how to best deal with an abundance of layers (drawings) tabs in a boated map. One solution would be to permit stacked maps, each with its own (less bloated) subset of drawings/layers, and toggling between them. Maybe we can find that thread and develop this suggestion further.

KlausDE
6,043 post(s)
#08-Oct-17 09:21

Like-Button missing

Stacked maps perhaps buried in this thread ?

Dimitri


4,278 post(s)
#08-Oct-17 15:04

Thanks for a wonderful post! It really helps to have a sense of priorities so that while everything gets done, those things people need most get done first.

Some quick answers to specific questions...

One key feature would create instant MF adoption: enable updates made within MF to contained linked MS8 maps to be persistent. WHY has this functionality been intentionally omitted?

Initially, that's the combined result of Radian being a DBMS tool and Release 8 not having been designed to be driven from an external user interface console through OBDC.

we could enjoy the benefits/strengths of both products until MF evolves into an all-purpose GIS tool (MS9?), supplanting MS8

That's the real and most important task, to reduce the time to 9. As good as 8 is, it has structural limitations from an earlier day that cannot be blended seamlessly into a fully parallel world of Radian, Future and 9. Any Radian-based product has to treat 8 as a limited thing, a sandboxed environment so to speak, where connections to and from have to be translated on the fly from what Radian is capable of to what 8 is capable of. That's a huge amount of effort that takes a lot of time to do, and at the end is somewhat pointless if you really intend to replace 8 with 9.

Much better would be to invest the same effort into getting to 9 faster. In fact, it's quicker to get directly to 9 than to invest into supporting a parallel world running 8, hence the decision to connect to 8 as a source for work in Radian/Future/9 (a quick and easy thing to do) but not to delay 9 with a massive investment in twinning with technology that 9 renders obsolete.

Commenting on the list... keep in mind that it's only been a month and a week since we started moving a "database tool, not a GIS" into becoming a GIS, so a lot of this is in the works.. :-) We're doing the basics in two cycles: first, a turn through vector editing, formatting, selections/transforms/tables, and print layouts at the entry level and then a second turn through all those to backfill stuff left out during the first turn, make adjustments based on community feedback, etc.

(creating bounded areas, registering images of archaic paper maps using control points, navigating a helicopter to a specific sample site using the GPS console, fixing error-ridden imported linework using topology factory, snapping to grid/graticule, drawing freeform lines, and printing maps

... bounded areas are easy. Sounds like that would make a great transform to add.

... registering images using control points. That will come with raster editing. We want to pump out full vector editing capability first and second do the full raster editor thing.

... GPS console. Part of making a GIS from a database tool, I agree.

... Topology factory. This will be done using the new transform pane technology, which has not yet been merged into the system but is one of the big things in the weeks ahead. We're moving such capabilities out of dialogs, like the Transform dialog in the current system, into panes, which provide a much greater degree of interactivity between the map display of the data and the control panels in the panes.

... snaps to grid /graticules. This almost made it into the first cycle of editing, like the snaps to vertices, but instead will be in the second pass. There's a nice variety of snaps that will be in the system.

... drawing freeform lines. Likewise. There will be a variety of editing tools beyond the basic ones now there. We are trying to apply a "less is more" philosophy so instead of dumping a truckload of every possible editing tool imaginable (most of which never get used) to instead present a reasonably rich set of those tools that actually get used.

... printing maps. In this cycle for basic print layouts.

custom line types and the ability to easily apply formatting to areas bounded by those lines (geological contacts).

The former I understand and is coming. Custom styles for areas, lines and points will be there in the next turn of the cycle through formatting. The latter I'm not sure I understand what you mean. If you mean a control that says "format everything that touches anything in this set" it seems to me that is more a selection or SQL thing where you want to organize the relationships between data. Once you have relationships that you want, then a standard, rich set of thematic formatting controls should work great and there should be no need for special-case thematic formatting tools.

The ability of MS8 (and earlier versions) to very efficiently and rapidly create bounded areas from lines and to apply thematic information based upon attributes of a point within the bounded area,

Given a "create bounded areas from lines" function, 9 will do that far more efficiently and faster than 8.

We suspect that MF could benefit from less reliance on polygons which on their own are inherently redundant

Well, nothing about Radian, Future or 9 relies on polygons. At a deep level the system doesn't really care.

But you can't say the same of a legacy infrastructure of zillions of data sets where GIS practitioners for several decades have accumulated exabytes of data where they use polygons to order notions about what is the inside of a system of ordered coordinates and what is an outside. There is so much of that already done and out there that it merits features in the GIS to exploit the data people have and how they have chosen to order it.

as are spatial overly functions.

Lots of them already there, in case they were overlooked.

the MF color reference seems unnecessarily arcane (there is probably some code efficiency reason unknown to us): it would seem that the color values are base 10 equivalents of hexadecimal representations of the RGB values.

I haven't looked explicitly but I suspect this is nothing more than the infinite influence of the web, which to a greater and greater degree defines and rules all aspects of human life. My guess is that whatever trendy JSON web style stuff is now being used for color values is what is driving the Radian choice. The technology of the web for cartography and GIS outweighs what classic GIS people do by about a billion people to one so there is a lot of benefit to piggybacking on whatever they do.

It's a bit humbling to realize that some programmer sitting within Google who can't even spell "GIS" might decide to apply a particular standard to Google's web mapping API and the next day whatever color value representation that guy decides will have a greater influence on what billions of people do in spatial work than the cumulative effect of ESRI hammering away for half a century.

But it is what it is and if you can use what that guy decides to make life easier for users, may as well leverage it.

mihalynuk3 post(s)
#10-Oct-17 07:42

Thanks Dimitri for your thorough and thoughtful commentary. Its great to hear about all of the Manifold Future GIS tools in the pipeline.

Unfortunately, I failed to successfully convey that the single most important feature that could be added to Manifold Future (MF) in the lead up to MS9 is the ability to write edits to linked MS8 files. As you point out, there is little lasting benefit in implementing “connections to and from [MS8 to MF that] have to be translated on the fly from what Radian is capable of to what 8 is capable of” and that is not what we are asking for. Given the awesome speed of Radian, nobody will want to run MS8 unless they NEED to do things that Radian/MF is not yet capable of (or for which they have not yet learned the Radian methodology). However, the ability to maintain key drawings in MS8 format (for example, because they are incrementally updated with GPS coordinates from the GPS console), while viewing in MF (currently possible) and making minor persistent edits in MF (not currently possible) would ease transition pains for any person or organization heavily invested in MS8, and committed to moving onto MF (and the future MS9).

RE: imaginary utility of polygons. It comes as no surprise that the brains at Manifold have designed Radian to not care about polygons. Its also nice that you acknowledge the waste of the polygon-centric GIS world and systems built around polygons as a key entity. Few seem to grasp this. Is there a role for the Manifold community to enlighten/lead the rest of the GIS world in this regard? (Does this topic deserve a separate thread?) At the very least, a few wise paragraphs in the introduction of the Radian (MF/MS9) manual might be in order. It is probably too radical to eliminate the polygon drawing tool, but maybe suggest that it is a proxy, a specialized line type with the same start and end nodes (to ease the pain of those addicted to polygons;). How could this polygon fat-free paradigm be advanced? How about an editing mode where areas bounded by lines, let’s call them “display polygons”, are automatically created? If a new line passes through an existing “display polygon” then that polygon is automatically split by the new line. If a centroid with associated color theme exists in the “display polygon” then it is colored accordingly. Polygons without centroids could be colored some randomly selected shade of a user selected default color. This would eliminate topology build surprises, for example, where “a tool seems to be working perfectly, while at a fine level everything is quickly turning to custard (and must be redone from scratch)”, and making “a proper mess of good topology by editing areas and relying on snaps” would not be an issue.

tjhb

7,503 post(s)
#10-Oct-17 08:20

That is almost complete nonsense.

Unfortunately, I failed to successfully convey that the single most important feature that could be added to Manifold Future (MF) in the lead up to MS9 is the ability to write edits to linked MS8 files.

Actually, you did convey that quite well, but it is false. Not just subjective and personal, but obviously and trivially false.

RE: imaginary utility of polygons...

You are saying: areas can always be constructed on the fly from existing geometry, where equivalent. Therefore, we should never have areas.

The premise is trivially true. The conclusion is trivially false.

tjhb

7,503 post(s)
#10-Oct-17 08:38

All the same, this is not a bad idea.

How about an editing mode where [areas] are automatically created [whenever subdividing lines are drawn].

That could be really good, as an additional tool.

It would not require getting rid of anything that currently exists. (Certainly not area objects.)

artlembo


2,875 post(s)
#10-Oct-17 15:38

I think calling mihalynuk's comment almost complete nonsense is unduly harsh. Also, indicating that that his desire to write edits to MS8 as false and obviously trivially false is totally uncharitable. You can behave better than that. The topic heading is Functionality that is needed to make Manifold Future part of my daily work process, and therefore, all of our comments in this thread are subjective.

As far as the polygon issue is concerned, I don't necessarily agree with his stand, but I may understand where he is coming from - and therefore, would never publicly call his ideas nonsense. If he is older like me, then he may have cut his teeth on workstation ARC/INFO. The way topology was handled there is exactly what he is talking about. There really weren't polygons in ARC/INFO - it was lines that were topologically built into polygons. This was based on the old DIME file structure used by the Census Bureau. In fact, when I started using Manifold in 2005, this was a hard thing for me to grasp, as I very much enjoyed ESRI's way of doing things (out of habit). I was so used to polygons really being an abstraction of line features. Most of us thought in this way - we saw the world as lines, with an ability to generate polygon definitions from those lines. Also, the ARC/INFO model that explicitly held left polygon, right polygon definitions for each line did in fact remove the redundancy of shared boundaries - with lines, two adjacent polygons were really defined by a single line with different left/right designations for the polygons. It reduced the problems of gaps and slivers when editing - in fact, I still prefer that manner of editing when digitizing tax map boundaries, but, the polygon representation (introduced in ArcView 2.0 in 1995) has grown on me and I am used to it.

Finally, being able to write to Mfd8 would be fantastic. Currently, I like connecting to ESRI geodatabases and would like to move that data into Mfd8. Using Radian (or 9) to connect, and slide into 8 would be great. Instead, what I have to do is save the data in 9, and then create an ODBC connection from 8. Also, since 8 has all the cartography tools, it would be nice to do some powerful analysis in 9, and then slide the results of that analysis into a project in 8.

So, none of these comments are are trivial, or nonsense.

Mike Pelletier


1,396 post(s)
#10-Oct-17 16:09

So how much computing power does generating polygons on the fly from line work really save? Surely there is user interface overhead associated with doing that method as well. Without a doubt much of the data I want to represent is areas and I'm very rarely challenged by computing speed. It does make sense to create tools that allow on the fly polygon creation from lines for cases that it would benefit. Perhaps this discussion needs specific examples where it would shine.

artlembo


2,875 post(s)
#10-Oct-17 16:35

well, a lot of the reasoning behind this was based on 1970s technology. The fact that one could use relational algebra to find all the polygons that were connected by say polygon A, was attractive. For instance, you would find all the lines that had polygon A in the left or right hand side of a line, and then list out all the polygons that were on the other side of the line. So, there was no computational geometry necessary to accomplish this. The magic of course was in ESRI's ability to BUILD and CLEAN a coverage's linework - they called it their license to print money.

As you know, there really isn't any need for that, as computers have become faster, and memory larger.

Manifold 8 does have the ability you talk about: Bounded Areas. Take a spaghetti set of lines and run Bounded Areas on it, and you now have polygons.

I don't think there is much need for the Arc-Node topology model any longer, so my comments were more in line with trying to understand where mihalynuk may have been coming from.

That said, I still find editing parcel fabrics to be easier when thought of as lines. But, that may just be my hang up.

tjhb

7,503 post(s)
#10-Oct-17 21:08

I think calling mihalynuk's comment almost complete nonsense is unduly harsh.

You are right Art. I should have shut up.

Also, indicating that that his desire to write edits to MS8 as false and obviously trivially false is totally uncharitable.

I didn't say that though, you misrepresent me. The desire is fine (maybe even great, if it wouldn't require a massive rewrite of Manifold 8). What is false is that writing edits back to Manifold 8 format is

the single most important feature that could be added to Manifold Future (MF) in the lead up to MS9

That's nuts. (I could have said nuts. People don't like the word 'false'.)

Similarly, I absolutely get the idea that lines plus centroids can be a better way to approach topology than areas. I don't even think that's old fashioned, it's about good conceptualisation and technique. (Editing areas can be a trap. I think I said that in my earlier post.)

But that doesn't mean that areas should be cut out. They matter, for all sorts of reasons and for many users.

What made me bristle was the tone taken: "what I most want is objectively most important", "what I prefer not to use should just be removed". (I exaggerate slightly but that was the repeated tone.)

Fight arrogance with arrogance? A very dumb instinct. Sorry. Can do better, yes.

tjhb

7,503 post(s)
#08-Oct-17 23:07

Lots of interesting points made by mihalnuk here, and Dimitri's comments are great.

On the other hand, the largely rhetorical comments about areas (polygons) seems less well aimed. The comments may be valid for geological workflows (even all geological workflows), but not universally.

Yes it is often quicker and more accurate to create or edit topology using lines alone, and it's very easy to make a proper mess of good topology by editing areas and relying on snaps, or shared editing. It's not always a question of user training--sometimes a tool seems to be working perfectly, while at a fine level everything is quickly turning to custard (and must be redone from scratch).

But it's wrong to suggest that polygons "on their own are inherently redundant because of shared boundaries". Areas have redundant storage (where there is adjacency), but that is a completely different thing from being redundant. Areas are useful in ways that lines are not, not just for for communication and display, or for spatial overlays (which you mention) and topology overlays, but more importantly as a natural object type for storing two-dimensional data. All of that is core GIS. Where all data is linear then storing areas may be unnecessary. But in many cases data is not one-dimensional.

Lastly of course, no GIS product should try to suit just one kind of user.

Forest
529 post(s)
#10-Oct-17 03:14

A swiping tool would be nice similar to what esri has. Perhaps the swiping tool could even work with one image server layer over another. I spend a lot of time looking at aerial photos and trying to see what has changed.

dale

523 post(s)
#10-Oct-17 05:46

Plus one from me.

tjhb

7,503 post(s)
#10-Oct-17 06:08

And me. (I don’t use Arc anything so I’m going on the swipe tool in Global Mapper—very intuitive, somewhat addictive.)

Dimitri


4,278 post(s)
#10-Oct-17 07:28

A swiping tool would be nice

Out of curiosity, what's wrong with a faster toggle in the Layers pane? Suppose, for example, a press and hold on a layer made it invisible for the duration of the hold? Or, even better, perhaps the toggle for visibility should not be a double-click but just a click. Click off, click on.

The swipe tool is without doubt useful, but it is one of those secret handshake commands people don't learn until the mystery is somehow revealed to them. It also involves a special gesture of the mouse in what otherwise is a limited set of simple mouse gestures that may be higher priority.

For example, a desire to pan the view is probably far more frequently desired than a desire to temporarily make a layer invisible to see what is underneath. Adding a special version of a mouse move that is very similar to the click and drag used for panning is asking more of the user.

On the other hand, I understand that when the mouse cursor is in context hovering over some object you might not want to move it over to a pane to do even a one click on/off. But there perhaps instead of a swipe the right solution would be a keyboard shortcut similar to how the space bar toggles snap off/on.

Not resisting any good ideas, just wanting to avoid growing a collection of mouse moves that are similar to each other.

tjhb

7,503 post(s)
#10-Oct-17 08:01

There's nothing wrong with a faster toggle!

But a swipe tool adds something (a) really cool, (b) entrancing, and (c) much more likely to show differences not immediately obvious otherwise.

So, focussing on (c):

Such differences can be make or break. Eureka, face palm, etc.

E.g.:

Thank god I caught this before the client saw it.

How about we try putting P against not inverse Q, but actual Q + k.

More opportunities like that.

Dimitri


4,278 post(s)
#10-Oct-17 16:49

much more likely to show differences not immediately obvious otherwise.

So... what is the command sequence for the swipe tool? Click and drag is taken for pan, so it has to be something else.

It should be unique, that is, a sequence not used in any regime (viewing/navigating, editing, etc.) since you want to be able to swipe to look underneath no matter what command regime you are in.

And... it should not conflict with any of the classic, well known mouse moves.

Click and drag - Pan

right click and drag - zoom box.

Ctrl click and drag - a selection move

ctrl right click and drag - a selection move (not yet in product but assigned in commands awaiting merger...)

Shift modifier for the above... varies open/closed

ALT modifier for the above... forces a deselection

... The above means that all the usual click and drag modifiers, that is, clicking and dragging on either the left mouse button or right mouse button using various combinations of shift, ctrl and alt, are spoken for.

That leaves the Third Rail of keyboard modifiers, the Windows key, a risky choice given that Microsoft secretly wires up the Windows key to immediately force a Windows 10 update that takes days and loses everything you were working on the moment you try to use "their" key. Ctrl-Windows-drag and drop? ...?

tjhb

7,503 post(s)
#10-Oct-17 21:32

... The above means that all the usual click and drag modifiers, that is, clicking and dragging on either the left mouse button or right mouse button using various combinations of shift, ctrl and alt, are spoken for.

That leaves...

Space is also spoken for (toggle snaps).

Caps Lock could possibly be used. When Caps Lock is engaged, panning is disabled. Horizontal mouse movements swipe to hide the current layer (opacity -> 0), from the cursor position left or right, showing only the layer(s) below.

I don't know though. Just a toolbar button? (Same function.)

[Added: Scroll Lock would be a better semantic match than Caps Lock, but I'm not sure how many keyboards still have Scroll Lock, or will have it in future.]

tjhb

7,503 post(s)
#10-Oct-17 22:00

...Deactivating Caps Lock would restore normal opacity (from properties).

I suppose Caps Lock is not a completely dumb idea. It's available everywhere (AFAIK), and hardly used.

But switching to a code or comments window immediately after using swipe would cause a certain amount of swearing.

Maybe too much swearing--or would it be OK?

[Added] Just to flesh it out a bit more:

Setting Caps Lock in a map window would mean that moving the mouse further left would hide the current layer (0%) for the region covered/extended; moving the mouse further right would show the current layer at its current opacity for the region covered/extended; layers above would be unaffected (continue to show); layers below would be unaffected (continue to belnd with opacity).

Vertical mouse movements would be ignored. Panning, selection, snaps would all be disabled--it would just be a display mode, for looking.

Disabling Caps Lock would restore the previous display mode and associated settings (including current snaps).

Forest
529 post(s)
#12-Oct-17 04:46

On swipe tool vs fast toggle, a swipe tool is better as one can move the line back and forth over a single small object to see how the object has changed. Usually, I am looking at small features that are close to the resolution limits of the imagery such as individual tree crowns. Toggling the whole image makes too much change and swamps my ability to track changes for individual objects. Often I have to mentally correct for small inaccuracies in georeferencing and for changes in light direction and atmospheric conditions as well so having a swipe tool where I can go back and forth over small objects to see changes helps.

Dimitri


4,278 post(s)
#12-Oct-17 08:23

My preference for how to do this would be to use a modifier with a right-click and drag. You don't have to draw a dotted line box but just open a window with maybe some other border effect to make it clear the extent of the opened window/trapdoor/stargate/portal into the world below.

Right-click and drag for zoom box is a totally super move that very quickly becomes a part of you. Mentally, it is like declaring "I want that view" so an analogous notion like "I want to see what is in that box underneath" is something that seems a natural extension. An absolutely ideal thing would be WindowsKey-right-click and drag, since it would be opening a window, so to speak, into the world below the active layer. But then there is Windows itself throwing elbows at all the other claimants to ensure it gets first crack at that Windows key. :-)

I wonder if a <spacebar>-right-click and drag is a possibility, using the spacebar as a modifier while trusting to sense timing as to whether the spacebar is tapped by itself to toggle snaps or held while a mouse move happens...

Quick question... I don't have Arc in front of me and don't remember the exact details... what's the precise set of moves in Arc for the swipe tool?

dale

523 post(s)
#12-Oct-17 12:36

Not Arc, but other tools I've used bring up the swipe as a dividing line. Click on the line, drag left or right across screen.

Arc's online swipe on line help is here

Dimitri


4,278 post(s)
#12-Oct-17 15:57

OK, well, in the other tools that sounds like a three part process:

1. Invoke a swipe tool.

2. Click on the line and drag left or right.

3. End the swipe tool (to get back to whatever you were doing).

If that is true (big if...) I don't like it because it means that if you are in the middle of doing something like an editing command building a polygon or whatever, you have to stop that to invoke a swipe tool to see what is underneath. In my book that stinks. A click of a layer off/on ... two clicks total... that does not interrupt whatever is the current command seems better.

Arc's help is funny. They say the swipe tool is used to interactively reveal layers beneath the layer being swiped, commenting that "This tool makes it easy to see what is underneath a particular layer without having to turn it off in the table of contents."

But if that is what they praise it must be really difficult to turn off a particular layer in the table of contents as there is a lot of ponderous motion involved in using swipe. The general form comes from the Effects toolbar:

"To use the Swipe Layer tool from the Effects toolbar, choose the layer you want to swipe from the Layer drop-down menu on the Effects toolbar. Then click and hold as you move the mouse pointer over the map."

It seems they've left off the first three steps, which would be:

a. Stop whatever you are doing.

b. Call up the Effects toolbar.

c. Choose the Swipe Layer tool in the Effects Toolbar.

... and only then would it be

d. Choose the layer you want to swipe from the layer drop-down menu,

e. click and hold as you move the mouse pointer over the map.

------------

The above is really, way over the top ponderous.

I mean, sure, if we're going to require entering a special Swipe Tool mode then the way more difficult design task of making it always available goes away. Suppose we choose a rarely-used, under-assigned Ctrl key sequence like Ctrl-T (mnemonic for "toggle layer"). Here's what a faster Manifold way would look like that corresponds to the ESRI way of apparently requiring choice of a Swipe Layer tool:

1. Ctrl-T. Toggles swipe mode to on.

2. Right-click and drag to open a window into the layer below.

3. Ctrl-T. Toggles swipe mode off.

---- we don't need no stinking "choose the layer you want to swipe" since such things obviously apply to whatever is the active layer. If you want it to apply to a different layer, just click that layer tab (or the layer in the Layers pane)

I think even better would be Ctrl-T just to toggle the layer off/on. Then it is a very fast motion without needing to move the mouse out of the region where it might be busy doing something.

---

Ah, and if the appeal is gadgety stuff (I'll admit it, I'm a sucker for such things sometimes as well...) then maybe Ctrl-T just toggles an X-ray mode where the mouse cursor turns into a big, drop-shadowed "hole" in the active layer, as seen in the illustration.

Move the mouse around and the "hole" moves around so you can peek at what is underneath. Move the wheel on the wheel mouse to expand and contract the size of the "hole". When done, click Ctrl-T again.

Actually... I kind of like that idea... This is where engineering rolls their eyes and asks the inevitable question... "OK... in the list of wishlist items, where do you want this one to go?...." :-)

Hmmm... cannot resist... the effect seen above brings to mind another idea: it would be cool if we could define a layer that contains area objects as a "mask" or "stencil" layer. What a mask layer does is that it forces transparency into an associated layer, say, the layer just under it. So, to get the illustration above you put a circular area where you want the Bing Maps layer made transparent and, voila! in that circular region there is no Bing maps layer covering up the layer below. You could have layer properties for things like "drop shadow" etc.

All these things are potentially interesting ideas, but it is a matter of utmost seriousness to get them into priority order. There is no end of fun things that can be done. The hard part is choosing which limited set must be done first.

Attachments:
mfd_swipe_tool_in_action.png

Dimitri


4,278 post(s)
#12-Oct-17 16:27

A better rendition (roads are above the layer that is cut out...)

... so... I guess that brings the idea for a mode for this tool where *every* layer above the designated hole moved about by the mouse becomes transparent in the hole... a "super swipe" tool.

... I guess another mode would be where the wheel mouse does not expand/contract the size of the hole but instead (perhaps a Ctrl-Wheel?) decreases/increases opacity of the hole. So maybe you want to move the hole around to see what is underneath, but you still want a faint ghosting of upper layers to appear for context.

Yet another idea... once you have a tool like this, you could connect an expression or a function to the tool, so that in the case of rasters what appears is some sort of functional transformation of what it shows, like edge detection, swapping of colors or other effects.

Attachments:
mfd_swipe_tool_in_action.png

Forest
529 post(s)
#16-Oct-17 03:24

I would prefer a square overlay/history window as I am usually looking for trees, vegetation boundaries or creek channels that have moved and as these are curved by nature, a straight edged swipe window would be better.

Apologies to guys who have to code for this stuff. It is not something I need now but is an unmet need as don't have anything that does that know.

Just a question. Have the manifold crew ever taken a look at what the Carnegie Airborne Observatory have been doing. They are the world champions of remote sensing and they represent what I aspire too. I am trying to make a tool kit that does what they do at a fraction of the cost.

Dimitri


4,278 post(s)
#16-Oct-17 14:29

Have the manifold crew ever taken a look at what the Carnegie Airborne Observatory have been doing.

Sure, although that's really a topic for a different thread. They operate an airplane that acquires LiDAR data together with data from a variety of multispectral sensors. Many people do that, which is why the world is flooded with very large amounts of remote sensing data from different instruments. To work with such data you need software that can handle large data and sophisticated analytics. That's one of the scenarios for which Radian technology was developed, as non-parallel software doesn't cut it in such applications.

I am trying to make a tool kit that does what they do at a fraction of the cost.

That's a topic for a different thread. It would be interesting to hear what tools you are developing if you care to start a thread reporting how you are using the Radian API in such tools.

Ah, almost forgot: no issues with a square opening instead of a round opening. There are many ways that could be done.

artlembo


2,875 post(s)
#16-Oct-17 14:52

I think a swipe tool is still important to have - I can't tell you the amount of hours I've wasted moving the swipe tool back and forth over different layers to compare changes from one image to an older image. And, some of the time, it was actually useful!

But, if you had a bubble like this that could expand with a mouse wheel, I think that is even more gagetery (not a word) than the swipe tool! I could see people really enjoying using this bubble tool when comparing different years of imagery.

dale

523 post(s)
#10-Oct-17 12:54

Faster toggle over many layers?

As well as a swipe and/or toggle, toggle many layers in a timed sequence, like Google time-lapse?

otm_shank
47 post(s)
#26-Sep-17 23:27

I'd like to see more capability for working with imagery, such as

  • georegistration
  • set resampling method (smoothing)
  • set output pixel size
  • parallelize writing output file (e.g. when writing ECW, like Global Mapper does)
  • option to split output into multiple files (rows * columns)
  • clip output to polygon
  • mosaic multiple images
  • export to a 'tile package' format (this would also be for maps with labels etc, not just imagery)

KlausDE
6,043 post(s)
#04-Nov-17 19:28

Is there a way to expand snapping to objects in other layers in a map component?

Dimitri


4,278 post(s)
#04-Nov-17 21:13

Not yet, but there will be as part of providing a richer set of snapping modes.

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