Key Geospatial Terminology Cheatsheet

Background

More applications leverage geospatial technologies than it may appear. Some simply store addresses while others leverage location data provided by mobile devices, embedded in content such as images, or derived from IP addresses. As a company with expertise in geospatial technologies and solutions for commercial companies, federal, state, and local government, we find it helpful for customers, managers, engineers, designers, and scientists to be familiar with the following geospatial terms to be able to collaborate and communicate more effectively.

Terms

• Feature: Think of a feature as a specific item on the map. For example, the hospital closest to your house is a feature on the map. Every feature has a set of attributes (a.k.a properties) and a geometry. The attributes could be information like the number of beds, helipads, and specialties of the hospital. Unlike a hospital which may be represented as Point geometry on the map, a road is represented by a line, while a park is best represented by a polygon.

• Geometry Type: Every feature has a geometry associated with it which can be rendered on a map, or geometry operations can be performed on it to answer certain questions. For example, one can query which homes Intersect with a given Area of Interest bounding box. Similarly, a query could ask which firetrucks are within 10 miles of a fire. Geometry Types include Point, Line, Polygon, Multi-Point, Multi-Line, and Multi-Polygon. It is often more useful to use Multi-* geometry types instead of the basic type. Take the state of Hawaii for example. It is one state which has a polygon for each island but if you were to click on Hawaii on the map, all the polygons should, for example, be highlighted.

• FeatureType: Think of a feature type (also known as FeatureClass) as the table in a database that has a row for each feature. It is a list of attribute columns as well as a geometry column. For example, a Hospital FeatureType has a set of columns to capture the attributes (e.g. number of beds and helipads) as well as a Geometry Column of type Point.

• Style: Before you can render a feature on a map, you need a style that describes how a feature of that FeatureType should be rendered. For example, highways may be red lines that are 6 pixels wide with a 1-pixel black border. But when you zoom way out, they stop getting rendered. Mapbox introduced a CSS-like styling scheme which is much nicer than the Styles Layer Descriptor (SLD) which is an XML-based Open Geospatial Consortium (OGC) standard used by GeoServer.

• Layer: A layer is just a FeatureType + Style. For example, all the hospitals with style information to render them, for example, as a red cross on your map.

• Vector Layers: Everything we mentioned so far were Vector data because features have a geometry in the form of vector data (points/lines/polygons with coordinates). The typical Google map you are used to seeing is a rendering of vector data.

• Raster Layers: Raster layers are pixels as opposed to vector data. For example, the satellite view in google maps is a raster layer. Rasters may be imagery collected by satellites, or pixels generated by performing some computations on raster or even vector data. For example, Digital Elevation Model (DEM) is a raster layer where each pixel is the elevation of the terrain at that spot.

• Tiles: Tiles are referred to geospatial data that have been chopped up by axis-aligned bounding boxes. Remember seeing google maps show up in squares as you zoomed in and out around 2010? Each of those images was a tile. Think of a hierarchy where the entire map at zoom level 0 is represented by a single tile 0/0/0.png but every time you zoom in one more level, each tile is broken down into 4 tiles each with more details. For example, the previous tile is broken into 1/0/0.png, 1/1/0.png, 1/1/1.png, and 1/0/1.png. As you can see, can be retrieved using an endpoint like this my-tile-service.com/zoom/x/y. Zoom level 0 has only 1 tile, zoom level 1, has 4 tiles, and zoom level 3 has 16 tiles and the number of tiles at each zoom level grows exponentially as you zoom in. Since each tile (regardless of zoom level) has a unique bounding box, instead of using zoom, x, y, the unique tile can be retrieved using its specific bounding box my-tile-service.com/?bbox=13.235732,14.761452,70.239879,78.123132.

• OGC Standards: The Open Geospatial Consortium is an international voluntary consensus standards organization for geospatial content and location-based services, sensor web and Internet of Things, GIS data processing and data sharing. For example, they define the Web Map Service, Web Feature Service, Web Coverage Service, Web Processing Service, and many other standards leveraged and implemented by geospatial technologies.

• WMS (Web Map Service): It is an OGC standard web service that returns a rendered image (or map). WMS takes a bounding box and returns an image the size of the bounding box you requested with the layers you want to include in the image, with the specified style. Here is a GetMap Request which gives the server all the info about what it wants back. Click the link, see the URL parameters, and change the WIDTH=512 parameter to 1024 and see what happens. You might think, it would be hard to generate the URLs, but if you use a client library like Leaflet, OpenLayers, or MapBoxGL it will generate those and fetch the map tiles behind the scenes. Note that WMS can be used to retrieve rendered images from vector data or raster data such as satellite imagery depending on the type of layers.

