This commit includes updates that affects the build, testing, and
deployment of Tile38.
- The root level build.sh has been broken up into multiple scripts
and placed in the "scripts" directory.
- The vendor directory has been updated to follow the Go modules
rules, thus `make` should work on isolated environments. Also
some vendored packages may have been updated to a later
version, if needed.
- The Makefile has been updated to allow for making single
binaries such as `make tile38-server`. There is some scaffolding
during the build process, so from now on all binaries should be
made using make. For example, to run a development version of
the tile38-cli binary, do this:
make tile38-cli && ./tile38-cli
not this:
go run cmd/tile38-cli/main.go
- Travis.CI docker push script has been updated to address a
change to Docker's JSON repo meta output, which in turn fixes
a bug where new Tile38 versions were not being properly pushed
to Docker
The big change is that the GeoJSON package has been completely
rewritten to fix a few of geometry calculation bugs, increase
performance, and to better follow the GeoJSON spec RFC 7946.
GeoJSON updates
- A LineString now requires at least two points.
- All json members, even foreign, now persist with the object.
- The bbox member persists too but is no longer used for geometry
calculations. This is change in behavior. Previously Tile38 would
treat the bbox as the object's physical rectangle.
- Corrections to geometry intersects and within calculations.
Faster spatial queries
- The performance of Point-in-polygon and object intersect operations
are greatly improved for complex polygons and line strings. It went
from O(n) to roughly O(log n).
- The same for all collection types with many children, including
FeatureCollection, GeometryCollection, MultiPoint, MultiLineString,
and MultiPolygon.
Codebase changes
- The pkg directory has been renamed to internal
- The GeoJSON internal package has been moved to a seperate repo at
https://github.com/tidwall/geojson. It's now vendored.
Please look out for higher memory usage for datasets using complex
shapes. A complex shape is one that has 64 or more points. For these
shapes it's expected that there will be increase of least 54 bytes per
point.
tidwall