Management Ref

Management_ref guidance

Purpose:

The management_ref in Smartsheet is used to track all BV-supported areas under management. Specifically, it documents the following core information:

  • The names of management units and their zones.

  • The area (ha) of each management unit and zone.

  • The communities involved in governance.

  • The communities that fish, harvest, or recreate in these areas.

  • The dates each management method was established, and the zones they apply to.

  • The species and habitats the management methods apply to.

Management Unit & Management Zones:

A management unit refers to a large-scale designated area under a specific management framework. It is typically defined based on ecological, administrative, or jurisdictional boundaries.

  • It encompasses multiple zones that may have different regulations or uses.

  • It can be an entire marine protected area (MPA), a fishery management region, or a broader coastal area under a governance plan.

  • Example: A national marine sanctuary or a community-managed fishing area.

A management zone is a subdivision within a management unit that has specific rules, uses, or restrictions based on conservation goals, resource use, or habitat protection.

  • Zones are created to allow different activities while ensuring sustainable management.

  • Common zone types include:

    • No-take zones (where fishing and harvesting are prohibited)

    • General use zone (where regulated fishing, tourism, and recreation are allowed)

    • Harvesting ban zone (where harvesting a particular species may be prohibited, but fishing otherwise is allowed)

    • Seasonal or temporary closure zones (restricted access during breeding or spawning seasons)

  • Example: Within a marine protected area or community-managed area, one zone may allow traditional fishing while another prohibits all extractive activities to protect coral reefs.

It is important to mention that some areas may not yet be part of a larger management unit and may exist as stand-alone zones, such as no-take zones. In many cases, this serves as a first step toward establishing a broader community-managed area. However, our larger goal at Blue Ventures should be to develop comprehensive community-managed areas that encompass these zones. For data entry purposes, if a formal management unit does not yet exist, you can assign a temporary name until one is officially established. The management zone name should reflect the specific zone’s name.

Data Entry:

  1. For visual examples for entering data, please refer to these slides.

  2. The unit_name is the name of the management unit. If unit_name is left blank, this row will not be counted towards the total area under management during “reach” reporting. Please remember to always assign a management unit name to the zone, and remember: 

    1. If a formal management unit does not yet exist, you can assign a temporary name until one is officially established. The management zone name should reflect the specific zone’s name.
  3. The management_name represents the name of the zone within the management unit. See Figure 2 for a full description of column names. 

  4. The management_method selected should apply to the spatial area of the management zone (management_name). If a management method applies to the entire management unit, the unit_name and management_name should be the same. For example, if a management unit has a deforestation ban across the entire area, including within the small no take zone in the management unit, then the data should look like this:

    1. unit_name= Ambalahonko, management_name=Ambalahonko, management_method= Deforestation ban

    2. unit_name= Ambalahonko, management_name=Ambalahonko No Take, management_method= No Take Zone

  5. The management_area_ha should be the area associated with the zone (management_name). If the unit_name and management_name are the same, as in the above example where the management methods apply to the entire management unit, then the area reported should be the entire area of the management unit, seeing as it’s also the name of the zone where the management methods apply. This is important as the way the area is entered impacts how we calculate total area associated with each management unit. 

    1. There are two ways in which the total area of each management unit is calculated:

      1. The area associated with each unique zone within the management unit will be summed to acquire the total area of the management unit.

        1. For temporary closures, only the area associated with the most recent closure event will be used (i.e. if Brittany TC occurred 10-1-2025 to 12/1/2025 and was 25 ha, and then Brittany TC was closed again 3/1/2026-5/1/2026 and was 50ha in a slightly different location, then we would use the most recent closure event area of 50ha).
      2. If the management unit name and the zone name are the same, implying the management_methods associated with this row apply to the entire management unit, then we assume the area (and management methods) associated with this row apply to the entire management unit, and in this case, we use the area associated with this row, rather than summing all unique zones within the unit to avoid overlap/over-estimating area.

  6. There are several scenarios in which there should be multiple rows associated with a single zone or management_name (see Figure 1 for specific examples). 

    1. When there are multiple management methods in place within the zone, as we want to track the date each method was implemented (est_date), so each method needs to have it’s own row; 

    2. When a management method covers a new species or habitat;

    3. When a temporary closure has new open/close dates.