• WFS (Web Feature Service): Unlike WMS which is meant to retrieve images, WFS is an OGC standard for retrieving the underlying Feature (which has attributes and geometry) to the browser/client. If you use WFS to get the United States feature, it will likely have a large list of coordinates that define the United States polygon in all its detail. WMS, on the other hand, would just return an image that has the United States feature rendered in it.

• WCS (Web Coverage Service): It is an OGC standard service meant to retrieve the “data” in a raster as opposed to a rendered version of a raster with styles applied to it. You may have a Digital Elevation Model (DEM) raster where each pixel is the elevation corresponding to a 50x50 meter square. You can use WMS to make sure all elevation above, say, 14k feet is colored red and returned as a map layer for visualization purposes only. But if you want to get the underlying data as a table of elevations per pixel, you have to use WCS. WMS is used to retrieve a map as a rendered image, while WFS and WCS get the underlying data.

• WPS (Web Processing Service): This service can be used to execute a process on vector or raster data. For example, you can have a Web Processing Service that will take a polygon and buffer it by 10 meters. Another service may take a massive layer of points to find which ones are within a polygon.

• Vector Tiles: Vector tiles are a way of serving and rendering vector data as tiles. The underlying idea is that instead of using vector data on the server side to render map tiles as rasters, chop up the vector data corresponding to each tile, send that tile of vector data to the client side, then render the map in the browser. The advantages of Vector Tiles are:
  • All the vector data needed to render a beautiful base map for the entire, say, USA for zoom levels 0-18 is much smaller than the amount of storage you would need to have, say, 256x256 pixel tile for all the zoom levels for the entire US. Think about how many raster tiles you’d need to be able to be zoomed into the neighborhood level for all of the US. Many many of the tiles would be completely blank with no interesting features in them. Vector tiles would waste no resources on these tiles.
  • Because the rendering happens on the client side and the features and their geometries are in the browser, vector tiles offer a level of interactivity that is not possible with solutions where everything is rendered on the server side. For example, as your mouse hovers across the map, the feature you are hovering over can be highlighted and animated to dim down over a couple of seconds as your mouse moves off of it.
  • They can easily be used to serve up vector data to render a beautiful map directly from Amazon S3 or local file folders without needing to run any server!

• Open Street Map (OSM): Check it out www.openstreetmap.org. The map does not look as pretty as google maps or apple maps, but the data behind it are 100% open. You can download the vector data for the entire planet from OSM and use it for anything you want. The vector data Google, Microsoft, etc have are proprietary. You can not get the underlying data. Note that if you live in a new neighborhood that doesn’t show up in google maps yet, you can go to OSM’s web-based editor (or their desktop editor), and draw in your street. It will show up on Google, Bing, Apple, etc shortly after as they all ingest OSM data. If you have edits that need to be made to a map, you always want to add it to OSM, not proprietary providers so that others can freely access and use your contributions as well. When disasters happen, or when new camps, cities, etc need to be mapped, “map parties” or osm communities gather to help draw in the vector data. Note that when disaster strikes, the roads, properties, etc can completely change or be washed away and disaster relief groups, governments, etc need updated maps to route and plan.

• Client Mapping Libraries: JavaScript libraries such as Leaflet, OpenLayers, and MapBoxGL are used to embed a map in a web page. These libraries allow you to add vector or raster layers from a variety of sources. These libraries support the variety of standards and conventions used for transferring geospatial vector and raster data over HTTP. For example, they all support WMS for map tiles (and even vector tiles), WFS for feature data, GeoJSON, COG, and more.
  • Here is an example of a MapBox map
  • Here is an example of an OpenLayers map
  • Here is an example of a Leaflet map

• Geospatial Servers: Geospatial data (vector and raster) can be served up to be consumed by client mapping libraries. Common geospatial servers include GeoServer, ESRI Server, QGIS Server, Mapnik, MapServer, MapProxy, Tegola, etc. Alternatively, geospatial data can be served up using AWS S3 without involving dedicated geospatial servers as well. For example, COG (Cloud Optimized GeoTiff) files can be stored in S3 and the mapping libraries that support the file format will only retrieve the parts of the raster that needs to be displayed based on the user’s viewport. Vector Tiles can also be pre-generated and stored in S3 and the maps get rendered in the client’s browser.

