The Buffer tool creates buffer polygons around input features to a specified distance.
The buffer routine traverses each of the input feature's vertices and creates buffer offsets. Output buffer features are created from those offsets.
Create offsets around a line
The following images show the progression of creating offsets around a line:
- Input line feature
- Offsets created around the input line feature
- Buffer derived from the offsets
Buffer distance
The buffer distance parameter value can be a fixed value or a field containing numeric values.
Example 1: Fixed distance
This example shows the buffer of a line feature class with the following parameter options:
- Distance [value or field]—A distance of 20
- Side Type—Full
- End Type—Flat
- Dissolve Type—Dissolve all output features into a single feature
Because the buffer distance is a constant, all features are buffered to the same width.
Example 2: Distance from field
This example shows the buffer of a line feature class with the following parameter options:
- Distance [value or field]—A numeric field with values of 10, 20, and 30
- Side Type—Full
- End Type—Flat
- Dissolve Type—Dissolve all output features into a single feature
Because the buffer distances are dependent on the field values, various buffer widths can be applied in the same operation.
Dissolve line buffers with a side type
The differences between dissolve options with a side type buffer are described below.
- Dissolve all output features into a single feature—The input line features are first connected in a pseudo network as much as possible. The longest runs of connected line features in this network are then buffered on one side. Individual features are only buffered if they do not connect to any other features in the input. This works well for smaller distances (which are most often used for buffering lines representing roads and streams). In some cases, larger distances will result in output buffers that at first glance do not look correct, but larger buffers can cause an extreme amount of overlap that cannot be handled without post-tool interaction to make sense of the output.
The one-sided buffer will attempt to keep resulting buffer output to the correct side even when output buffers interact with the incorrect side of other input line features.
- No Dissolve—One-sided buffer buffers the input lines individually. No considerations are made for the interaction of resultant buffers in the output.
There are cases when using the Dissolve all output features into a single feature option, that due to the complexity of the input features with the specified buffer distance, the creation of a one-sided buffer may fail internally. When this happens, the buffer is reattempted with slightly different values. This process tends to be less efficient and there may be missing buffer areas due to the inability to determine how to maintain the buffer on the specified side. The resulting output buffer may cross other input features to the incorrect side. Input lines with spirals, loops, and inconsistent line segment direction often cause these issues with a buffer side type when using the Dissolve all output features into a single feature option.
Euclidean and geodesic buffering
An important feature of the Buffer tool is the Method parameter, which specifies how buffers are created. There are two basic methods for constructing buffers, Euclidean (planar), and geodesic.
- Euclidean buffers measure distance in a two-dimensional
Cartesian plane in which straight-line or Euclidean distances are
calculated between two points on a flat surface (the Cartesian plane). Euclidean
buffers are best when
analyzing distances around features in a projected coordinate system, which are concentrated in a
relatively small area (such as one UTM zone).
In a projected coordinate system, there are areas in the projection where distances, areas, and the shape of features are distorted; this is a fact of using projected coordinate systems. For example, if using a State Plane or UTM projected coordinate system, features are more accurate near the origin of the projection (the center of the state, or the UTM zone), but become more distorted when moving away from the origin. Similarly, if a World projected coordinate system is used, distortion is often minimal in one area, but significant in another (for the Mercator World projection, distortion is minimal near the equator but significant near the poles). For a dataset that has features in both low and high distortion areas, Euclidean buffers will be more accurate in the low distortion areas and less accurate in the high distortion areas.
- Geodesic buffers account for the curvature of the spheroid and correctly handle data near and across the dateline and poles. Geodesic buffers are best if the data covers a large geographic extent or the coordinate system of the inputs is unsuitable for distance calculations. Geodesic buffers may appear unusual on a flat map, but when displayed on a globe, they look correct.
Choose geodesic buffers if the data covers a large geographic extent or the coordinate system of the inputs is unsuitable for distance calculations.
The Method parameter has the following options:
- Planar—The buffering method will be based on the coordinate system of the Input Features parameter value. This is the default.
- If the input features have a projected coordinate system, Euclidean buffers will be created.
- If the input features have a geographic coordinate system and the Buffer Distance value is in linear units (meters, feet, and so forth, as opposed to angular units such as degrees), geodesic buffers will be created.
- Geodesic—A shape-preserving geodesic buffer will be created regardless of the input coordinate system. It is not assumed that the lines connecting vertices are geodesic curves. Instead, the features in the spatial reference of the input feature class are buffered to create buffers that more closely represent the input features shape. If you are concerned about the shape of the buffers and how closely their shape matches the original input features, it is recommended that you use this option, particularly when the input data is in a geographic coordinate system. In some cases, this may take more time than the geodesic buffer created using the Planar option, but the result is a buffer that more accurately matches the shape of the input feature.
Geodesic buffer example
This example compares 1,000-kilometer geodesic and Euclidean buffers of a number of select world cities. Geodesic buffers were generated by buffering a point feature class with a geographic coordinate system, and Euclidean buffers were generated by buffering a point feature class with a projected coordinate system (in both the projected and unprojected datasets, the points represent the same cities).
When working with a dataset in one of the common projected coordinate systems for the whole world, such as Mercator, projection distortion may be minimal near the equator but significant near the poles. This means that for a Mercator projected dataset, distance measurements and buffer offsets should be quite accurate near the equator and less accurate away from the equator.
The first graphic shows the input point locations. The equator and prime meridian are shown for reference. Both graphics are displayed in the Mercator (World) projection.
In the second graphic, the points near the equator have geodesic and Euclidean buffers that are coincident. For points near the equator, the Mercator projection produces accurate distance measurements. However, the buffers of points far from the equator show more distance distortion, as their Euclidean buffers are much smaller than the geodesic buffers. This occurs with the Mercator projection because at the poles, areas are stretched (land masses close to the poles, such as Greenland and Antarctica have enormous areas in comparison with the land masses close to the equator). All 1,000-kilometer Euclidean buffers are the same size since the Euclidean buffer routine assumes that map distances are the same everywhere in the projection (1,000 kilometers in Brazil is the same as 1,000 kilometers in central Russia). This is not true since away from the equator, the projection's distances become more and more distorted. With any type of analysis of distance on a global scale, use geodesic buffers, as they will be accurate in all areas while Euclidean buffers will not be accurate in high distortion areas.
Note:
Displaying geodesic and Euclidean buffers on a globe will reveal that the geodesic buffers are more accurate.
These are the same 1,000-kilometer Euclidean and geodesic buffers that were created for the example above. When displayed on a globe, each of the Euclidean buffers is a different size despite the same buffer distance being used for each (the buffer in Alaska appears smaller than the buffer in Brazil). This is a result of the buffers being created with the false assumption that all of the map distances were the same from one location to another. Contrarily, each of the geodesic buffers is a correct uniform size when displayed on the globe; these geodesic buffers are correct because they were not influenced by distortion from a projected coordinate system.
Additional information about geodesic buffering
The vertices of input polyline and polygon features are assumed to be connected with geodesic lines (a geodesic line is the shortest path between two points on an ellipsoid). If the intended path between vertices is not meant to follow a geodesic, you must explicitly densify the inputs. Geometries can be densified using the Densify tool. Use the Geodesic method to get buffers that more closely match the shape of the input features (see below).
Geodesic buffers involve more complicated calculations than planar buffers and may take longer to complete. How much longer primarily depends on the number and density of vertices in a feature. As the number and density of vertices in a feature increase, so does the amount of time necessary to create the buffer feature.
Shape-preserving geodesic buffers
When buffering lines or polygons, the Geodesic method produces geodesic buffers by buffering the feature in the spatial reference of the input feature class to ensure the buffers follow the intended geodesic shape of the input features.
After using the Geodesic method, you may find little difference in the output buffers. This is because the shape-preserving geodesic method can be seen most obviously when the input features do not have an appropriate vertex density for the buffer creation process to maintain their shape (typically coarse, inaccurate features). It is important to know the input data before deciding to use the Geodesic method.
For example, the following image is a coarse feature with few vertices (vertices are only at the bends in the line) covering a large portion of the globe:
If you buffer this line by 500 kilometers using the Planar method, the following is the output buffer feature (pink):
This may have been unexpected, but as mentioned earlier, when using the Planar method (when creating geodesic buffers), it is assumed that the vertices of the input polyline feature are connected with geodesic lines, as seen in purple below:
Looking at the input features (blue), the resultant geodesic lines (purple), and the geodesic buffer (pink) together for this case, the output now makes sense:
This is probably not what you want.
When using the Geodesic method, it is not assumed that the lines connecting vertices are connected by geodesic curves. The resulting geodesic buffer using the Geodesic method is shown below in green:
You now have a geodesic buffer that more closely maintains the shape of the input feature.
BUFF_DIST field
The values in the BUFF_DIST field of the output feature class are in the linear unit of the input's coordinate system. For example, if a 50-meter buffer distance is specified in the tool, but the input has a coordinate system that uses feet as the linear unit, 50 meters will be converted to feet in the output BUFF_DIST field. The following are exceptions to this:
- If the input has a geographic coordinate system and the buffer distance is specified in a linear unit, such as kilometers or miles, the values in the BUFF_DIST field will be in meters.
- If the spatial reference of the input is unknown, no conversion is applied, so the value in the BUFF_DIST field is the value provided.
The tables below summarize the scenarios when the BUFF_DIST unit conversion is and is not performed.
| Input features coordinate system | Buffer distance units | Unit conversion |
|---|---|---|
Geographic | Angular or linear | Converted to meters |
Projected | Angular | Converted to input coordinate system unit |
Projected | Linear | Converted to input coordinate system unit |
Geographic or Projected | Unknown | Assumed to be input coordinate system unit |
Unknown | Angular or Linear | No conversion |
| Input features coordinate system | Buffer distance units | Unit conversion |
|---|---|---|
Geographic | Angular or linear | Converted to meters |
Projected | Angular | Converted to meters |
Projected | Linear | Converted to meters |
Geographic or Projected | Unknown | Assumed to be input coordinate system unit |
Unknown | Angular or Linear | No conversion |
Note:
BUFF_DIST value units are always those of the Output Coordinate System environment when it is set.