Reporter: stanton
[Submitted to the original trac issue database at 10.16am, Friday, 28th January 2011]

At present, osm2pgsql largely ignores relations. The only processing of relations that happens is that ways which are members are concatenated (if consecutive) and added to planet_osm_line as a separate entry, with the tags of the relation. The link between points and relations, as well as roles, are lost entirely.

Having "raw" relation and membership data in the database and thus available to Mapnik would open up new possibilities. (What I have in mind is a public transport map with the lines superimposed. Each way would be labeled with the lines that use it as a list, e.g. 1, 2, 5; ways used in only one direction could be rendered with arrows.)

This would involve creating two new tables:

• planet_osm_relation, which would contain an osm_id column (with its OSM ID) and one more column for each tag of the relation - in a fashion similar to planet_osm_line and planet_osm_point
• planet_osm_member, which would contain the relation membership information as follows:
  • osm_id - ID of the relation
  • type - OSM primitive type of the member (node, way, relation)
  • member - ID of the member
  • seq - Sequential number of the member in the relation (1-based)
  • role - Role of the member

As for processing cost, I'd guesstimate a relation with a certain number of members to have a similar cost to a way with the same number of nodes:

• A row in the corresponding table, one column per tag, needs to be created in either case.
• Instead of collecting all nodes of a way, we'd be collecting all members of a relation - roughly equivalent.
• No spatial calculation for relations; instead we would add another table row per member. Given that spatial calculations are expensive, I'd expect relations to be even slightly faster on this one.