-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow altitude to be encoded #76
Comments
/cc @kkaefer who has also been pondering how to encode a z value |
This could also be useful for carrying around metadata like node IDs of points. One big question I have is how this works for clipping at the tile edges. Is it considered safe to interpolate between the Z values of the endpoints when fabricating a new point at the tile edge to clip a line or a polygon edge? If not, what Z value should that point have? |
RE: Z value when clipping a line, Isn't this the same issue when clipping a line/polygon anyway, you are creating an arbitrary (x,y) point already so you need to know the z value for that point? Am I missing something else? |
This could be done with #93 but that way it wouldn't be universally understood as altitude. In the GeoJSON spec: Altitude or elevation MAY be included as an optional third element. |
@flippmoke is this being considered for mvt3? |
Yes, 3-D geometries are part of the plan. |
Some thoughts about 3D (after years of working in that space):
|
Ultimately including 3D solids is what I would like however that is a complex issue that may confuse the specification or probably should be its own specification. See issues here: https://3d.bk.tudelft.nl/hledoux/blog/your-solids-the-same/
An intermediate step to provide 2.5D could be to allow 2 more commands and an altitude parameter
1
dX
,dY
2
dX
,dY
5
dX
,dY
,dAltitude
6
dX
,dY
,dAltitude
7
Example Command Integers
[Count][Id]
1
1
9
[00000000 00000000 0000000 00001][001]
1
120
961
[00000000 00000000 0000011 11000][001]
2
1
10
[00000000 00000000 0000000 00001][010]
2
3
26
[00000000 00000000 0000000 00011][010]
5
1
13
[00000000 00000000 0000000 00001][101]
5
120
965
[00000000 00000000 0000011 11000][101]
6
1
14
[00000000 00000000 0000000 00001][110]
6
3
30
[00000000 00000000 0000000 00011][110]
7
1
15
[00000000 00000000 0000000 00001][111]
Calling it altitude hopefully conveys the intent to provide 2.5D for simplicity. The
MoveTo3
andLineTo3
work the same as the correspondingMoveTo
andLineTo
.This also maps to the TopoJson and GeoJson allowing an altitude to be defined in their coordinates specification.
The remaining problem is around specifying the bounds for the altitude and the extent. As the tiles won't stack. One option is to interpret the value using the tile resolution and the existing layer
extent
field. Values will be positive and negative.Hopefully this will trigger some discussion :)
The text was updated successfully, but these errors were encountered: