outdooractive / gis-tools Goto Github PK

Add var tileCover: [MapTile] to GeoJson

From the specification: https://tools.ietf.org/html/rfc7946

3.1.9. Antimeridian Cutting

In representing Features that cross the antimeridian,
interoperability is improved by modifying their geometry.  Any
geometry that crosses the antimeridian SHOULD be represented by
cutting it in two such that neither part's representation crosses the
antimeridian.

For example, a line extending from 45 degrees N, 170 degrees E across
the antimeridian to 45 degrees N, 170 degrees W should be cut in two
and represented as a MultiLineString.

{
    "type": "MultiLineString",
    "coordinates": [
    [
    [170.0, 45.0], [180.0, 45.0]
    ], [
    [-180.0, 45.0], [-170.0, 45.0]
    ]
    ]
}

A rectangle extending from 40 degrees N, 170 degrees E across the
antimeridian to 50 degrees N, 170 degrees W should be cut in two and
represented as a MultiPolygon.

{
    "type": "MultiPolygon",
    "coordinates": [
    [
    [
    [180.0, 40.0], [180.0, 50.0], [170.0, 50.0],
    [170.0, 40.0], [180.0, 40.0]
    ]
    ],
    [
    [
    [-170.0, 40.0], [-170.0, 50.0], [-180.0, 50.0],
    [-180.0, 40.0], [-170.0, 40.0]
    ]
    ]
    ]
}

Like DMS/Sexagesimal or UTM

