Tethys Map View 2.0

[Jacob Fullerton]

Per our discussion yesterday in the Tethys scrum, it sounds like there are some important features that need to be added to the tethys_map_view gizmo. I'd just like to mention some things that I would personally like to see in the updated gizmo for everyone's consideration (also feel free to add your own ideas/criticisms, I do not intend to monopolize this conversation):

• I'd like to have the color settings for the MVDraw gizmos exposed to the developer in the python wrapper where any hex/rgba color could be used. Currently the map_view gizmo defaults all vector objects to the #ffcc33 (golden yellow color). We might also consider doing the same for the css on the buttons themselves to change the default color in the python wrapper (currently default to a deep blue gray color). Both of these should be optional settings in my opinion.
• Dr. Jones also talked about having a select tool which I agree with, it would be nice to be able to shift-select objects on the map for all selectable layers (need layer filtering still)
• In addition to having a delete button where a user can click on the delete tool and then delete objects, it would be nice to enable the user to click, drag and drop features into a trash bin (also Dr. Jones idea). This interaction is fairly common in most drawing utilities
• A right-click that would bring up a custom menu instead of the default browser window would be nice. There are some libraries I know about out there that could be used, would be nice to add this functionality to the map (again, as a suggestion, food for thought).

That's all I can think of at the moment, I'm sure that more stuff will come to me, but maybe everyone else could mention things that they'd like to see in a webmap with drawing tools.

[swainn]

Here are a few additional ideas based on other discussions:

