dorm.contrib.gis¶
Geometric value type and Field subclasses + spatial lookups.
See GIS for recipes.
API¶
dorm.contrib.gis.Geom
dataclass
¶
Pythonic geometry value.
kind is the GeoJSON-style geometry type: "Point",
"Polygon", "LineString", etc. coordinates follows the
same shape rules as GeoJSON — [x, y] for Point, a list of
rings for Polygon, etc. srid is the spatial reference system
identifier (default 4326 = WGS84 long/lat).
The runtime stores the value as Well-Known Text (WKT) when talking to the database — both PostGIS and SpatiaLite accept WKT via standard text adapters and avoid binary protocol drift.
to_wkt() -> str
¶
Render this geometry as Well-Known Text (without the SRID
prefix). Use :meth:to_ewkt for SRID=4326;POINT(...)
encoding accepted by PostGIS' geometry type.
bootstrap_sqlite(connection: Any) -> None
staticmethod
¶
Load mod_spatialite into a SQLite connection so its
spatial functions become available. Idempotent — calling
twice is a no-op.
The extension path defaults to whatever the system provides
as mod_spatialite; on Debian / Ubuntu install
libsqlite3-mod-spatialite.
dorm.contrib.gis.PointField
¶
Bases: GeometryField
dorm.contrib.gis.PolygonField
¶
Bases: GeometryField
dorm.contrib.gis.LineStringField
¶
Bases: GeometryField
dorm.contrib.gis.GeometryField
¶
Bases: Field
Generic geometry column — holds Point / Polygon / LineString.
Backend mapping:
- PostgreSQL:
GEOMETRY(<kind>, <srid>)(PostGIS). - SQLite:
BLOBwith mod_spatialite-managed serialisation. - Other backends:
TEXT(WKT). Functional but not optimised — every spatial query becomes a sequential scan.