(https://www.crunchydata.com/blog/converting-dms-to-postgis-point-geometry)

From the specification: https://tools.ietf.org/html/rfc7946

3.2. Feature Object

o  If a Feature has a commonly used identifier, that identifier
SHOULD be included as a member of the Feature object with the name
"id", and the value of this member is either a JSON string or
number.

• https://github.com/Turfjs/turf/tree/master/packages/turf-concave
• https://github.com/Turfjs/turf/tree/master/packages/turf-convex

The area of a polygon should IMO be the area of the outer ring minus the area of the union of the inner rings.

Needs #24

Also add tests...

https://developers.google.com/maps/documentation/utilities/polylinealgorithm

https://github.com/Turfjs/turf/blob/master/packages/turf-boolean-crosses

Links:

• https://github.com/TWKB/Specification/blob/master/twkb.md
• https://postgis.net/docs/ST_AsTWKB.html
• https://github.com/TWKB/twkb.js
• https://github.com/mapnik/mapnik/blob/master/src/twkb.cpp

https://github.com/Turfjs/turf/tree/master/packages/turf-kinks

• https://epsg.io/4978

Check if one of the formulas here is acutally correct, or search for a correct formula:
https://stackoverflow.com/questions/1185408/converting-from-longitude-latitude-to-cartesian-coordinates/55256861

A use case is described here: https://www.crunchydata.com/blog/postgis-clustering-with-k-means

Add an extension to Projection.swift, maybe a convenience initializer to BoundingBox(projected: ProjectedBoundingBox)

• Overview of the GeoJSON format (https://www.rfc-editor.org/rfc/rfc7946)
  • Document the objects
  • Examples for how to create each object
  • Examples for how to read and write objects from various sources
• Document Coordinate3D and CoordinateXY, and how to project from one to the other
• Document BoundingBox
• Document the RTree
• Document WKB/WKT
• Link to https://github.com/Outdooractive/mvt-tools and the other yet unpublished package
• Link to the documentation in https://swiftpackageindex.com/Outdooractive/gis-tools/main/documentation/gistools
• Add a list of all ported algorithms and document at least the most important ones

From the specification: https://tools.ietf.org/html/rfc7946

5. Bounding Box

Example of a 3D bbox member with a depth of 100 meters:

{
    "type": "FeatureCollection",
    "bbox": [100.0, 0.0, -100.0, 105.0, 1.0, 0.0],
    "features": [
    //...
    ]
}

A rectangle extending from 40 degrees N, 170 degrees E across the
antimeridian to 50 degrees N, 170 degrees W should be cut in two and
represented as a MultiPolygon.

{
    "type": "MultiPolygon",
    "coordinates": [
    [
    [
    [180.0, 40.0], [180.0, 50.0], [170.0, 50.0],
    [170.0, 40.0], [180.0, 40.0]
    ]
    ],
    [
    [
    [-170.0, 40.0], [-170.0, 50.0], [-180.0, 50.0],
    [-180.0, 40.0], [-170.0, 40.0]
    ]
    ]
    ]
}

5.3. The Poles

A bounding box that contains the North Pole extends from a southwest
corner of "minlat" degrees N, 180 degrees W to a northeast corner of
90 degrees N, 180 degrees E.  Viewed on a globe, this bounding box
approximates a spherical cap bounded by the "minlat" circle of
latitude.

"bbox": [-180.0, minlat, 180.0, 90.0]

A bounding box that contains the South Pole extends from a southwest
corner of 90 degrees S, 180 degrees W to a northeast corner of
"maxlat" degrees S, 180 degrees E.

"bbox": [-180.0, -90.0, 180.0, maxlat]

A bounding box that just touches the North Pole and forms a slice of
an approximate spherical cap when viewed on a globe extends from a
southwest corner of "minlat" degrees N and "westlon" degrees E to a
northeast corner of 90 degrees N and "eastlon" degrees E.

"bbox": [westlon, minlat, eastlon, 90.0]

Similarly, a bounding box that just touches the South Pole and forms
a slice of an approximate spherical cap when viewed on a globe has
the following representation in GeoJSON.

"bbox": [westlon, -90.0, eastlon, maxlat]

Implementers MUST NOT use latitude values greater than 90 or less
than -90 to imply an extent that is not a spherical cap.

https://github.com/Turfjs/turf/blob/master/packages/turf-boolean-intersects

Improve handling for objects that cross the anitmeridian.

Either add some method to cut objects, or do it automatically.

• https://github.com/Turfjs/turf/blob/master/packages/turf-buffer
• https://github.com/GEOSwift/geos

• https://github.com/Turfjs/turf/tree/master/packages/turf-clusters
• https://github.com/Turfjs/turf/tree/master/packages/turf-clusters-dbscan
• https://github.com/Turfjs/turf/tree/master/packages/turf-clusters-kmeans

The GeoJSON spec doesn't (officially) allow different projections, but that doesn't meant that there aren't any usecases where you want to keep things simple and just use the coordinates that you have.

Expample: Loading data from Postgis via WKB that is originally in EPSG:3857 will currently be reprojected to EPSG:4326. This is unnecessary if you need the data in the original projection later on.

Many/most/all of the algorithms won't work with anything but lat/long coordinates, so this must be checked. Either bail out when the input has the wrong projection, or reproject on the fly.

Todos:

• Update the README
• Add projection support to Coordinate3D
• Add projection support to BoundingBox
• Add projection support to all GeoJSON objects
• Remove CoordinateXY
• Remove ProjectedCoordinate and ProjectedBoundingBox
• Projection support to WKB and WKT (convert from/to)
• Make BoundingBox.intersection() projection-aware
• Check each algorithm that it uses the right projection

https://github.com/Turfjs/turf/tree/master/packages/turf-great-circle

The implementation of Codable for geometry types is not compatible with SwiftData. Saving a model with a LineString as a property produces the following error:

SwiftData/ModelCoders.swift:286: Fatal error: Composite Coder only supports Keyed Container

I have an branch that fixes this, but I think it changes how things are serialized, so it does not serve as a drop in replacement for the current version(or maybe it does, I'm not sure). I think it is possible to make a version that would be a drop in replacement(but maybe it isn't), at the expense or somewhat more repeated code.

Is this a change you would be interested in? If so I can work on preparing a PR. But i also understand if you are not, as this seems like a somewhat niche use.

Was there an intentional decision to avoid using Codable for the GeoJSON support?

https://github.com/Turfjs/turf/tree/master/packages/turf-polygon-smooth

https://proj.org/en/9.4/about.html

For transforming coordinates between coordinate reference systems.

Should be optional, as this uses an external library.

It looks like integer feature ids should be explicitly cast to UInt64 on WatchOS. I have a branch with tests for this.

Gist for discussion: https://gist.github.com/JeffLutzenberger/369d3062dafb5925d9641119eef41edd

(MVT tile spec: mapbox/vector-tile-spec#94)