Skip to content
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

Open
blanchg opened this issue May 10, 2016 · 8 comments
Open

Allow altitude to be encoded #76

blanchg opened this issue May 10, 2016 · 8 comments

Comments

@blanchg
Copy link

blanchg commented May 10, 2016

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
Copy link

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

@e-n-f
Copy link
Contributor

e-n-f commented May 11, 2016

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
Copy link
Author

blanchg commented May 11, 2016

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
Copy link

zuo1188 commented Aug 16, 2017

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
Copy link

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
Copy link

@flippmoke is this being considered for mvt3?

@e-n-f
Copy link
Contributor

e-n-f commented Apr 17, 2018

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

@jaakla
Copy link

jaakla commented Jul 17, 2018

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

  • For 3D buildings you cannot just add z coordinate to simple features, you need to build meshes, textures with multiple resolutions etc. Nutiteq/CARTO built few years back own solution and file format NML based on 3D graphics standard OpenCollada. NML is basically PBF-encoded DAE, which is packaged to tile-based sqlite file (somewhat similar to mbtiles) with multiple zoom levels and corresponding textures in different resolutions (LOD based on zoom). Later Cesium created own open 3D tiles spec, which is kind of similar, but more developed. Basically you introduce many special 3D object types to encode buildings etc.
  • For 3D terrain you also need special solution, neither Collada or simple features is optimal for that. Open 3D Tiles spec covers that area also (AFAIK), NML never did so far.
  • For simple geo features with 3D coordinates I'd suggest not to add only Z, but also M dimension (Measure). This allows to encode certain natural values (e.g. temperature, time) in more compressed way, as diffs.
  • With some 3D datasets, like point clouds with significant Z range you may need 3(or 4 with M)-dimensional tiling schema. This would resolve Z (and M) unit question - you can leave them 'unitless' as XY are now; but it requires defining Z/M ranges in metadata level. With current XY space there is implicit 'natural global' range (i.e. the world in Spherical Mercator) and this makes client side simpler, with Z/M you need to make e.g. tilejson mandatory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants