trajectoryjp / spatial_id_go

Go module spatial id provides conversions between geodetic coordinates, spatial IDs, and extended spatial IDs.

空間IDモジュール

概要

任意の座標を空間IDに変換するモジュールです。

• 外部ライブラリの事前インストールなしで利用が可能です。
• 提供機能は以下の通りです。
  • 任意の座標から空間IDを取得する機能
  • 空間IDを任意の精度に拡大・縮小する機能
  • 任意の空間IDの周辺の空間IDを取得する機能
  • 任意の形状から空間IDを取得する機能
  • 空間IDをquadkeyと2分木におけるbit形式のIDに変換する機能
• 空間ID仕様についてはDigital Architecture Design Center 3次元空間情報基盤アーキテクチャ検討会 会議資料を参照して下さい。

注意事項

• 入力可能な緯度の最大、最小値は「±85.0511287798」とします。
• 精度レベルの指定範囲は、0から35とします。
• 経度の限界値は±180ですが、180と-180は同じ個所を指すこととZFXY形式のインデックスの考え方により、180はモジュール内部では-180として扱われます。(180の入力は可能とします。)

spatial_id_go's Issues

Add new functions 'CheckSpatialIdsOverlap', 'CheckSpatialIdsArrayOverlap', 'CheckExtendedSpastialIdsArrayOverlap' and 'CheckExtendedSpastialIdsOverlap'

Describe the solution you'd like

• CheckSpatialIdsOverlap would provide a method for checking the overlap between two spatialIds.

• CheckSpatialIdsArrayOverlap would provide a method for checking the overlap between two arrays of spatialIds.

• CheckExtendedSpatialIdsOverlap would provide a method for checking the overlap between two extended spatialIds.

• CheckExtendedSpatialIdsArrayOverlap would provide a method for cheking the overlap between two arrays of extended spatialIds.

Delete common/logger

This module has the logger package.
I think this is maybe for developing, but modules for releases should not have loggers.
So please delete all of them.

Add geodesic to cartesian conversion functions

Currently there are no internal functions to convert from geodesic (latitude, longitude, altitude) to cartesian (X, Y, Z).

1. Make a function that converts from geodesic to cartesian.
2. Make a second function that converts from cartesian to geodesic.

The Coordinate Reference System should be consistent and doesn't need to be changed by the user of the function.

Add explanation in README for new functions in PR#6

Is your feature request related to a problem? Please describe.
There is no guide on how to use the functions that were added in PR#6.

Describe the solution you'd like
Add a brief explanation of each of

• GetNspatialIdsAroundVoxcels()
• GetSpatialIdsWithinRadiusOfLine()
• FitClearanceAroundExtendedSpatialID()

and a code-based example of how to use them. The explanation should include how to use each of the parameters.

Additional context
Also, add speed performance of GetSpatialIdsWithinRadiusOfLine

Rename GetSpatialIdsWithinRadiusOfLine

Describe the bug
GetSpatialIdsWithinRadiusOfLine does not return spatial ids but extended spatial ids.
The name is wrong.

Expected behavior
Please rename GetSpatialIdsWithinRadiusOfLine.
For example, GetExtendedSpatialIdsWithinRadiusOfLine

Additional context
Add Auxiliary SpatialID functions

GetSpatialIdsWithinRadiusOfLine() does not return expected result when radius==0 and skipsMeasurement=true

Describe the bug
When radius == 0, and skipsMeasurement=true GetSpatialIdsWithinRadiusOfLine() should return the same result as GetExtendedSpatialIdsOnLine(), but it returns more than GetExtendedSpatialIdsOnLine().

To Reproduce
Steps to reproduce the behavior:

1. Run a request with:

	startPoint, error := object.NewPoint(137.0, 34.0, 50)
	if error != nil {
		t.Fatal(error)
	}
	endPoint, error := object.NewPoint(137.001, 34.001, 50)
	if error != nil {
		t.Fatal(error)
	}

spatialIds, error := transform.GetSpatialIdsWithinRadiusOfLine(startPoint, endPoint, 0, 23, 23, true)

spatialIdsOnLine, error := shape.GetExtendedSpatialIdsOnLine(startPoint, endPoint, 23, 23)

and spatialIds != spatialIdsOnLine

Expected behavior
In the above case,

spatialIds != spatialIdsOnLine

Desktop (please complete the following information):

• OS: macOS
  n/a
• Version 14.4.1

Smartphone (please complete the following information):
n/a

Additional context
n/a

