A Julia Protocol for Geospatial Data
To support operations or visualization of multiple (but similar) implementations of vector data (across GeoJSON.jl
, LibGEOS.jl
, etc). As a starting point, it will follow the GEO interface [1] in Python (which in turn borrows its design from the GeoJSON specification [2]).
A position can be thought of as a tuple of numbers. There must be at least two elements, and may be more. The order of elements must follow x
, y
, z
order (e.g. easting, northing, altitude for coordinates in a projected coordinate reference system, or longitude, latitude, altitude for coordinates in a geographic coordinate reference system). It requires the following methods:
xcoord(::AbstractPosition)::Float64
ycoord(::AbstractPosition)::Float64
zcoord(::AbstractPosition)::Float64
hasz(::AbstractPosition)::Bool
(false
by default)
Remark: Although the specification allows the representation of up to 3 dimensions, not all algorithms support require all 3 dimensions. Also, if you are working with an arbitrary obj::AbstractPosition
, you should call hasz(obj)
before calling zcoord(obj)
.
Represents vector geometry, and encompasses the following abstract types: AbstractPoint, AbstractMultiPoint, AbstractLineString, AbstractMultiLineString, AbstractMultiPolygon, AbstractPolygon
. It requires the coordinates
method, where
coordinates(::AbstractPoint)
returns a single position.coordinates(::AbstractMultiPoint)
returns a vector of positions.coordinates(::AbstractLineString)
returns a vector of positions.coordinates(::AbstractMultiLineString)
returns a vector of linestrings.coordinates(::AbstractPolygon)
returns a vector of linestrings.coordinates(::AbstractMultiPolygon)
returns a vector of polygons.
Represents a collection of geometries, and requires the geometries
method, which returns a vector of geometries. Is also a subtype of AbstractGeometry
.
Represents a geometry with additional attributes, and requires the following methods
geometry(::AbstractFeature)::AbstractGeometry
returns the corresponding geometryproperties(::AbstractFeature)::Dict{AbstractString,Any}
returns a dictionary of the properties
Optionally, you can also provide the following methods
bbox(::AbstractFeature)::AbstractGeometry
returns the bounding box for that featurecrs(::AbstractFeature)::Dict{AbstractString,Any}
returns the coordinate reference system
If you don't need to provide your own user types, GeoInterface also provides a set of geometries (below), which implements the GEO Interface:
CRS
Position
Geometry <: AbstractGeometry
Point <: AbstractPoint <: AbstractGeometry
MultiPoint <: AbstractMultiPoint <: AbstractGeometry
LineString <: AbstractLineString <: AbstractGeometry
MultiLineString <: AbstractMultiLineString <: AbstractGeometry
Polygon <: AbstractPolygon <: AbstractGeometry
MultiPolygon <: AbstractMultiPolygon <: AbstractGeometry
GeometryCollection <: AbstractGeometryCollection <: AbstractGeometry
Feature <: AbstractFeature
FeatureCollection <: AbstractFeatureCollection
Conceptually,
- an
::AbstractGeometryCollection
maps to aDataArray{::AbstractGeometry}
, and - an
::AbstractFeatureCollection
maps to aDataFrame
, where each row is anAbstractFeature
The design of the types in GeoInterface differs from the GeoJSON specification in the following ways:
- Julia Geometries do not provide a
bbox
andcrs
method. If you wish to provide abbox
orcrs
attribute, wrap the geometry into aFeature
orFeatureCollection
. - Features do not have special fields for
id
,bbox
, andcrs
. These are to be provided (or found) in theproperties
field, under the keysfeatureid
,bbox
, andcrs
respectively (if they exist).
[1]: A Python Protocol for Geospatial Data (gist)
[2]: GeoJSON Specification (website)