Examples of Specific Data Entry Issues:

  1. There are several records where management_method=other. Please define what those are, and attempt to fit them into one of the predefined options for management_method.

  2. There are several temporary closures with the same management_name, same open and close dates, yet different lat/longs and different management_area_ha. This implies that a single temporary closure was located in several different places of different sizes (areas) all at the same time. Please identify whether these rows are duplicates (i.e. area and lat/longs are wrong for two of the rows because they were inputted incorrectly), in which case they should be removed, if these are actually spatially explicit areas that need to be distinctly named. See example below:

    1. The only possible way a single spatial area could have different areas and lat/longs from one another, is if each row was meant to represent a different closure event, in which case the open and close dates should be different than other rows. For instance, if Brittany TC was opened 10/1/2025 and closed 12/1/2025 and was 25 ha, but the next closure event for Brittany TC was in a slightly different location and size to reflect adaptive management, then this makes sense, and Brittany TC could indeed have different lat/longs and area. 

    2. If these are spatially explicit areas that opened and closed at the same time in different areas, these closures should be distinctly named, perhaps one called Brittany TC 1 and another Brittany TC 2.

Connecting Management Ref to Spatial Boundaries

  1. The management_name will be used to link the management_ref to the spatial boundaries associated with that zone.

  2. Spatial boundaries are used to validate the area that is reported for each zone in the management_ref.

  3. Spatial boundaries will be displayed in an interactive dashboard (coming soon), with the management_ref data joined to it so that all data documented in the management_ref can be visually displayed and explored in a map. Users will be able to see which management methods apply to each zone in the map, as well as dates they were established, and total area.

  4. To share spatial boundaries with the Spatial and Ecological Team so that they can be displayed in the dashboard and used to validate area numbers, please upload to this google form. Data uploaded via this form is sent to our central landing area (shared google drive called “Spatial Data”) and saved in a standardized naming convention. The data is validated/checked here for naming and geometry issues before being sent to the central database (postgresql/postgis) and subsequently uploaded to the dashboard. Uploading boundaries to this google form allows our team to process data in a standardized way. 

    1. We want to avoid uploading directly to the Spatial Data shared drive, as we want to ensure consistent naming conventions, which our google form generates, and we do not receive email notifications when uploaded directly to the drive (only when uploaded to google form). 

    2. If you decide to upload directly to the shared drive/if someone on your team is GIS-savvy, please upload to the appropriate nested folder. The file structure is Management Units/Country/archive or final. 1) Data that has not been processed to fit our shapefile naming convention (raw data) should be shared to the Management Units/Country/archive folder. Once uploaded, let our team know the data has been uploaded and is ready for processing. 2) If your team is GIS-savvy and would prefer to process the shapefile on their own, please first upload raw data to the archive folder, and then ensure the processed shapefile follows these specifications:

      1. Shapefile name: iso3code_mgmt_monthyear_projection.shp (e.g. ken_mgmt_jan2025_wgs84.shp)

      2. Attribute table naming convention:

        1. mgmt_name = management_name from management_ref

        2. mgmt_ha = area in hectares

        3. iso3 = the 3 letter code for the country

      3. Upload or append data to Management Units/Country/final folder

      4. Notify Spatial and Ecological Team that data has been processed and needs to be incorporated into the global dataset (appended to Management Units/Country/final/ bv_global_mgmt_jan2025_wgs84.shp) and subsequently saved to the postgresql/postgis database.

  5. How to access/download spatial boundaries:

    1. Final management boundaries will be saved to the Spatial Data shared drive in the following pathway: H:\Shared drives\Spatial Data\Management Units\Global\final. Data can be downloaded from here for now, but once the dashboard to visualize the data is complete, the data will be available for download, and pulled directly from our postgresql/postgis database, which will be the final validated dataset.

Figure 1: Example of how to enter data in management_ref. Rows that are colored the same are associated with the same spatial area, indicated by having the same management_name.The highlighted text shows why the new row is justified according to the assumptions above.

unit_name

management_

name

management_

method

target_

species

target_habitat est_date close_date lat long
Velondriake Velondriake Gear Restriction octopus all 1/7/2018 NA 22.0951 43.2304
Velondriake Velondriake Gear Restriction octopus, fish all 9/2/2019 NA 22.0951 43.2304
Velondriake Velondriake Harvesting Ban conch all 2/5/2020 NA 22.0951 43.2304
Velondriake Velondriake Reserve No Take Zone turtle NA 1/7/2016 NA 23.4957 41.2525
Velondriake Velondriake Reserve No Take Zone all reef 4/7/2016 NA 23.4957 41.2525
Velondriake Velondriake TC1 Temporary Closure turtle NA 11/1/2011 2/1/2012 23.5125 42.5631
Velondriake Velondriake TC1 Temporary Closure turtle NA 7/1/2012 10/1/2012 23.5125 42.5631
Velondriake Velondriake TC2 Temporary Closure octopus reef 1/1/2011 2/1/2012 22.3122 42.5551
Velondriake Velondriake TC2 Temporary Closure octopus reef, seagrass 2/1/2011 2/1/2012 22.3122 42.5551

