The views provided by the OSHDB API provide direct access to the OSM entities, but also allow to get the JTS geometries of the OSM features corresponding to their state at the requested snapshot or contribution time(s). With this geometry, further operations such as filtering or aggregation can be performed. It is also irreplaceable during the map-reduce step to generate useful results, such as the length of a road network for example.
For some OSM elements, such as nodes, generating geometries is straight forward, for others the conversion requires further knowledge of the data model and tagging schema used by OSM. The following document gives an overview of how the OSHDB handles the building of geometries of different OSM object types.
Nodes are always presented as Points. Note that nodes which have never had a tag and are a part of a way or relation are considered to be structural-only points (sometimes called vertices), and thus not returned in an OSHDB query when querying all nodes. This is because the OSHDB does not consider them to not be map features by their own. They can however be fetched as members of their parent way or relation objects, if needed.
Ways are converted to either LineString or Polygon geometries depending on their composition and their tags: A not closed way is always represented as a line, while it depends for a closed one. The TagInterpreter component of the OSHDB is responsible for deciding whether a closed way results in a line or a polygon: A (closed) OSM way with the tag building=yes will be converted to a polygon geometry, while a junction=roundabout one will not.
Relations are handled by the OSHDB in two different ways: Multipolygons are converted to either Polygon or MultiPolygon geometries (depending on the number of outer rings), while all other relation types result in a GeometryCollection.
There are situations where a part of OSM's entities have either incomplete or invalid data, for example a broken multipolygon resulting from a mapping error. The OSHDB makes the best effort to return a (potentially invalid) geometry also for these objects. For performance reasons the OSHDB cannot check for every possible error in the input (OSM) data, and for similar reasons it also cannot correct all errors it does find. This means that the OSHDB does not provide any guaranteed outcome for all possible errors and might return an invalid or valid geometry as a result in such cases or even no result at all.