mirror
/
tile38
mirror of https://github.com/tidwall/tile38.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
tile38/vendor/github.com/tidwall/geojson/circle_test.go

174 lines
4.5 KiB
Go
Raw Normal View History

Faster point in polygon / GeoJSON updates 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.
2018-10-11 00:25:40 +03:00
package geojson
Updated geojson packages
2018-10-27 19:23:29 +03:00
import (
"testing"
Faster point in polygon / GeoJSON updates 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.
2018-10-11 00:25:40 +03:00
Updated geojson packages
2018-10-27 19:23:29 +03:00
"github.com/tidwall/geojson/geometry"
)
func TestCircleNew(t *testing.T) {
Fix Circle type
2018-10-16 18:55:26 +03:00
expectJSON(t,
`{"type":"Feature","geometry":{"type":"Point","coordinates":[-112,33]},"properties":{"type":"Circle","radius":"5000"}}`,
`{"type":"Feature","geometry":{"type":"Point","coordinates":[-112,33]},"properties":{"type":"Circle","radius":5000,"radius_units":"m"}}`,
)
Faster point in polygon / GeoJSON updates 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.
2018-10-11 00:25:40 +03:00
g, err := Parse(`{
Updated geojson packages
2018-10-27 19:23:29 +03:00
"type":"Feature",
"geometry":{"type":"Point","coordinates":[-112.2693,33.5123]},
"properties": {
"type": "Circle",
"radius": 1000
}
}`, nil)
Faster point in polygon / GeoJSON updates 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.
2018-10-11 00:25:40 +03:00
if err != nil {
t.Fatal(err)
}
Fix Circle type
2018-10-16 18:55:26 +03:00
expect(t, g.Contains(PO(-112.26, 33.51)))
Updated geojson packages
2018-10-27 19:23:29 +03:00
circle := NewCircle(P(-112, 33), 123456.654321, 64)
expectJSON(t, circle.JSON(), `{"type":"Feature","geometry":{"type":"Point","coordinates":[-112,33]},"properties":{"type":"Circle","radius":123456.654321,"radius_units":"m"}}`)
}
func TestCircleContains(t *testing.T) {
g := NewCircle(P(-122.4412, 37.7335), 1000, 64)
expect(t, g.Contains(PO(-122.4412, 37.7335)))
expect(t, g.Contains(PO(-122.44121, 37.7335)))
expect(t, g.Contains(
MPO([]geometry.Point{
P(-122.4408378, 37.7341129),
P(-122.4408378, 37.733)})))
expect(t, g.Contains(
NewCircle(P(-122.44121, 37.7335), 500, 64)))
expect(t, g.Contains(
LO([]geometry.Point{
P(-122.4408378, 37.7341129),
P(-122.4408378, 37.733)})))
expect(t, g.Contains(
MLO([]*geometry.Line{
L([]geometry.Point{
P(-122.4408378, 37.7341129),
P(-122.4408378, 37.733),
}),
L([]geometry.Point{
P(-122.44, 37.733),
P(-122.44, 37.7341129),
})})))
expect(t, g.Contains(
PPO(
[]geometry.Point{
P(-122.4408378, 37.7341129),
P(-122.4408378, 37.733),
P(-122.44, 37.733),
P(-122.44, 37.7341129),
P(-122.4408378, 37.7341129),
},
[][]geometry.Point{})))
// Does-not-contain
expect(t, !g.Contains(PO(-122.265, 37.826)))
expect(t, !g.Contains(
NewCircle(P(-122.265, 37.826), 100, 64)))
expect(t, !g.Contains(
LO([]geometry.Point{
P(-122.265, 37.826),
P(-122.210, 37.860)})))
expect(t, !g.Contains(
MPO([]geometry.Point{
P(-122.4408378, 37.7341129),
P(-122.198181, 37.7490)})))
expect(t, !g.Contains(
MLO([]*geometry.Line{
L([]geometry.Point{
P(-122.265, 37.826),
P(-122.265, 37.860),
}),
L([]geometry.Point{
P(-122.44, 37.733),
P(-122.44, 37.7341129),
})})))
expect(t, !g.Contains(PPO(
[]geometry.Point{
P(-122.265, 37.826),
P(-122.265, 37.860),
P(-122.210, 37.860),
P(-122.210, 37.826),
P(-122.265, 37.826),
},
[][]geometry.Point{})))
Faster point in polygon / GeoJSON updates 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.
2018-10-11 00:25:40 +03:00
}
Updated geojson packages
2018-10-27 19:23:29 +03:00
func TestCircleIntersects(t *testing.T) {
g := NewCircle(P(-122.4412, 37.7335), 1000, 64)
expect(t, g.Intersects(PO(-122.4412, 37.7335)))
expect(t, g.Intersects(PO(-122.44121, 37.7335)))
expect(t, g.Intersects(
MPO([]geometry.Point{
P(-122.4408378, 37.7341129),
P(-122.4408378, 37.733)})))
expect(t, g.Intersects(
NewCircle(P(-122.44121, 37.7335), 500, 64)))
expect(t, g.Intersects(
LO([]geometry.Point{
P(-122.4408378, 37.7341129),
P(-122.4408378, 37.733)})))
expect(t, g.Intersects(
LO([]geometry.Point{
P(-122.4408378, 37.7341129),
P(-122.265, 37.826)})))
expect(t, g.Intersects(
MLO([]*geometry.Line{
L([]geometry.Point{
P(-122.4408378, 37.7341129),
P(-122.265, 37.826),
}),
L([]geometry.Point{
P(-122.44, 37.733),
P(-122.44, 37.7341129),
})})))
expect(t, g.Intersects(
PPO(
[]geometry.Point{
P(-122.4408378, 37.7341129),
P(-122.265, 37.860),
P(-122.210, 37.826),
P(-122.44, 37.7341129),
P(-122.4408378, 37.7341129),
},
[][]geometry.Point{})))
expect(t, g.Intersects(
MPO([]geometry.Point{
P(-122.4408378, 37.7341129),
P(-122.198181, 37.7490)})))
expect(t, g.Intersects(
MLO([]*geometry.Line{
L([]geometry.Point{
P(-122.265, 37.826),
P(-122.265, 37.860),
}),
L([]geometry.Point{
P(-122.44, 37.733),
P(-122.44, 37.7341129),
})})))
// Does-not-intersect
expect(t, !g.Intersects(PO(-122.265, 37.826)))
expect(t, !g.Intersects(
NewCircle(P(-122.265, 37.826), 100, 64)))
expect(t, !g.Intersects(
LO([]geometry.Point{
P(-122.265, 37.826),
P(-122.210, 37.860)})))
}
// This snippet tests 100M comparisons.
// On my box this takes 24.5s without haversine trick, and 13.7s with the trick.
//
//func TestCircle_Performance(t *testing.T) {
// g := NewCircle(P(-122.4412, 37.7335), 1000, 64)
// r := rand.New(rand.NewSource(42))
// for i:= 0; i < 100000000; i++ {
// g.Contains(PO((r.Float64() - 0.5) * 180, r.Float64() * 90))
// }
// expect(t, true)
//}