texel

command module
v0.0.9 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Aug 15, 2024 License: MIT Imports: 17 Imported by: 0

README

texel

GitHub license GitHub release Go Report Card Docker Pulls

Preprocesses a GeoPackage for creating valid (more info below) vector tiles from it. (And in the future probably will also create the actual vector tiles.)

The (MULTI)POLYGON geometries in a geopackage are snapped to the grid cq matrix matching the one of the intended (internal pixel grid of the) vector tiles. While ensuring that no (new) intersections arise from this, by adding points to lines that skim along other vertices. An additional benefit is that the vector tile generator needs to process fewer data (snapping combines some points into one) and does not need any additional processing aside from clipping and converting to the internal tile pixel grid.

"Valid" geometries

Our definition of valid is in the context of vector tiles and is more loose than the OGC rules. Mainly in comparison to the OGC rules, we allow:

  • Overlap (not intersection)
  • Linear rings or line strings with less than 3 vertices (effectively becoming lines or points)

With the drawing/rendering of vector tiles in mind, these invalidities do not cause a problem. On the contrary, they introduce possibilities. E.g. when zooming out, you would like to still see a lake as a point and a river as a line. (The tool that this codebase is forked from, sieve would filter those out.) Also when zooming out on a lake with an attached river, you would like to keep seeing that river as a line, but still as part of the original geometry/feature including all attributes and styling.

Examples

Not adding extra points could create intersections:

snapped with vs without extra point

Close thin polygons can turn into lines:

before.png after-overlapping-lines.png

Notes

  • It will take a Geopackage and writes a new Geopackage with all the (MULTI)POLYGON tables preprocessed.
    • All other spatial tables are 'untouched' and copied as-is.
    • Other non-spatial tables are not copied to the new geopackage.
  • ⚠ Spatialite lib is mandatory for running this application. This lib is needed for creating the RTree triggers on the spatial tables for updating/maintaining the RTree.

Usage

./texel -s=[source GPKG] -t=[target GPKG] \
   -tms=[tile matrix set for filtering] -z=[tile matrix ids] \
   -p=[pagesize for writing to target GPKG] -o=[overwrite target GPKG] \
   -pl=[keep points and lines]

./texel --help
Docker
docker run \
  --name texel \
  --rm \
  -u $(id -u):$(id -g) \
  -v `pwd`/example:/example \
  pdok/texel \
    -s=./example/example.gpkg \
    -t=./example/example-processed.gpkg \
    -tms="NetherlandsRDNewQuad" \
    -z '[5]' \
    -p=10 \
    -o=false \
    -pl=true

Build

go test ./... -covermode=atomic

go build .
Docker
docker build -t pdok/texel .

References

  • sieve is the predecessor of this tool and much of its processing codebase is reused as boilerplate.

Documentation

The Go Gopher

There is no documentation for this package.

Directories

Path Synopsis
Package intgeom resembles github.com/go-spatial/geom but uses int64s internally to avoid floating point errors when performing arithmetic with the coords.
Package intgeom resembles github.com/go-spatial/geom but uses int64s internally to avoid floating point errors when performing arithmetic with the coords.
Package processing takes care of the logistics around reading and writing to a Target.
Package processing takes care of the logistics around reading and writing to a Target.
Package tms20 implements the OGC Tile Matrix Set standard (v2.0) as a slippy.Grid See https://www.ogc.org/standard/tms/
Package tms20 implements the OGC Tile Matrix Set standard (v2.0) as a slippy.Grid See https://www.ogc.org/standard/tms/

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL