Relation 3D:Model

Rationale

We already have simple 3d modelling like building:parts=* and building:levels=* so, what should we do if we want to use stored 3d models and simple 3d which we already have in database? We need to know, which objects have 3d model and do not render building:parts=* and building:levels=* based geometry.

Tags

Key	Value	Explanation
type	3d:model	Indicates this relation represents an object's 3d model.
src	url	URL to model. I think wiki data might be the best place to store models and models' edit history. I dont know which way is better, keep number of relations one for each model or keep number of links in each relation to models with different level of details.
polygons	Number of polygons	Says how many polygons contains model. Is it lowpoly or highpoly model.
azimuth	Origin azimuth	Angle between model's Y axis and direction to North
lon	Model's origin lon	Longitude of model's (0, 0) point. Center coordinates of members by default.
lat	Model's origin lat	Latitude of model's (0, 0) point. Center coordinates of members by default.

Members

Member	Role	Explanation
building=* and building:part=*	-	Ways, used in Simple 3D buildings [S3DB], 3D Renders shouldn't render 3d models for child objects.
	origin	Origin point for model. I think it would be good practice to use one of the corners for this. Longitude and latitude of this point should override relation's lon and lat tag values.
	director	Used to specify azimuth for model, with osm node. If user have specified director point, build vector from origin node to director node. Norm of this vector will be X vector for model coordinates system. And azimuth is angle between direction to North and this vector. This value should override relation's azimuth tag value.

Procedural generation

1. Add roles for objects like 3d:ref:REF_NAME
2. Access that object from 3d model description script as REF_NAME
3. Generate geometry iteratively
4. Extend geometry groups with onthologies or throe osm's tag=vlue
5. Describe snapshots