• Cloud Optimized GeoTiffs (COG): A COG is a GeoTIFF that has been optimized to be served up through cloud storage such as S3 as opposed to a geospatial server. GeoTiff is a tiff that corresponds to a specific area on earth hence “Geo”. When you add it to a map, it shows up over a specific part of the world, for example, a specific city or neighborhood. A COG file can be a single file many gigabytes in size but because of its design, only the parts being viewed on a map by a user can be extracted and sent to the client. This is as opposed to waiting for a large file to be downloaded by the client before it can be viewed.

• Common Geospatial Formats: There are numerous file formats
  • Vector
    • GeoJSON: a JSON format that has a standardized way of storing location and projection information
    • Shapefile: one of the oldest geospatial file formats developed by ESRI
    • KML: this is the Keyhole Markup Language which is the file format used by Google Earth
    • GeoPackage / MBTiles / SQLite: a file-based data store that can store vector and raster files
    • File geodatabase: A file geodatabase is specific to ESRI products and is a collection of files in a folder on disk that can store, query, and manage both spatial and non-spatial data.
  • Raster
    • GeoTiff
    • COG: Cloud Optimized GeoTiff
    • GeoPDF: A pdf file that corresponds to a specific part of the world
    • GeoPackage / MBTiles / SQLite: a file-based data store that can store vector and raster files
  • Geospatial Databases
    • PostGIS extention makes Postgres able to understand geospatial format and use SQL to perform geospatial queries (e.g. which features are in this boundingbox)
    • SpatiaLite extention makes SQlite a geospatial DB
    • Oracle Spatial
    • ArcSDE is an ESRI geospatial database
    • ElasticSearch supports GeoHash which can be used to perform some geospatial queries.

• GDAL: Is an open source translator library for raster and vector geospatial data formats that is released under an MIT style Open Source License by the Open Source Geospatial Foundation. As a library, it presents a single raster abstract data model and single vector abstract data model to the calling application for all supported formats. It also comes with a variety of useful command line utilities for data translation and processing. Essentially all geospatial servers and desktop clients leverage GDAL under the hood. It is primarily implemented in C/C++ and has wrappers for Python, Java, etc. Take a look at the GDAL GitHub Repo.

• Geocoding: Geocoding is the process of converting a street address to a coordinate on a map. You may use the coordinate to place markers on a map, center the map on the coordinate, or perform analytics. Reverse geocoding is the process of converting geographic coordinates into a human-readable address. There are many geocoders each with their own advantages and disadvantages. Here is a short list:
  • Pelis
  • ESRI Geocoder
  • Google Maps Service
  • Mapbox Geocoder
  • QGIS Geocoding Plugin
  • PostGIS Plugin

• Imagery: The actual imagery of Earth can be collected using satellites, airplanes, and drones. You have seen such imagery on google maps when you switch to the “Satellite” view. Before collected imagery can be displayed on a map, it has to be processed. For example, the images may have been collected at different times, days, or months, parts of the imagery might have been under cloud cover, and different sensors (satellite/plane/cameras) might have been used all of which can result in a non-uniform dataset. Additionally, each lens and sensor type warps the image differently. The images need to be processed to select ones that have minimal cloud cover and then orthorectified to remove the warp caused by the sensors and color-matched.

• Common Map Projections and Coordinate Systems: The earth is 3D but we usually view and manipulate maps in 2D. There are numerous ways to take a spheroid and flatten it on a 2D surface each of which can be described by a mathematical equation. Each map projection has its strengths and weaknesses as they distort or preserve the area, shape, direction, distance, and/or scale of map features differently. Depending on what you need to compute or do, you may need to use different projections. In fact, even each state in the US has its own projection which is designed to be a better fit for the particular part of the imperfect globe it is on. Even though there are many dozens of projects, the following are critical to know:
  • Geographic Coordinate System: EPSG:4326 (WGS 84): Information in 3D applications like Google Earth are stored in this format which is the typical Longitude, Latitude coordinates expressed as degrees. The Washington Monument is at: -77.035246, 38.889460. Note that the coordinate is degrees from 0, 0 which is were the Equator and Prime Meridian intersect off of the coast of africa.
  • Projected Coordinate System: EPSG:3857 (Web Mercator) / EPSG:900913 (Google Maps): The information displayed on a flattened map like Google Maps or OpenStreetMap is displayed in this format. The Washington Monument is at: -8575524.353985, 4705849.975818. Note that the coordinate is in meters from 0, 0.