• Add an "editable" attribute on MVLayers to allow for enabling/disabling editing capabilities on a layer by layer basis.
• Other attributes on MVLayers for more detailed control could be: movable, deletable, creatable.
• Add a "visible" attribute on MVLayers to dictate the initial visibility of the layer.
• Formal support for D3 / SVG layers in MVLayer
• Additional JavaScript API endpoints for the MapView to allow for customization
• Ability to apply a theme to the MapView that would change the color of the buttons as an alternative to specifying the color for each button as proposed above.
• Selective editing mode where user is prompted to select the layers they wish to edit (Alan Snow's suggestion)

In all these considerations, we need to take mobile devices into account. There is not support for right-click actions on all mobile devices(Force Touch on iOS devices is sort of an equivalent action). So, we either need to provide alternatives for mobile devices, or provide a mechanism that works for both mobile and desktop.

[Jacob Fullerton]

With regard to the ability to use either mobile devices or computers, I noticed that the handlers that are currently in place for the dragbox drawing tool are not sufficient for a mobile device. I can't create a dragbox with my phone for instance, the browser thinks I'm panning the map instead. We'd probably need to turn off the map pan interaction altogether for the dragbox interaction to work properly on a mobile device. Presents a problem for a computer user though because a user would likely want to maintain the option to have the scroll wheel still pan the map when it is pressed down, even while using the dragbox feature.

Might also want to include the ability to rotate the map view. Google maps with the two finger rotate or the shift controls on the computer would be what I would suggest.

[Jacob Fullerton]

Something else that came to mind was that if we want the developer to be able to create invisible layers that don't appear on the Legend we should have a separate visibility control that applies to the legend only. Would be useful if the developer wants to build and cache several layers at once rather than recompute a layer (for instance, a raster color map vs. a text display of elevations). It would prevent the user from having to wait to buffer through another computation and would speed up the toggle between different layers without having to have them all display simultaneously on the legend. Just a thought.

[swainn]

Good point about the drawing tools not supporting mobile. Perhaps we can look to the ESRI JavaScript API to see if they have a way to do editing on a mobile device. Perhaps some features like editing could be desktop only. I like the idea of visibility controls for both layers and the legend items. It could be that many layers showing on the map share the same legend. So, perhaps the legend entries should be decoupled from layers completely. I also think we could simplify the legend quite a bit so it isn't so cluttered. One nice feature would be to add the ability to hide/collapse the legend.

[Jacob Fullerton]

I like those ideas a lot! As for decoupling the layers from the legend though I'm not sure I understand what you are trying to suggest. Are you saying that we should make it so that only layers that are given the "legend-show" attribute would appear on the legend, even if multiple layers appear on the legend with the same title (if shown)? As far as hiding/showing the legend I would suggest that we create a button for that at the top right corner of the map next to the other buttons.

What are your thoughts on the bootstrap tooltips for the mapview gizmo? I have been working on adding them into my personal app, when I get it finished I'll  post a screenshot. I think tooltips could be very helpful for first time users who are unfamiliar with what each tool does.

[swainn]

For the legend I'm thinking that we create separate objects that represent entries in the legend (e.g.: MVLegendClass) and then we can assign each legend object to one or more MVLayer objects. That way a multiple layers could share the same legend entry.

Tooltips on the MapView tools would be awesome. 

[Jacob Fullerton]

That sounds good, gives the developer a little more control as to what they want to do for the layers. I like it!

I'll be working on the tooltips for my version and see how it might be implemented as I mentioned. Haven't had time yet, been converting my app to python to see if it makes things any simpler

[Jacob Fullerton]

I got it to work! Only took a couple lines of code to make it work too. Here's the result:

[swainn]

Sweet. Can you work it in and submit a pull request? I still need to review the other one you sent me.

[Jacob Fullerton]

Sure thing, I'll do that tomorrow sometime, just finishing up my other to-do's.

[Jacob Fullerton]

So I'm finishing up adding that tooltip thing, and I was testing the original code I had in place for the delete button. I'm not sure what we will want to do with this button in the long run, personally a select option with some sort of context menu would be nice. However, as I was testing the delete button I also noticed that there is no way for the code to recognize that one feature is sitting on top of another. In other words, if you stack features on top of one another and click once on the features using the delete tool it will delete everything under that click. If we want the delete tool to function such that only the most recently drawn feature in the pixel is seen by the delete tool we need to give some sort of property to the features. It's really a small thing and I'm not personally going to claim that investing the time and energy into this delete button is going to be all that helpful in the long run considering the idea we've had for using a select tool with some controls to read the properties/delete the selected features/etc. Just thought I'd bring it forward in case someone has a quick fix. Here's the code as I currently have it working:

  DeleteFeatureInteraction = function() {

    ol.interaction.Pointer.call(this, {

      handleDownEvent: DeleteFeatureInteraction.prototype.handleDownEvent,

      //Borrow the code from the DragFeatureInteraction for map movement (pointer)

      handleMoveEvent: DragFeatureInteraction.prototype.handleMoveEvent

      });

    this.coordinate_ = null;

    this.cursor_ = 'pointer';

    this.feature_ = null;

    this.previousCursor_ = undefined;

    };

  ol.inherits(DeleteFeatureInteraction, ol.interaction.Pointer);

  DeleteFeatureInteraction.prototype.handleDownEvent = function(event) {

    var map = event.map;

    var feature = map.forEachFeatureAtPixel(event.pixel,

        function(feature, layer) {

            if (layer instanceof ol.layer.Vector) {

                layer.getSource().removeFeature(feature);

            };

        });

    return;

    };

[Jacob Fullerton]

I found this about how we might do it if we are really invested in this delete button:

http://stackoverflow.com/questions/35722225/openlayers-3-hover-to-highlight-only-one-specified-object-per-time

[Norm Jones]

I vote we put our energy into a select tool and a context menu with a delete option.

On Thursday, July 21, 2016 at 2:50:21 PM UTC-6, Jacob Fullerton wrote:

[Jacob Fullerton]

+1, the delete button I've added works for the time being, if people want that tool improved in the future I'd be happy to fix it up if I can (I do for my current app! So let's please keep it going). That being said, I like the idea of a select tool more

[swainn]

I say let's get the version of the delete button that you have in as is and then start working on a modified mechanism.

+1

[alansnow21]

+1

[swainn]

I've decided to go ahead and summarize all of the new features for MapView that we have discussed in this thread. Please let me know if I missed any:

• Color settings for MVDraw feature layer
• Color / theme settings for map control buttons
• Select control with shift-select / control-select modifiers
• Click and drag features into a trash bin to delete
• Contextual menu (right-click) containing options like delete (what else?)
• Add "editable" attribute to MVLayers (possibly "movable", "deletable", and other similar attributes for more fine grained control)
• Add "visible" attribute to MVLayers to define initial visibility of layer
• Formal support in MVLayers for D3/SVG layers (if not already implemented)
• Selected editing: user is prompted to select layers to edit when they overlap OR the user enables editing mode on certain layers before editing
• Hide / collapse legend
• Decouple legend from layers to allow multiple layers to share the same legend entry
• Tooltips on controls (this has been implemented)

[Norm Jones]

I like those select options, but before we get too far down this road, we need to have a plan for exactly how we are going to do the editing/deleting/etc of features. See my other thread. 

[Jacob Fullerton]

So I've given this thread a little more thought and I have a suggestion about how we construct the layers. Typically with Civil 3D or Arcmap, the way to include an object in a specific layer is done in two different ways: 1) you define the layer and select that as the current drawing layer, then generate your objects. New objects are automatically assigned to that layer. 2) You create your objects in a baselayer or any other layer, but by selection can then transfer those objects to a new layer or an existing layer.

I would include a button in the right-click menu as part of the context in the form of an option [Change layer --> 1) Create new layer 2) Move to existing layer].

