- Deprecation: Move
jts/transform-geom
,jts/get-srid
,jts/set-srid
,jts/pm
,jts/default-srid
, andjts/gf-wgs84
togeo.crs
, leaving aliases ingeo.jts
during deprecation. - Deprecation: Deprecate
jts/gf
in favor ofcrs/get-geometry-factory
, leaving alias ingeo.jts
during deprecation. - Deprecation: Deprecate
jts/get-factory
in favor ofcrs/get-geometry-factory
, leaving alias ingeo.jts
during deprecation. - Deprecation: Deprecate
jts/polygons
in favor ofjts/geometries
, leaving alias in place during deprecation. - Bump
geohash
to 1.4.0, which can use bounding boxes over the meridian - For development, bump
lein-midje
to 3.2.2 andcheshire
to 5.10.0, removing extrajackson
dependencies - Bump
h3
to 3.6.3 - Remove singularity error with
distance
by using spheroidalspatial4j
Vincenty calculation when input point is at a pole, but otherwise using thegeohash
ellipsoidal Vincenty calculation. - Modify
set-srid
to use.createGeometry
instead of.setSRID
, improving passthrough of projections within geometries and reducing need to manually set projections after operations - Add
get-geometry-factory
toTransformable
, and extendTransformable
toGeometry
andGeometryFactory
- Add
transform-helper
andcreate-transform
toTransformable
, and extendTransformable
toCoordinateTransform
- Allow
transform-geom
to acceptGeometryFactory
as a second argument, passingtransform-geom
to protocol-basedtransform-helper
to improve dispatch - Allow
to-jts
to accept all of the argument arities oftransform-geom
- Add
get-parameters
andget-parameter-string
functions togeo.crs
- Bump
jts2geojson
to 0.14.3, which usesjackson
2.10
- Breaking change: switch upstream
proj4j
to use[org.locationtech.proj4j/proj4j "1.1.0"]
, changing namespace fromorg.osgeo.proj4j
toorg.locationtech.proj4j
- Breaking change: rename
proj4-string?
toproj4-str?
, to maintain naming consistency in the API - Breaking change: remove
jts-earth
fromgeo.spatial
, and replace all uses of deprecatedspatial4j
functions using thatJtsShapeFactory
with functions using theSpatialContext
earth
- Allow
transform-geom
to use externally createdproj4j
CoordinateTransform
objects geo.io
readers and writers are now thread-safe- Add
h3-line
function to H3 protocol, which returns the line of indexes between two cells - Add
h3-to-center-child
function to H3 protocol, which returns a center child at a given resolution - Add
get-res-0-indexes
function for H3, which returns a collection of all indexes at resolution 0 - Add
get-pentagon-indexes
function for H3, which returns all topologically pentagonal cells at a given resolution - Add
get-faces
function for H3, which returns the icosahedron faces intersected by a cell, represented by integers 0-19. - Add
line-segment
,multi-point
,multi-linestring
, andmulti-linestring-wkt
functions togeo.jts
- Add testing support for OpenJDK 8, OpenJDK 11, OpenJDK 13, OpenJ9 alongside HotSpot, and Clojure 1.10
- Fix reflection on geometry creation functions in the
jts
namespace - Bump
h3
to 3.6.0, enabling support for functions described above - Bump other core dependencies to keep up with upstream changes:
jts2geojson
to 0.14.2, andjts
to 1.16.1 - Bump internal dependencies for testing and documentation:
midje
to 1.9.9,criterium
to 0.4.5,cheshire
to 5.9.0, andlein-codox
to 0.10.7 - Remove
noggit
from dependencies, now that it is no longer used - Add
deps.edn
based onproject.clj
- Fix reflection on functions in the
crs
namespace - Bump JTS to 1.16.0, with support for XYZM coordinates
- Bump H3 to 3.1.0, with support for a new
h3-distance
function - Bump internal dependencies
New namespace geo.h3
for interacing with Uber's H3 tiling library
This namespace contains a variety of functions for interoperating with H3 via Uber's H3 Java Bindings. Some highlights include these functions implemented for H3 Cells expressed as either Longs or Strings:
(Via protocol geo.h3/H3Index
)
This protocol is implemented for String
and Long
which are the 2 ways of representing an H3 cell.
to-string
to-long
h3->pt
get-resolution
k-ring
k-ring-distances
to-jts
edge
edge-origin
edge-destination
edges
edge-boundary
pentagon?
is-valid?
neighbors?
Via protocol geo.h3/Polygonal
This protocol includes interfaces to H3's Polyfill functionality for tiling a polygon with H3 cells.
It is implemented for ch.hsr.geohash.GeoHash
, org.locationtech.spatial4j.shape.impl.RectangleImpl
, org.locationtech.jts.geom.Polygon
, org.locationtech.jts.geom.LinearRing
, and org.locationtech.jts.geom.MultiPolygon
.
to-polygon
polyfill
polyfill-address
Additional H3 Functions
compact
uncompact
multi-polygon
Additionally, we've added the H3 GeoCoord
class to geo
's Shapelike
and Point
protocols, so they can interoperate with all of the existing spatial types.
See the full API docs for more detailed information.
- Update to new version of JTS hosted by LocationTech org (https://github.com/locationtech/jts and https://mvnrepository.com/artifact/org.locationtech.jts/jts-core/1.15.0)
Note while this change is relatively minor with regard to the outward API for factual/geo, it is considered a major version upgrade because any of the JTS types returned by this library will have moved from the com.vividsolutions
namespace to org.locationtech
. So users of this library may need to update any type-specific code or imports accordingly.
Several new functions have been added to the geo.jts
namespace to deal with CRS projections.
geo.jts
operations will default to SRID 4326, but will respect a geometry's existing SRID if setgeo.jts/transform-geom
to convert a JTS Geometry to an alternate CRS.geo.jts/get-srid
to check the SRID of a JTS Geometrygeo.jts/set-srid
to check the SRID of a JTS Geometrygeo.jts
functionslinear-ring
,polygon-wkt
, andmulti-polygon-wkt
now accept optionalsrid
arguments for constructing new geometries in the desired SRIDgeo.spatial/to-jts
NewShapelike
protocol function for convertingShapelike
s to JTS geometries. Accepts an optional SRID and defaults to 4326
See geo.crs
for some helpers around checking and manipulating CRS reference IDs.
geo.io/read-geojson
Can now read GeoJSON Features and FeatureCollections. Note that the interface of this has changed somewhat to accommodate the different structures of GeoJSON Geometries, Features, and FeatureCollections.read-geojson
will always return a sequence of Feature maps containing:geometry
and:properties
keys- Use
geo.io/parse-geojson
To access the raw GeoJSON entity (Geometry, Feature, or FeatureCollection) if needed - Use
geo.io/to-geojson-feature-collection
orgeo.io/to-geojson-feature
to construct the appropriate GeoJSON from a map containing{:properties {...} :geometry <JTS Geom>}
geo.spatial/rand-point-in-radius
for getting a random point within a given radius of a given center pointgeo.spatial/resegment
for partitioning JTS LineStrings into segments of a given max length
geo.geohash/geohashes-intersecting
has been optimized significantly for tiling large geometries with small geohash levels.
- Minor perf improvement from removing a reflection call in our JTSShapeFactoryUsage
- Added new spatial function for splitting JTS linestrings into sub-strings based on a desired maximum segment length
- Added JTS functions for working with linestrings more conveniently
- Update dependencies, including JTS to 1.13 and Spatial4J to 0.6
- Add new
geo.io
namespace with functions for reading and writing common geo formats - Fix intersecting-geohashes edge cases around dateline and origin-crossing geometries