Ocean and coastal web atlases (which often include data portals) are online collections of maps, datasets, information, and tools related to ocean and coastal areas, including administrative boundaries, the physical environment, biota, and human uses. They are often used by a wide range of stakeholders - ocean and coastal managers, elected officials, and the public – to inform decisions, and they are rapidly becoming an essential element of ecosystem-based management (EBM), marine spatial planning (MSP), marine protected area planning, and other large public decision making processes for the marine environment. Participants in these processes find that having access to relevant, up-to-date, and credible information in a single holds numerous benefits. It can make decision making more efficient and transparent, increase confidence in decisions made, and make communicating with the public about the decision-making process easier.
However, along with their tremendous potential, developing ocean and coastal web atlases and data portals comes with a tremendous number of decisions to be made and the potential to bog public processes down - both time and money-wise - in collecting and managing more and more data. How much data and information is enough? When can ocean and coastal planners and managers stop compiling data and move on to the next steps?
In this issue of MEAM, we hear from a variety of ocean management experts that have experience using and/or building web atlases and data portals about how to scope atlas/portal development appropriately in the context of a larger planning and management process. We also learn from a data portal developer about how that data portal is being used for regional ocean management.
Charles “Bud” Ehler: 30-35% at most
Editor’s note: Charles “Bud” Ehler is president of Ocean Visions Consulting and a consultant on marine spatial planning to UNESCO’s Intergovernmental Oceanographic Commission. He can be contacted at charles.ehler [at] mac.com.
“Building data portals is relatively ‘easy’ (OK, I know nothing related to marine spatial planning is easy!) compared to other aspects of MSP such as engaging stakeholders, agreeing on initial priority issues, specifying SMART objectives, identifying management actions to achieve objectives, linking performance indicators to management actions, developing performance monitoring and evaluation plans—all critical elements of the MSP process. Many of these elements—problems, objectives, indicators—should be considered in the design and development of the data portal.
I don’t mean to minimize the importance of data portals, but it is important to keep them in perspective. If a planning body has $3 million and three years to develop a marine spatial plan, how many of those available resources (time and money) should be spent on developing a data portal and collecting and organizing the data to populate it, and how much on the other essential elements of MSP? I would suggest 30-35% at most. A state-of-the-art data atlas or data portal without a management plan at the end of the first cycle of MSP is not where we want to be. The bottom line is ‘keep the whole process and its elements in perspective’. A detailed work plan at the beginning of a MSP process and its regular review and revision throughout the process should ensure a comprehensive approach to planning and the delivery of some real planning outputs and outcomes on time and within budget.”
Ned Dwyer: Prioritize your data collection efforts
Editor’s note: Ned Dwyer is executive director of the EurOcean Foundation and a member of the International Coastal Atlas Network steering group. He can be contacted at ned.dwyer [at] eurocean.org.
“The key thing is to first decide the audience for your atlas and the overall goal or aim. Why is it that you are developing your atlas? Once you have clearly identified this, it will be easier to decide on the data content.
“In terms of content, you need to decide on the thematic areas that you wish to address and then identify the geospatial data layers that would best illustrate and provide the most appropriate information on this theme. Of course, you have to work within your resource budget – in terms of both time and money. This forces you to prioritize what data to collect first. If the data already exists – in another agency perhaps – then it is easier to source this rather than build a dataset from scratch. Sometime you may discover that the data you would like to include in your atlas does not exist, or is not spatially ready (e.g., just lists of yacht clubs, but not as a GIS layer), so you have to create the GIS layers yourself. If you have already prioritized your data requirements, this allows you to decide if this layer is vital or just a ‘nice to have’.
“In addition, over the lifetime of the atlas project, you should set resources aside for both the update of the existing layers and the collection/creation of new ones. I think sometimes people forget that data and information change. It is vital to ensure the geospatial data layers in your atlas are as up-to-date as possible.”
Joanna Smith: Set a deadline and intermediate milestones relative to the overall timeline
Editor’s note: Joanna Smith is the marine spatial planning science manager for TNC Canada and The Nature Conservancy’s Global Oceans Team. She can be contacted at joanna_smith [at] tnc.org.
“An MSP atlas should be built to match the scope of the planning objectives and inform the planning outputs, including a zoning design (if one is being developed) and the management plan. So, for example, if the planning process is for fisheries, offshore wind energy development, and tourism, then a data needs assessment and gap analysis are done to determine what is needed, available data, data gaps, and contact information for the data custodians relative to making decisions about these activities. Every layer in an atlas should relate to the process objectives, directly or indirectly. Depending on the MSP process timelines, and the capacity available for staff and financial resources, this assessment and analysis can be done rapidly at a fairly high level or methodically and in detail. The best way to limit data collection and compilation to a reasonable amount of time is to set a deadline and several intermediate milestones in relation to the overall timeline. In rough terms, the initial data collection and compilation phase is probably one-fifth to one-third of the total length of the project beginning during the first 1-2 years of the process, or sometimes beginning before an MSP officially starts (pre-planning phase). It is important to hold stakeholder consultations to determine what data are going to be important for planning. It should then follow that the data are prioritized to those issues that are in scope for the planning process, once objectives are finalized for the MSP. Additional data are identified throughout the process and should be added to the catalogue and incorporated into decision-support tools to inform decisions.
“The iterative nature of data gathering is why an adaptive geospatial data framework is important. With an adaptive framework, data can be added and outputs updated or analyses rerun when necessary. Oftentimes, efforts have been made previously by government, NGOs, or other organizations to compile marine and coastal data layers, and all efforts should be made to capitalize on these previous initiatives and build on them. It is rare that an MSP process would have to start from scratch. Planners can look for data portals and other online data storage platforms hosted by governments, institutions, NGOs, and intergovernmental organizations. A web atlas is a really valuable tool to have for planning, but planning can progress before it is completed. Intermediate data and mapping products can be created to share spatial data layers or maps with stakeholders and build planning tools. For example, ArcGIS spatial data catalogues can be used to build Adobe GeoPDF files that contain multiple spatial layers and sketching tools. More sophisticated tools, such as SeaSketch, that contain a range of simple and complex functionalities can be added or used.
“To give a real-world example: in Seychelles, The Nature Conservancy and TNC Canada are facilitating an MSP process that is led by Government of Seychelles. Capacity within the core team is limited, so a high-level, rapid data needs assessment was completed in 2014, and we partnered with another project in Seychelles that was compiling biodiversity datasets. The Seychelles MSP is a great example of an MSP process that has had to carefully manage time spent on developing planning tools versus completing planning outputs according to strict timelines. A spatial data catalogue was one of the first planning outputs created to support the development of a draft zoning design for 1.37 million square kilometers of Seychelles’ Exclusive Economic Zone. Individual layers were shared as maps with stakeholders, in an Adobe GeoPDF, and in presentations to inform planning. Now, in the third year of the process, TNC is building an MSP atlas for publication because we have the time to put this product together. The MSP Atlas is being created with 35 key layers for print and online publication, and additional layers will be added over time to the online version. A mini version of the Atlas (10 layers) was put together in temporary binders to test it for several months before publication, getting input from committee members and stakeholders about format, design, and content. There is never going to be enough time to obtain or create all the data that one might really want to make decisions, but with input from stakeholders and government, it is pretty clear what datasets are most important or essential.
“It should be emphasized that a data viewer or portal is not a management plan. Spatial information is necessary for MSP in that it provides relevant information to inform and support decisions about the spatial and temporal allocation for activities and uses. However, it is not a management plan in and of itself. A management plan will have both spatial and non-spatial aspects, and there will be a great deal of effort paid to determining the compatible or allowable activities in relation to the spatial allocation goals and addressing priorities for implementation of the plan, including how to integrate management across multiple sectors and monitor and enforce new zones or management areas.”
Grover Fugate: A plan needs enough data to make reasonable and meaningful inferences
Editor’s note: Grover Fugate is executive director of the Rhode Island Coastal Resources Management Council which led the development of that state’s Ocean Special Area Management Plan. He can be contacted at gfugate [at] crmc.ri.gov.
“There is often the sense that we always need additional data, but at some point, one needs to draw the line and draft the plan. The intent of the plan, and thus the scale of data collection, has a direct bearing on this issue. If you are at a permitting level with large-scale requirements, you need data critical to these decisions, and this will drive decisions on how much data you need. A plan needs enough data to make reasonable and meaningful inferences, but as managers, we always have to operate in a world where we have incomplete data. It should be noted that data will continue to be developed after the adoption of the plan, so it is essential to have a readily adaptable framework to make changes to the plan.”
Leo de Vrees: Distinguish between ‘need to know’ and ‘nice to know’
Editor’s note: Leo de Vrees is senior advisor for the Rijkswaterstaat Sea and Delta of the Ministry of Infrastructure and the Environment of the Netherlands. He can be contacted at leo.de.vrees [at] rws.nl.
“There is a distinction between data and information. You need to start the process by thinking about the information you need to address policy and management questions, and you need to distinguish between ‘need to know’ and ‘nice to know’ information. Then you move from broad, generic information (e.g., where are Natura 2000 areas located, or where are oil/gas platforms located) to more detailed information (which species are in a particular Natura 2000 area, or is there a helicopter deck on a platform, or is this platform located close to a potential wind farm area). Once you’ve assessed your information needs, you start collecting data based on those needs. Of course, resources also play a role in collecting data. Collecting monitoring data at sea, for example, is quite expensive.
“Also keep in mind that a web atlas/data portal is never a final product because activities at sea continuously change. So information always needs to be updated.”
Coastal atlases around the world
There is no comprehensive listing of ocean and coastal web atlases or data portals, but the roster of members of the International Coastal Atlas Network (ICAN) lists upwards of 50 coastal web atlases from around the world. According to Ned Dwyer, executive director of the EurOcean Foundation and a member of the ICAN steering group, the number of coastal web atlases is continually increasing, but coverage is still very patchy. Dwyer says, “Some areas have many atlases and portals while other areas are not covered at all. In developed countries, there are many atlases covering different scales from international to national to regional and even local. However, in developing countries there are not that many portals. Often this is due to a combined lack of appropriate digital data, resources, and capacity.”
Per Marcia Berman, c-chair of ICAN and program manager for the Comprehensive Coastal Inventory for the Chesapeake Bay based at the Virginia Institute of Marine Science in the US, the total cost of developing a coastal web atlas varies immensely between regions and projects, with major costs consisting of licensing fees (if commercial software is used), hardware, data, and personnel. Berman says, “In the US, we have robust datasets frequently collected with public funds and therefore available to us at no - or very minimal - cost. Unfortunately, this is not the case in many other places around the world where the cost of data can be very high.”
Where coastal web atlases or data portals do exist, limited or unstable internet connectivity can be a very real challenge, according to Lucy Scott, a member of the ICAN steering group who has worked on several digital atlases in the African region, including the African Coastal and Marine Atlas (ACMA). To deal with this, Scott says, “The first version of the ACMA developed in 2007 had a static HTML interface which loaded very quickly. Downloadable data files were provided as zip packages so they could be downloaded when a good connection was available and used offline. Subsequent versions of the ACMA have an interactive GIS interface which is significantly more challenging to use with a poor internet connection, but the software has been optimized to be as data-efficient as possible.”
In addition to these measures, Fernando Félix, project coordinator for the Southeast Pacific Data and Information Network in Support to Integrated Coastal Area Management (SPINCAM), suggests newsletters on coastal-marine issues can be useful to connect marine practitioners in regions of slow or unstable internet connectivity with data relevant to their work, including information not available from an atlas. Newsletters can include, for example, “links to databases or institutions with relevant information on coastal resources, management experiences, academic issues, and lists of experts,” according to Félix.
Marcia Berman can be contacted at marcia [at] vims.edu. Lucy Scott can be contacted at lucy.scott [at] asclme.org. Fernando Félix can be contacted at ffelix [at] cpps-int.org.
Should there be an über atlas?
We posed a question to ICAN steering group member Ned Dwyer about whether it would be better to have fewer, more comprehensive atlases to save resources in creating them. He responded with this perspective:
“Each [atlas] has been developed for a particular reason and probably has a particular audience in mind. I don´t think centralizing or reducing them all to a few atlases is the answer. This can lead to centralization of power and decision making and also lead to slower reaction times and more administratively heavy decision paths. Also from a user perspective, a simple and easy-to-use portal, with a clear and limited set of data and functions, is often preferable to an all singing, all dancing portal that is rich in content and functionality but actually tricky to use.
“Nevertheless, ideally these various atlases should be able to talk to each other. This is why using data standards and implementing interoperability is key. This is something we have been promoting through ICAN since the beginning. Interoperable and standards-compliant atlases will allow easier reuse of metadata and data, so that even though there may be multiple atlases, they can share their data seamlessly. This will avoid problems of having multiple copies of datasets or having datasets getting out of sync with each other. It also means that we can have different ‘views’ of the data in different contexts. So I don´t think we need to limit the number of atlases. We just need to be smarter in how we implement them. I believe everyone can benefit, as it means limited resources can focus on what is unique about a particular atlas and not get stuck reproducing data that already exist elsewhere.
“Another useful tool would be an Atlas of Atlases, which can show you for a particular region what atlases and portals exist for different themes and different spatial scales. In Europe, the European Atlas of the Seas partially addresses this. As well as having a consistent set of data layers for all EU countries, it also identifies the major national atlases for each country. In ICAN we are looking at developing an improved searchable inventory of the Atlases of our different members, showing the regions they cover, the different themes and issues they address, and the development technologies used. This would be a useful resource for atlas developers, as they can find others who may have developed something similar to what a new atlas developer is thinking about.”
Further reading for developing your own ocean and coastal web atlas or data portal
Several key resources and references for marine planners and managers getting started developing their own web atlases /data portals are listed below.
- The International Coastal Atlas Network (ICAN) is a community of practice to share experiences and find common solutions for coastal web atlas development. ICAN develops and provides user and developer guides, handbooks and articles on best practices, information on standards and web services, expertise and technical support directories, education, outreach, and funding opportunities.
- Of particular note, ICAN recently published a Best Practice Guide to Engage your Coastal Wet Atlas User Community.
- The network’s next in-person meeting ICAN 8 workshop: Coastal Web Atlases – Enhancing Ocean Literacy will be held in Santa Marta, Colombia, from September 11-12, 2017. This workshop will explore how a coastal web atlas can contribute to and support ocean literacy initiatives and will examine the role of coastal web atlases in advancing ocean literacy with different audiences. Learn more.
- For a brief overview of challenges and best practices for creating and using data portals (US-oriented), we recommend Creating and Using Data Portals to Support Ocean Planning: Challenges and Best Practices from the Northeast United States and Elsewhere published by SeaPlan in November 2016.
- For a deep dive into coastal web atlases, including in-depth case studies from around the world, we recommend Coastal Informatics: Web Atlas Design and Implementation published by IGI Global in 2011.
- For a shorter overview of coastal web atlases, we recommend “Potentials and limitations of coastal web atlases” published in the Journal of Coastal Conservation in March 2011.