However, I was also thinking about the GIS nature of the apps that are currently going into this platform and there's a problem currently with just having layers by themselves. I can include for instance wells (points), slurry trenches (polylines), rivers (polylines), and lakes (polygons) all in one layer called "Conceptual Model." If I want to edit the attributes of the layer, the attributes will have to be sorted and filtered by the classes contained within that layer. As the gizmo currently exists, the only registered objects are descriptions of the vector objects (e.g. "Point", "Polyline", "Polygon"). What we would need is a separate attribute apart from describing the type of vector object that would allow the user to create their own object class and prevent overlapping classes with similar geometries.

My recommendation for the problem with overlapping vector objects with different classes would be similar to how Arcmap works currently: select your objects and right-click to get a context menu (or a button could be included for redundancy), within that context menu we could select a "Create Feature Class" or "Add Attribute" button. A modal window could popup and ask the user to give the attribute/class a name and parameter variables (e.g. Name = [well], param1 = [screen elevation], param2 = [pumping rate]) where the number of parameters can be dynamically added by the user (e.g. add parameter) and define whether those parameters are required or not. Those objects would then be appended to the JSON object. If we really wanted to make things similar to Arcmap, we maintain a persistent store of feature classes created by the app as a library. That way, when a user has already defined the attribute or feature class they can right click on the object, select "Assign Feature Class from List" or "Assign Attribute from List" and it will have all of those previously defined classes/attributes with the parameters. Additionally, another context menu button should be included so that a class/attribute can be modified to either add a new parameter or modify an existing one or remove an existing parameter. The classes or attributes would serve as a template, and upon creating or assigning a vector object to a class or giving it an attribute a new window would pop open with the selected objects that would allow the user to assign values to the parameters of each object.

In summary, I recommend that we set up the MapView Gizmo 2.0 to have the ability to create/assign layers to objects and create/modify/assign classes to objects. The classes/attributes should be stored either in the persistent stores of the app or with the objects as they are saved to a PostGIS or some other form of data storage. I would personally recommend a dual storage of the class definitions and attribute definitions where the local machine keeps and maintains a list and any imported object is read and looks for a "Class" tag that can then repopulate the local list. All exported objects should maintain their tags as a JSON object or a separate text file, and imported datasets from other types should be interpreted (shapefiles, kml, etc). The capacity to read other data types and create those classes might be much further down the road, but it's a thought.

If what I'm saying is Greek, I'm sorry, I can probably translate it better via a slideshow or graphic, just let me know. I'm just trying to get some thoughts going on how things could/should be done with this gizmo as I may soon start developing small parts of it that could possibly be extracted for the actual gizmo in the future. I want some other people's opinion as I think about this.

[Norm Jones]

Why would we ever want the user to be able to define new feature classes or modify attributes? In a decision support framework involving pre-defined models, we should be able to define the classes/attributes needed 99% of the time.

Maybe I am missing something.

[Jacob Fullerton]

You're right Dr. Jones, if Tethys is only going to support pre-defined models then yeah, class creation and attribute modification tools would not be necessary. However, I have seen Shawn Crawley's app for the GIS data visualizer with the ability to mesh together several shapefiles and create maps (really great app!). In my mind a GIS data editor follows a visualizer. I don't know what the long-term vision is for Tethys, so maybe that's something I should be more familiar with before suggesting more on this subject, but if we are ever going to not have every model/dataset pre-defined then we're going to want to be able to have some tools where we can custom-make classes and modify the attributes. That's my opinion though.

One very simple application that I could foresee coming about from an app after Shawn's current visualizer is a GIS data editor. A city could have a simple GIS dataset of fire hydrants that they want to keep on Hydroshare and update via a Hydroshare app. Shawn's app can already visualize the hydrant locations on a map, but to add a new hydrant and say when it was installed, what size, who installed it, and all of the other metadata, Map View 2.0 will not have the tools to modify the fire hydrant shapefile, and the city would be forced to have their own software license for something else in order to maintain that file.

