Skip to content
This repository has been archived by the owner on Dec 8, 2017. It is now read-only.

Rendering support for building roofs? #18

Closed
nickidlugash opened this issue Jun 20, 2016 · 4 comments
Closed

Rendering support for building roofs? #18

nickidlugash opened this issue Jun 20, 2016 · 4 comments

Comments

@nickidlugash
Copy link

From #17 (comment)

What would it take to implement roof rendering for buildings, so we can improve the accuracy of renderings of complex and high-profile landmarks?

Some questions I've been thinking about:

Which OSM keys would we support?

OSM currently has 1,028,142 features with a roof:shape tag (773,099 if you subtract the flat values, which would render identically to having no roof:shape tag).

205,223* of these features also have a roof:height and/or roof:level value. These values would be helpful not just to render accurate height, but to give certain distinctive-looking roofs the proper proportions (e.g. very elongated pyramid-shaped roofs on cathedrals).

The rest of the roof tags are probably not useful (either not relevant, or are not used widely enough).

How would we represent roof properties in the spec?

The current spec additions that @lbud has added to her working branch are all for a generic extrusion type, not a type specific to buildings, which I think makes sense. Adding roofs complicates this a bit. Some (possibly questionable) options:

  1. Add extrusion-top-shape and extrusion-top-height properties (or however they would be named). This would involve creating support for a bunch of simple 3D shapes. By far the most common are various triangular prisms and pyramids, but also includes spherical domes and onion domes. Are there use cases for additional geometries on top of an extrusion, besides for buildings?
  2. Treat the roofs as a separate style layer, with a separate render type of 3d or something. This type would require both 3d-shape and 3d-height properties as above, and also a 3d-min-height. As above, it would require support for rendering a variety of simple 3D shapes. I haven't really thought this option through.

Anyone who has any ideas of how this could work, and how big of a lift it would be, please chime in!

* 107,464 (# of roof:height) + 116,983 (# of roof:level) - 19,224 (# with both) = 205,223

/cc @lbud @ajashton @mapbox/gl

@1ec5
Copy link
Contributor

1ec5 commented Jun 20, 2016

Are there use cases for additional geometries on top of an extrusion, besides for buildings?

One could imagine a 3D analogue to a "line cap" property, to enhance uses cases like mapbox/mapbox-gl-style-spec#456 (comment) where the extruded geometries represent bar-chart-like data rather than physical features. But for the most part, I think the particular roof shapes we'd want to support are so specific to buildings that they couldn't even be generalized to support, say, extruded fountains.

@ajashton
Copy link
Member

The roof shape tagging is very OSM-specific, and only covers building rendering while there are all kinds of other uses for 3D visualization.

Say GL supported a generalized 3D mesh format:

  • OSM's roof:* tags could be parsed and turned into a 3D mesh as a pre-processing step (ie before/during the creation of the vector tiles)
    • We don't need to worry about complicating the GL style spec with building-specific properties
    • We can iterate on shape support incrementally without having to release and support new style spec versions at every stage
  • We would have the freedom to render the many many building shapes not describable by roof:* tags
    • Many city-defining landmarks are in this category - One World Trade Center, The Eiffel Tower, the Sydney Opera House, the Gateway Arch in St Louis, various space needle style towers.
  • It would open up many more interesting data visualization possibilities

@mourner
Copy link
Member

mourner commented Jun 25, 2016

We don't need to worry about complicating the GL style spec with building-specific properties

We will have to make a major Vector Tile spec revision though, designing an new encoding scheme for 3D meshes. This may be fine, but worth noting.

Another appeal of the client-side mesh generation from roof properties is that we can have adaptive detalization of the mesh (e.g. when overzooming to a building), while a pre-generated mesh would either be too simple, or take a lot of size encoded in VT.

@lucaswoj
Copy link

lucaswoj commented Jan 17, 2017

migrated to mapbox/mapbox-gl-js#3998

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

No branches or pull requests

5 participants