Append conversion functions between ExtendedSpatialId and QuadkeyAndAltitudekey without using floating point numbers

Is your feature request related to a problem? Please describe.
For example, we can convert ExtendedSpatialId to QuadkeyAndAltitudekey with ConvertExtendedSpatialIDsToQuadkeysAndVerticalIDs(_).
However, this uses floating point numbers for the maximum and minimum heights, which can lead to calculation errors.

Describe the solution you'd like
QuadkeyAndAltitudekey has the same measurements as ExtendedSpatialId, so ideally we can convert between them without using floating point numbers.

Describe alternatives you've considered
Please append conversion functions between ExtendedSpatialId and QuadkeyAndAltitudekey without using floating point numbers.

Additional context
This blocks #17.

Move X,Y,F index validation checks inside `.Set_()` functions

Is your feature request related to a problem? Please describe.
Currently, all .Set_() functions in spatial_id.go do not validate incoming index data

Describe the solution you'd like
There are known values for the maximum and minimum possible values, according to Digital Architecture Design Center 3次元空間情報基盤アーキテクチャ検討会 会議資料. The .Set_() functions should check these.

For example, the user should not be able to set the y index beyond the theoretical possible value.

Additional context

Because these are methods to the spatialID/extendedSpatialID, consider what should happen (what value should be returned) when the maximum or minimum possible value is exceeded.

ConvertExtendedSpatialIDsToQuadkeysAndVerticalIDs() does not return the expected number of vertical indicies

Describe the bug
ConvertExtendedSpatialIDsToQuadkeysAndVerticalIDs() returns FromExtendedSpatialIDToQuadkeyAndVerticalID.innerIDList with a length=2 when the length should be 1.

type FromExtendedSpatialIDToQuadkeyAndVerticalID struct {
	// quadkeyの精度
	quadkeyZoom int64
	// innerIDList [[quadkey,vIndex]...]
	innerIDList [][2]int64
	// 高さ方向の精度
	vZoom int64
	// 最高高度
	maxHeight float64
	// 最低高度
	minHeight float64
}

To Reproduce
(will produce test code after issue is reported)

Expected behavior
For an Extended Spatial ID of verticalZoom=23 and horizontalZoom=23 with output zooms of the same levels, we should expect FromExtendedSpatialIDToQuadkeyAndVerticalID.innerIDList to be length=1

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: macOS
• Version 14.4.1

Smartphone (please complete the following information):
n/a

Additional context
The reason for the length of two is likely due to a boarder problem: convertVerticallIDToBit() calculates

	spatialIDMaxHeight := float64(vIndex+1) * alt25 / float64(math.Pow(2, float64(vZoom)))
	spatialIDMinHeight := float64(vIndex) * alt25 / float64(math.Pow(2, float64(vZoom)))

and when the bitIndex is calculated using Max and Min height

	maxBitIndex := calcBitIndex(spatialIDMaxHeight, outputZoom, maxHeight, minHeight)
	minBitIndex := calcBitIndex(spatialIDMinHeight, outputZoom, maxHeight, minHeight)

maxBitIndex measures the location of the top of the current Extended Spatial ID and also refers to the next higher one.

Make ConvertExtendedSpatialIdsToQuadkeysAndAltitudekeys() easier to use

Is your feature request related to a problem? Please describe.
the current input parameters are:

ConvertExtendedSpatialIDsToQuadkeysAndAltitudekeys
//
//	Converts ExtendedSpatialIDs to []*object.FromExtendedSpatialIDToQuadkeyAndAltitudekey given zoom, scalar and offset parameters
//
// input:
//
// extendedSpatialIDs: slice of string-encoded ExtendedSpatialIDs
//
// outputQuadkeyZoom: the horizontal resolution of the output
//
// outputAltitudekeyZoom: the vertical resolution of the output
//
// altitudeRangeScalar: altitude range scalar is s, where 2^25-s = altitude range (max altitude - min altitude)
//
// verticalIndexOffset : shifts the altitude range up or down by n units of the resulting verticalIndex

but altitudeRangeScalar and verticalIndexOffset should be easier to understand and implement. altitudeRangeScalar requires two-step calculation (2^25 - 2^scalar) and verticalIndexOffset changes depending on outputAltitudekeyZoomLevel.

Describe the solution you'd like

• verticalIndexOffset should ideally be intuitive and independent of other input parameters (ie, not dependent on the outputAltitudekeyZoom)
• altitudeRangeScalar should simply be 2^scalar