Common Mapping Standards

Why Use Data Standards?

Benefits

• Encourage internal and external interoperability
• Data can be leveraged beyond the initial intent for creation
• Increase system transparency
• Reduces design and development time

Obstacles

• Many different kinds of standards
• Can often be complex to architect
• Initial learning curve to get started

Considerations

• Standards should match your system needs
• Publish what standards you are using
• Strive for consistency across enterprise/organization
• Stay up-to-date with the standards you are using

Data Encoding

• OGC Keyhole Markup Language (KML)
  • Schema
• OpenGIS Geography Markup Language (GML)
  • Schema
• OpenLayers
• OGC Network Common Data Form (NetCDF)

Mapping Service Standards

• Web Map Service (WMS)
  • Schema
• Web Feature Service (WFS)
• Web Coverage Service (WCS)
  • Schema
• Catalog Service for the Web (CSW)
  • Best Practices

Benefits and Limitations

• KML
  • Useful for Google Maps and Google Earth as well as desktop GIS
  • Limited to the number of geographic features
• WMS
  • Useful for publishing a graphic map
  • Does not contain any “real” data.  Only a picture of the data.
• WFS
  • Useful for sending data between system (GML encoding)
  • With encoding, the size and complexity of the XML information is expanded
• CSW
  • Useful for publishing a clearinghouse of metadata describing data and services your organization is offering
  • While various metadata standards can be used in CSW, not all of these standards are the same.

Standards Organizations and Resources

• International Standards Organization (ISO)
  • Standards
• Federal Geographic Data Committee (FGDC)
  • Standards
• World Wide Web Consortium (W3C)
  • Standards
• Open Geospatial Consortium
  • Standards
• Open Source Geospatial Foundation (OSGeo)
• Internet Engineering Task Force (IETF)

Data Publishing Considerations

A number of specific criteria and parameters should be considered before determining the type, format, and method for publishing your geospatial and non-geospatial data.  These include:

The “Client”

• Desktop / Thick Client Application
  • Service can be more robust
  • Easy to turn data layers on and off within a single service
  • Can manipulate transparency of each layer
• Web Application / Thin Client
  • Requires an optimized service
  • User will be restricted to the functionality of the application

The End User and Purpose

• Who is the intended user?
  • How will they use the data?
  • Are there specific tools or functionality this data service was created for?
  • What questions will need to be answered by the data?
  • What standards are expected within the data and service?
• Secondary End User
  • Will external users want to utilize this service and build their own mashup application?
  • What standards are expected within the data and service?

End User Expectations

Users expect:

• Optimized services
• Cartographically rendered services
• High-quality data
• Well-maintained services
• Frequent or real-time updates

Data Access and Exchange

What is an Ontology?

An ontology is a representation of knowledge, generally of a particular subject (domain), written with a standardized, structured syntax. An ontology contains concepts (resources), which serve to characterize the domain.

Ontologies and Thesauri References

• Marine Metadata Interoperability

Coastal and Marine Spatial Planning Discovery Vocabularies Workshop

A Joint Woods Hole Oceanographic Institute/ USGS/ NOAA Workshop

• Workshop Report (February 2011)

Service Type

The type of service you create will depend largely on the type of server you have implemented.  If you rely on ESRI products, you will most likely create an ArcGIS Server service.  If you rely on Open Source technology, WMS or KML are good options.

Service Types include:

• ArcGIS Server Services
• Web Map Service (WMS)
• Keyhole Markup Language (KML)
• Web Feature Service (WFS)

Data Type, Size and Performance

There are a number of factors specific to the spatial data that must be considered before creating a service.  These include:

• Data type – will Raster or Vector data be added to the service?
• Complexity – as complexity increases performance often decreases
• Scale and Projection – determining the appropriate scale and projection will impact end user performance and usability
• Dynamic vs Cached service
  • Will the service be used as an operational layer or as a base layer?  Operational layers tend to be dynamic while base maps are usually cached services.
  • Complex and large vector and raster dataset lend themselves to being cached as draw times of voluminous data will take longer than the user wants to wait.
  • If data require frequent updates, dynamic services are often optimal due to the the time and server requirement to rebuild and cache the service with each update.

Projections

• Web Mercator
  • Considered the industry norm.
  • Has been adopted by Microsoft Bing, Google and ESRI
  • Based on a true spheroid so measure and area calculations will be inaccurate.
  • Others:
    • Equal Area / Equidistant
    • State / Local
    • Custom

Note: If you decide to use a projection other than Web Mercator, a custom-tiled base map will need to be created.  Other options include using dynamic layers are most basemap services are in Web Mercator and cannot be reprojected.

Symbology

When symbolizing data for a service, the following should be considered:

• Simple Symbology – More complex symbology requires longer processing time by the server.
• Annotation or Dynamic Labels –
  • Determine whether labels will be used.  If so, will they need to be dynamic?
  • Annotation layers will result in better performance but will not always be the best solution.
  • Base Map Cartography
    • Consider the base map that will be used when symbolizing; what looks good on one base map may not look good on another.
    • Scale Dependency
      • Perhaps the layer does not need to be visible at all scales.  The fewest layers being drawn at the same time results in better performance.