Figure 2: Management_ref column descriptions.

country ISO country code, which is an internationally recognized letter combination code BV
unit_name The name of the management unit that the management_name is associated with. editable
management_name Unique name of the management area with spaces and punctuation allowed. This should be the name of the spatial zone in which management methods apply. There should be at least one row of data where the unit_name and management_name are the same, as this represents the methods within the larger management unit. editable
management_method The type of management method that applies to the management_name. The predefined list includes: General Use, Temporary Closure, Seasonal Closure, No Take Zone, Gear Restriction, Managed Access, Harvesting Ban, Size Restriction, Habitat Protection, or Deforestation Ban. editable
est_date

Date the management method was established/when the management method began applying to new species or habitat; MM/DD/YY

(this does not apply to temporary closures)

editable
close_date

Closing date of the managed area; MM/DD/YY

(this applies to temporary closures only)

editable
open_date

Opening date of the managed area; MM/DD/YY

(this applies to temporary closures only)

editable
mangrove_mon Y/N - Indicates whether ecological monitoring for mangroves has occurred within the management unit (unit_name). editable
seagrass_mon Y/N - Indicates whether ecological monitoring for seagrass has occurred within the management unit (unit_name). editable
reef_mon Y/N - Indicates whether ecological monitoring for reefs has occurred within the management unit (unit_name). editable
mgmt_body The official governing body of the management_name editable
regulation_type The type of legal regulation. The predefined list includes: village head regulation, village head decree, joint village head regulation or none. editable
admin3_fish The list of admin3s that fish, harvest or recreate within the management_name. editable
admin3_fish_flag The flag will be red if one of the admin3s listed in the “admin3_fish” column does not exist in the admin3_ref. BV
admin3_govern The list of admin3s that have a role in governing the management_name. editable
admin3_govern_flag The flag will be red if one of the admin3s listed in the “admin3_govern” column does not exist in the admin3_ref. BV
management_fishing_ground The list of fishing grounds associated with the management_name. The dropdown list is connected to the “name” column in the fishing_ground_ref. editable
fishing_ground_flag The flag will be red if one of the fishing grounds listed in “management_fishing_ground” does not exist in the fishing_ground_ref. BV
target_group Target species group for the management_method. This can include ‘All’, one or multiple species groups. The dropdown list is connected to the MASTER species_ref and includes species groups from all partners. editable
target_species Target species for the management_method. This can include ‘All_species’, one or multiple scientific species. The dropdown list is connected to the MASTER species_ref and includes species from all partners. editable
species_flag The flag will be red if the “target_species” chosen is not referenced in the partner’s species_ref. BV
target_habitat Target habitat for the management_method. The predefined dropdown list includes the habitat choices: reef, seagrass, mangrove, mud_flat, sand, deepwater or other. editable
management_area_ha Size of the management_name in hectares (ha). Keep in mind this is the area of the management_name or zone ONLY. All management_names associated with a management_unit will be totaled to generate a total area for the management unit (unit_name). Only the most recent temporary closure area will be included. editable
management_lat Latitude of management_name editable
management_long Longitude of management_name editable
partner_ID Partner name with no spaces and no punctuation, only underscores. The dropdown list is connected to the “name” column in the org_ref. editable
partner_flag The flag will be red if the “partner” value does not exist in the org_ref BV
spatial_data Indicates if the management_name has a match in the shapefile attribute table. If you’d like to submit any new spatial boundaries (management areas, habitat, communities, etc), upload the spatial files to this form. The management_name will be used to link spatial data to the management_ref, so any spatial boundaries that are sent should include the management_name in the attribute table of the shapefile. BV
bv_started_work The formula in this column brings in the most recent date from the start_date column in the admin3_ref, based on the communities listed in the admin3_fish column in the management_ref. BV
bv_stopped_work The formula in this column brings in the most recent end_date from admin3_ref only if every community in the admin3_fish column in management_ref has a corresponding end_date in admin3_ref. In other words, if three admin3_fish communities are associated with a management area, and one community has an end date in the admin3_ref, the bv_stop_date will remain blank in the management_ref because two communities are still active. A date will only appear in the bv_stop_date column if all admin3_fish communities have an end_date in the admin3_ref. BV
raw_data_id Unique ID to be able to join Smartsheet records to archived Airtables BV
airtable_closure_ref Unique ID assigned to closures in Airtable BV
airtable_notes Notes brought over from Airtable to assist in updating/correcting data in Smartsheet management_ref BV
management_unique Concatenation of lmma_id + lmma_name + management_id + management_name + open_date + close_date +est_date  to identify unique Temporary Closure events and management methods within management areas BV