Editor and Curation Workflow

Curation and Validation

As a user, I expect all contributions on MapStory to be accompanied by source information.

Reference Layers

MapStory should provide common geometries that can be extend with tabular data supplied by the user. these "Reference Layers" lower the barrier to entry for non-geospatial users. examples of Reference Layers include:

• political boundaries (Countries, States, Counties, etc)
• Natural History boundaries (geologic time)
• Phsyical geography boundaries (climate types, continental extents, marine bathometry).

Attribution and Verification

Each StoryLayer and feature edit within a StoryLayer should be tied to an owner that represents him/herself with a ‘real name’. POLICY NOTE: Site Administrators have the power to delete, unpublish or roll back StoryLayers that do not abide by the real names policy. StoryLayer editors have power to roll back feature edits made by users that don’t abide by real names policy.

Sourcing (StoryLayers and Features)

• All StoryLayers should have source information listed in the Data Source metadata field.
• All feature edits should have Data Source information listed in a ‘Source’ attribute field for the edit -These sourcing requirements should be enforced by the GeoGig version control mechanism.

Flagging, Approving, Follow Up

• Any user should be able to ‘flag’ a layer if they see something that is broken, inappropriate, or inaccurate.
  • The flag should denote which category is in dispute (broken, inappropriate, inaccurate, etc...)
• Site (or Layer Admin?) Administrators should receive notifications of new flags on layers
• Site (or Layer Admin?) Administrators follow a protocol to review and resolve flags
• Layer detail page should have a space to show whether there are pending/unresolved flags on a layer

Monitoring and Metrics

• Edit activities should be published to the Activity Feed of the user doing the edits.
• Users should be able to follow the edit activity on a StoryLayer of interest by requesting ‘notifications’ be sent whenever the StoryLayer is modified.
• The StoryLayer detail page will also provide basic monitoring and metric information, such as: an edit history list; total edits made; date/time of most recent edit; number of unresolved flags; lists of contributors

Versioning

Users expect to be able to make edits to StoryLayers that are tracked

Layers as "Repositories"

The key conceptual shift for the next generation editing implementation is that a single StoryLayer in MapStory is, in effect, a repository of its own. This enables workflows for layer creators and layer editors as follows:

• Once created, each StoryLayer has its own GeoGig repository
• (Needs Review) StoryLayers have admins that can manage the StoryLayer's schema, update and commit strategy, etc., Furthermore the Owner is by Default a layer admin. StoryLayer admins can elevate other editors to admin status. Admins can also demote fellow admins with the exception of the StoryLayer owner. Organization and Initiatives can act as the owners of their StoryLayers. Additionally, site admins have StoryLayer admin access on all StoryLayers
• StoryLayer creator can set StoryLayer editing rules as either only owner-edited, edited-by-select-users or edited-by-whole-community. (Note - If StoryLayer is edited-by-select-users, these users will be listed on StoryLayer Detail Page for transparency. Invited editors receive a notification and ‘accept’ to become editors.
• StoryLayer owner can change layer between owner-edited or edited-by-select-user status at any time. But, once a StoryLayer is set to edited-by-whole-community this status cannot be reversed.
• If a StoryLayer is edited-by-whole-community, than edit contributions are automatically approved and published. If a StoryLayer is owner-edited or edited-by-select-users the StoryLayer Owner can set edits to be “published automatically” or “require review and approval”. If require approval, StoryLayer Owner and editors with approval status get notifications and can see pending edits in the StoryLayer Owner view of the StoryLayer’s editing interface.

Branch Editing Models

• If a user seeks to make many edits to a StoryLayer they can create a “Branch” of the StoryLayer. In the Branch the user can upload multiple new edits and make other feature and attribute changes and then, when finished, submit a “pull request”. If the StoryLayer is owner-edited or edited-by-select-users, a owner will review and merge the pull request. If the StoryLayer is edited-by-whole-community the pull request will be automatically merged. If the pull request causes disturbances, another editor can roll-it-back.
  • schema changes to edited-by-whole-community StoryLayers can only be preformed by site administrators in accordance with administrative guidelines
• Branch editing can be done off-site in a desktop environment such as QGIS and appended via the importer. Basic edits must be done on-site or within the tools.mapstory.org site.

Basic Editor Updates

Users have expressed a desire to build on the existing editing experience in the following ways. Please see this doc for a complete set of Layer Editing userstories:

As a user, I expect to be able to propose edits to StoryLayers in a simple editing interface. The things I should be able to edit include: feature geometries, feature time information, feature attributes, and StoryLayer metadata. My edits to features should be able to be done through a map or a table view. And all edits should be tracked in a history. Finally, if I desire it, I should get notifications when my edits are changed by another user, or if a StoryLayer I’ve edited is changed at all.

Geographic Editing

Geographic editing involves:

• moving the location of a feature
• adding a feature
• deleting a feature
• modifying the boundary or path of a feature

Temporal Editing

Temporal editing involves changing the start-time or end-time information of a feature. Edits should be enforced at the same temporal resolution

Metadata Editing

Metadata editing involves changing the title, abstract, and data source information for the layer

Attribute Editing

Attribute editing involves adding new attributes to the layer schema, editing existing attributes, and adding/editing content within an attribute for a feature.

Attribution and "Commit" Messages

Whenever an edit is submitted, it should be accompanied by a ‘commit message’ that allows the editor to explain the nature of his/her edits. Commit messages and attribution should be displayed in the Editor History log for the layer. The time of edit and percent change should also be tracked

Allow users to add notes about their edits. For example, an editor may want to note that evidence they have to support an edit, or uncertainty that they have despite making an edit.

Table Editing

As an editor, I can make geometry, time or attribute edits via a table view.

Map Editing

As an editor, I can make geometry, time and attribute edits by selecting features on the map.

Messages & Tooltips

The basic editor should provide detailed user feedback to support the editing process, including tooltips and messages prior to any submissions.

Lenses (Styled Layers within Editor)

The basic editor should display layers with a default style. A simplified style editor also will enable editors to view the layer in additional ‘lenses’ that support editing. these styles (with common preset lenses) should be used for classification and data management within the editor (ie. sort by type, within a specific range, matching a given value, etc)

Users should be able to toggle the basemap that is used in an edit session

<< Previous Section | Road Map Home | Next Section>>