mapbox / vector-tile-spec

Mapbox Vector Tile specification
https://www.mapbox.com/vector-tiles/specification/
Other
891 stars 210 forks source link

Allow altitude to be encoded #76

Open blanchg opened 8 years ago

blanchg commented 8 years ago

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

Command Id Parameters Parameter Count
MoveTo 1 dX, dY 2
LineTo 2 dX, dY 2
MoveTo3 5 dX, dY, dAltitude 3
LineTo3 6 dX, dY, dAltitude 3
ClosePath 7 No parameters 0
Example Command Integers
Command ID Count CommandInteger Binary Representation [Count][Id]
MoveTo 1 1 9 [00000000 00000000 0000000 00001][001]
MoveTo 1 120 961 [00000000 00000000 0000011 11000][001]
LineTo 2 1 10 [00000000 00000000 0000000 00001][010]
LineTo 2 3 26 [00000000 00000000 0000000 00011][010]
MoveTo3 5 1 13 [00000000 00000000 0000000 00001][101]
MoveTo3 5 120 965 [00000000 00000000 0000011 11000][101]
LineTo3 6 1 14 [00000000 00000000 0000000 00001][110]
LineTo3 6 3 30 [00000000 00000000 0000000 00011][110]
ClosePath 7 1 15 [00000000 00000000 0000000 00001][111]

Calling it altitude hopefully conveys the intent to provide 2.5D for simplicity. The MoveTo3 and LineTo3 work the same as the corresponding MoveTo and LineTo.

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 :)

springmeyer commented 8 years ago

/cc @kkaefer who has also been pondering how to encode a z value

e-n-f commented 8 years ago

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?

blanchg commented 8 years ago

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?

zuo1188 commented 7 years ago

hoping mapbox vector tile can support 3d polygon like this img_1628 img_1629 img_1631

AutoNavi seams using 3d vectortile defined by themself

andrewharvey commented 6 years ago

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.

andrewharvey commented 6 years ago

@flippmoke is this being considered for mvt3?

e-n-f commented 6 years ago

Yes, 3-D geometries are part of the plan.

jaakla commented 6 years ago

Some thoughts about 3D (after years of working in that space):