# Simple geometries

The geometry model implemented by the `geobase`

package is based on
Simple Feature Access - Part 1: Common Architecture
published by the
Open Geospatial Consortium (OGC).

The basic primitives are *point*, *line string* (or a polyline) and *polygon*,
and their multi-part representations. A *geometry collection* may contain any
type of other geometry objects.

## π§© Geometry types

Geometry primitive types supported by this package (with samples adapted from the samples of the Wikipedia page about WKT, and compatible also with GeoJSON):

Also multipart geometry classes are supported:

## π§ Building geometry objects

Samples above expect 2D coordinates (x and y coordinates - or longitude and latitude).

When data contains more coordinates, like also z in 3D data, then the `type`

parameter in build methods (for geometries other than `Point`

) must always be
used explicitely to define the coordinate type.

A line string with 3 points (2D coordinates with x and y) from the table above:

In this call there was no need to specify the coordinate type, but the same
example adjusted to contain 3D coordinates (x, y and z) requires explicitely
also the `type`

parameter (here each point has the `z`

value of 5.5):

This sample even extended, a line string with 3D and measured coordinates (x, y,
z and m) is created below (here the `m`

value grows from 3.1 to 3.3):

Geometry objects can be created also from iterables of `Position`

objects
(instances of `Position`

itself, or subtypes `Projected`

and `Geographic`

):

In all geometry classes there are also some other ways to create objects:

- default constructors: creates a geometry object using coordinate arrays
`parse`

: parses a geometry object from text conforming to some text format like GeoJSON or WKT`decode`

: decodes a geometry object from bytes conforming to some binary format like WKB

Alternative ways to construct geometries are shown for 3D lines strings.

All other geometry objects have similar factories too.

## π¦ Calculating bounding boxes

Geometry objects also know how to calculate their minimum bounding boxes.

If bounding boxes are needed frequently it might be more efficient to populate bounding boxes on geometry objects.

When reading external data, itβs possible that a minimum bounding box is included in data already. The last example shows how to use external data for bounding box.

## ποΈ Geometry data model

The following class diagram describes key members of `Point`

, `LineString`

and `Polygon`

geometry classes:

Primitive geometry classes described by the diagram:

`Point`

with a single position represented by`Position`

`LineString`

with a chain of positions (at least two positions) represented by`PositionSeries`

`Polygon`

with an array of linear rings- exactly one
`exterior`

ring represented by`PositionSeries`

- 0 to N
`interior`

rings (holes) with each represented by`PositionSeries`

- exactly one

The `PositionSeries`

class is described in the appendix
about coordinate arrays and
the `SimpleGeometryContent`

interface visible in the diagram in
content interfaces.
The usage of `project()`

method is described in the chapter about
projections.

See also the class diagram about multi and collection geometries below:

For example `MultiLineString`

stores `chains`

of positions for all line strings
as a list of `PositionSeries`

. Itβs also possible to get a mapped iterable of
`LineString`

objects using the `lineStrings`

getter.