Again, if this type of application is outside of the scope, then yeah we don't need to worry about having the ability to create/modify classes.

[Dan Ames]

One example of this is Jocelyn's app where she was allowing the user to draw polygons and change values of the attribute table. I suppose that isn't creating a new feature class, but it is an example of editing values.... Not sure if we need to allow totally creating a new feature class from scratch though.. 

--
You received this message because you are subscribed to the Google Groups "Tethys Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tethysplatfor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tethysplatform/538128c9-7c54-4b80-b119-df2e05a2a14f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shawn Crawley]

I, personally, don't completely understand what is meant by "creating a new feature class." Maybe having Jacob explain in person would help at least me.

To view this discussion on the web visit https://groups.google.com/d/msgid/tethysplatform/CAAduJf6unPC5BVw%3DrsoW9q5oPaEX%2BUj4A8Nt6i7DcQE1Oy4t%2BA%40mail.gmail.com.

[Norm Jones]

What you are describing (defining new feature classes, modifying feature classes) is basically what you do with ArcCatalog in the ArcGIS universe. To me, this seems like a such a foundational, low-level GIS functionality that I am not sure why we would put it in a Tethys app. I doubt we would ever want to try to completely replicate a desktop GIS in Tethys. The focus should be streamlined decision support, data analysis, and modeling applications. 

My $0.02 anyway.

[swainn]

Unless you are building a GIS application like Shawn has done for HydroShare... I could see the value of opening that up to the user in certain use cases, but form most of the applications developed with Tethys, giving the ability to end users to create feature classes will be far too low level. Certainly developers will need (and already have) a programmatic means of creating new feature classes for their apps. If they want to expose those capabilities to the user, then I think we shift the burden to the developer to create the user interface for that. If this becomes a common operation, then we can think about generalizing it and integrating it into MapView. But for now, I don't think it should be high priority.

[Jacob Fullerton]

So far the ability to edit attribute tables appears to be something of more utility than creating feature classes. Of the two suggestions I made regarding feature class creation and attribute table modification I would definitely pick attribute table modification first. I think I'll hop onto Dr. Jones's thread because that particular attribute has more to do with what he was discussing.

[Dan Ames]

I agree with Nathan. There are probably enough other things we should add first. Even in Shawn's case I don't think we are creating new data sets through the app (yet)... - Dan

--

You received this message because you are subscribed to the Google Groups "Tethys Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tethysplatfor...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tethysplatform/64bda3f7-d0c4-4390-838c-5b54db6b143c%40googlegroups.com.

[swainn]

All:

We had a productive design meeting this morning to discuss the new features related to the Map View Gizmo and Layout. To summarize, we are moving ahead with the idea that a more advanced GIS / spatial data editor is beyond the scope of the Map View Gizmo, and will instead be implemented as a Layout (this is a new concept for Tethys, but think pre-built, customizable page/view with controller). The Map View Gizmo will still be supported, but it will be used more as a basic spatial data viewer / spatial data input field, while the Map View Layout will use the Map View Gizmo, but will have additional functionality such as the layer selector, legend, symbology, attribute tables, and advanced editing mode. That said, there are still some upgrades that need to be made to Map View Gizmo to support capabilities that we want in Map View Layout. We have created a design document which can be found at this link:

https://docs.google.com/a/aquaveo.com/document/d/1-x-jsRCCw2_gbIwpo2jAKSECsWkdpymfATIP9em78vo/edit?usp=sharing

Let's move this discussion to the design document in comments and suggestions. Jacob is going to lead the design and implementation effort with help from Scott and myself.

[Norm Jones]

Jacob and I had a pow wow on Friday and came up with a nice preliminary design of the Map View Layout. We are working on the design document. Will report at an upcoming scrum.

However, I will be out of town this Weds. 

--
You received this message because you are subscribed to a topic in the Google Groups "Tethys Platform" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tethysplatform/KZxt9SFzsAw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tethysplatfor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tethysplatform/b46526a5-266e-4e3d-957f-a11a91110f86%40googlegroups.com.

[Nathan Swain]

I will also be out of town on Wednesday, so let's postpone until  next week. I'll send out a message to the group.

You received this message because you are subscribed to the Google Groups "Tethys Platform" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tethysplatfor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tethysplatform/A99EEE4A-27A7-455D-82C6-C2C8DC4A9CBF%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Nathan Swain, Ph.D.

Project Engineer

Aquaveo, LLC

801.709.2943