Roadmap for Creating/Editing/Managing Spatial Data in Tethys Apps

[Norm Jones]

Greetings everyone. I was thinking of adding a post to the other thread on Map View 2.0, but what I want to chat about might be sufficiently different that it warrants a new thread. But if someone wants to merge this with that other thread, that would be fine too.

I'm looking down the road a little bit and considering the number of applications where it will be necessary to create and edit layers of spatial data in a Tethys application. The “spatial data” that I am referring to is points, lines, and polygons. And not just the features, but the associated attributes which may vary from application to application.

To date, we have supported points, lines, and polygons (including rectangles) in Open Layers using the annotation tools. The annotation tools are simple and convenient, but very limited. For example, if you refresh your browser they disappear! That is fine for simple cases, but I'm looking at a more extensive case we're one may wish to create spatial features and/or edit both the geometry and the attributes of existing features. In other words, something similar in concept to the Map Module associated with GMS, SMS, and WMS.

I've been thinking about this quite a bit and we did a little brainstorming the other day when Jacob Fullerton was in my office. I jotted down a few notes and I wanted to throw them out there as a straw man or starting point for discussion. 

It would be nice if we had a framework for special features that would allow you to do the following:

• Create new features manually
  
• Delete features
  
• Edit the geometry of features
  
• Edit attributes associated with the features
  
• Import features from shapefiles or other sources  and then be able to edit them
  
• Save all of the edits to a spatial database
  
• Programmatically access the geometry and attributes of the features (we can do this now if they are in the spatial database)

So here is a general outline of how we may be able to accomplish that:

1. We support a method of organizing special features into feature classes or layers in a Tethys app. This would be a standard GIS feature class where you have a table where each row in the table is a feature and it can have a set of attributes. GIS 101. Each layer would include points, lines, or polygons. In most cases, we would predefine the fields or attributes associated with a feature class depending on the application. There may be cases where we allow the user to establish the fields, but in most applications the fields needed will depend on the use case. These layers would have to be stored in PostGIS or GeoServer or some combination.
   
2. When we want to allow the user to edit a layer, we would pop over into an edit mode (a new Tethys window) which would include a map view and some basic editing tools. Switching into edit mode would require us to take the features that are stored in a spatial database and convert them to annotation objects for editing. We would also need to assign a unique ID to each of those annotation objects and create a 2D array of attribute data. 
   
3. While in edit mode the user can create new futures, edit existing features, or delete features. Based on the type of layer, we would probably need to dim and undim the editing tools. For example if it was a point layer, only the point tool would be available and the line and polygon tools would be dimmed or not available. While in edit mode, we would allow the user to pop up an attribute table dialogue to edit the attributes associated with the features. We could have filters on the attribute table so that it display just the selected features or all features. This would provide a simple way to edit attributes that would be general and would not need to be customized for each application. Of course, this would also necessitate a selection tool.
   
4. When one exits the edit mode, all of the changes made to the spatial features and the attribute table would be saved to the database.
   
5. It would also be important to have a standardized methodology for managing the layers for general viewing. The other day I saw a demo of Shawn's HydroShare GIS app and I really liked what he has done where he lists map layers on the left in a format similar to the ArcGIS table of contents. One can toggle the layers on and off and edit the symbology. We really should be able to standardize this for spatial layers so that a developer could plug it right in.

 Anyway that is a starting point. Feedback welcome. 

[Dan Ames]

I like this proposal except for popping up a new tethys window... it would be smoother if we can just change the mode of the current window/map to edit. Unless the new window could be overlayed seamlessly with all the data that was in the previous view, etc...

--
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/bf1d9791-4b39-4ca7-b127-674c2a7ed04e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jacob Fullerton]

I agree with Dr. Ames, editing mode could bring up different panels perhaps, but changing pages would be a little annoying, especially for small edits.

[Norm Jones]

That is kind of an implementation detail. You would need to load some tools, buttons, etc that are unique to the editing process and would probably want to disable other buttons, etc. while in editing mode. Seems like the simplest way to do that would be to load an edit page. Might also make the implementation of editing easier to do from a programming standpoint.

[Jacob Fullerton]

So I will reiterate that I agree with the top-level road map that Dr. Jones detailed in his original post on this thread. The GUI is up for debate for me, but that's less important.

For editing attributes of features I have some questions:

• Which data types should the map view gizmo support? (I am only familiar with KML and SHP as far as programming goes, I also know that sometimes people store info in TXT and CSV format.)
• How should we keep track of imported data by default? Should there be a GIS layer that is automatically populated with every dataset that is imported into the model?
• How do we want to preserve the GIS data imported/edited by the users? Do we want to save model instances with the GIS datasets? Persistent stores could work for data storage as each dataset is almost exclusively table format by default (postgre/postgis). I can imagine that a user might be running a similar model multiple times and would want to have the same GIS data available in a project every time s/he opened it up online without having to re-import all of the datasets and make the modifications to run the model.

I'm actually starting to experiment with this aspect of the mapview gizmo for my thesis. Input would be appreciated so that I can create something that might be useful to the tethys platform instead of something specific to my project.