Google Summer of Code/2017/Project Ideas/3D Model Repository
This is a description of the project idea "Web application for sharing 3D-Models to use in OSM-related 3D-Applications" that has been suggested among other ideas for the Google Summer of Code 2017. It is provided in the hope to help students understand what the project entails, and as a starting point for their own planning.
Vision
In addition to established use cases such as navigation systems and maps, OpenStreetMap is increasingly used for the purpose of 3D visualisation. A lot of data has been added using tagging standards such as Simple 3D buildings, which are supported by a wide range of data consumers. However, there is a limit to the level of detail that is achievable using common OSM tools, so while these existing tagging styles are an important foundation, some situations are more easily represented using 3D models created by stand-alone tools (such as Blender or SketchUp).
To collect open 3D models in a central location, and encourage creators to contribute their work to this effort, an online repository of 3D buildings would be ideal. Models in this repository could represent unique features such as a famous building, but also generic models representing typical street furniture designs – barriers, trash bins, street lights etc. Unlike OSM, which has a continuous dataset, the models would be subdivided into logical components, edited individually. For example, the model of the fountain in front of a castle would be separate from the model of the castle itself. The spatial relationship between the models does not need to be defined in the repository, because OpenStreetMap already serves this purpose well.
Unlike some existing model repositories, e.g. BlendSwap, the proposed model repository would be limited to and optimized for a particular goal: The representation of real-world features, in the context of 3D maps. The repository is not intended for fictional content, for example.
Functionality
The following is a brief outline of the intended functionality of the model repository.
Browsing
Each model has an associated page displaying model metadata and version history as well as an interactive 360° view of the model. The view preferably uses an existing library such as three.js or cesium.js for client-side rendering, but may allow for additional visualizations (e.g. pre-viewing the model with various OSM 3D renderers).
Visitors of the site search for models by name, or browse a map where models are marked as pins based on their metadata locations.
User accounts
To contribute content to the repository, logging into a user account is required. User accounts are tied to OSM user accounts via OAuth.
For each user, a page should list basic information (such as a customizable description text), as well as the user's contributions to the repository.
Special permissions are required for administrative actions, such as:
- hiding model revisions from non-admin users (e.g. in case of copyright violations)
- banning users
Upload
When uploading a model, the creator is given the ability to enter metadata and pre-view the model before saving it. The creator also selects a license for the model. Using a license chooser, the creator picks from a set of ODbL-compatible Creative Commons licenses[1].
During the upload process, it is also possible to select a location (latitude and longitude) on an OSM slippymap. This is not the same as the link with OSM (see below), and is primarily intended for discovering models on the website, not for data consumers. Due to legal reasons[2], this information is stored separately from the model.
Download
In addition to the ability to download individual models (via links accessible from their model page, and a basic API), all models and metadata in the repository are regularly published as dumps comparable to the OSM planet files.
Linking
Models don't always need to be explicitly linked with OSM to be usable by applications. For example, map style designers could determine that all OSM elements with a particular combination of tags should be represented with some model from the repository.
Nevertheless, explicitly linking between models and OSM elements will be possible. At its most basic, tagging a model's id to an OSM element signifies that there is a model of this object available in the repository, and that a renderer may display this model instead of attempting to render the OSM element normally. It follows that models have IDs which are sufficiently stable to allow external linking.
Future development
Not all possible features of a repository can be implemented during a single summer. The following are some advanced considerations related to the model repository. Those don't need to be addressed as part of this project, but are a possible area of further development.
- Advanced linking: More complex situations will eventually call for more elaborate linking approaches than the basic tags outlined above, e.g. making sure that paths, power lines etc. connected to a modeled building connect in the right place.
- Shared textures: For models that do not use photographic textures, sharing textures between models can help to keep the data volume within consumers' performance constraints.