...

MobileMap requires ArcGIS Feature Services to define the data model for data access, data collection and editing. The first step in using MobileMap, therefore is to design and publish a data model. To do this, the general process is: Document > Build > Symbolize > Publish > Test.

The build process utilizes a python toolbox that WSG provides to all clients. This toolbox processes data model documents (CSV files) that are described below. Some users develop their data models using other workflows or tools. While this is fine, it should be noted that there are a limited number of Esri data types that cannot be used in sync-enabled services (Esri documentation at https://doc.arcgis.com/en/arcgis-online/manage-data/manage-editing-hfl.htm):

• 64-bit object IDs

• Big integer

• Date only

• Time only

• Timestamp offset

Documenting Data Models

The WSG approach to documenting requirements is to use a spreadsheet format in which the layers, fields and allowed values are captured in two tabs of an Excel spreadsheet - data model and domains. The requirements gathering process starts typically starts with one or more templates that WSG can provide based on data models used for previous implementations, as well field protocols (cruise specs) and any existing field forms or data collection software user interface examples.

...

• Layer

  • Layer name, no spaces

  • Recommended syntax

    • Use of plural nouns (e.g. Stands, Streams, Roads)

    • Where multiple words needed, use title case with underscores (e.g., Treatment_Areas)

    • For cruise use Stands, Plots, Trees, Logs

• Layer Type

  • Polygon, Line, Point, Table

• FieldName

  • Where multiple words needed, use title case with underscores (e.g., Plot_Type)

  • Keep it human readable by avoiding abbreviations, acroymns, slang (e.g. use Cruise_Type instead of CRZTYP)

• DataType

  • TEXT, LONG, SINGLE, DOUBLE

  MaxLength

  • The data types above are the only data types supported by this data modeling script. Some users develop data models using other workflows or tools. While this is fine, it should be noted that there are a limited number of Esri data types that cannot be used in sync-enabled services

    • 64-bit object IDs

    • Big integer

    • Date only

    • Time only

    • Timestamp offset

    • See Esri documentation at https://doc.arcgis.com/en/arcgis-online/manage-data/manage-editing-hfl.htm

• MaxLength

  • Only for TEXT fields

  • Maximum number of characters that can be entered

• Precision

  • Only for SINGLE and DOUBLE fields

• AllowNullValues

  • Yes = field is not required, No = field is required

• Default Value

  • Enter the default value to be stored for the field when a new feature is created. If the field uses a Coded Value Domain, enter the code (not the description) here.

• Domain Name

  • Must match the domain name in the domains CSV file

...

• Stands - Required polygon Feature Layer, symbolized using Status field.

• Source_Stands - Optional polygon Feature Layer. Can be used as a lightweight polygon layer as a temporary destination when importing or copying stand polygons. Most or all fields should be optional (possible exceptions include Stand_ID).

• Plots - Required point Feature Layer, symbolized using Status field.

• Trees - Required business (attribute only, no spatial) table

  • For Coded Value Domains, the codes should only include capital letters and numbers. This is because MobileMap will convert the text entered (or selected when using popups) for Coded Value Domain fields to ALL CAPS then it will compare the modified value to the allowed codes. If the codes use lower case, they will not match.

    • Valid: C, CULL

    • Not valid: Cull, cull

• Logs - Optional, business (attribute only, no spatial) table. Used for recording defect, product or grade by log

  • For Coded Value Domains, the codes should only include capital letters and numbers. This is because MobileMap will convert the text entered (or selected when using popups) for Coded Value Domain fields to ALL CAPS then it will compare the modified value to the allowed codes. If the codes use lower case, they will not match.

    • Valid: C, CULL

    • Not valid: Cull, cull

Cruise Table Optimization

Currently MobileMap supports vertical scrolling but does not support horizontal scrolling. This can pose challenges when a cruise spec requires a large number of measurements per tree, such as research, carbon, lidar, wildfire and permanent plot cruises. Below are some suggestions for addressing this problem if you find that there is not enough real estate on the Tree List to accommodate all of the attribute fields that need to be collected.

1. Optimize column widths - MobileMap supports configurable column widths that be used to tailor column widths to the size of the actual data that is entered. It can be necessary to also shorten the length of the field alias that is displayed

2. Modify data type or character lengths - Changing from full words to single characters can reduce width that is required to display any given field. An example might be changing alias for the ‘Product’ field from ‘Prod’ to 'P' and the values from ‘Saw’ and ‘Pulp’ to ‘S' and 'P’.

3. Combine fields where possible - Often it is possible to combine 2 or more fields into 1 while still supporting the full range of values. An example might be the fields ‘Live/Dead’, ‘Cull’ and ‘Decay Class’, which are often included in carbon cruise data models and typically follow the FIA user guide in terms of field definitions and allowed values. Under FIA standards, Cull is only relevant for live trees and includes Rough and Rotten values. Decay class in only relevant for dead trees and includes 5 decay classes. These 3 fields can be combined into a single field named ‘Condition’ with an alias of 'C' and the following codes/values:

   1. LT: Healthy live tree

   2. CP: Live tree with rough cull suitable for pulp

   3. CR: Live tree with rotten cull not suitable for pulp

   4. D1: Dead tree decay class 1

   5. D2: Dead tree decay class 2

   6. …

   7. D5: Dead tree decay class 5

4. Use Logs for additional fields - If log-level data are not used in your data model, this table can be used to store less common attributes. For example, defect, cull, decay class can be stored in the ‘logs’ table which is only opened for those trees that have defect that needs to be recorded

5. Store data at the Plot level - If some trees are only recorded as plot information, such as witness trees, they can often be recorded on the plot record by adding a few additional attributes to the Plots table (e.g., Witness Tree 1 Species, Witness Tree 1 DBY, Witness Tree 1 Distance, Witness Tree 1 Azimuth,Witness Tree 2 Species, …)

Business Logic Data Model Requirements

...