Add (Multi)Polygon support

[acannistra]

The current iteration of changegen only supports adding and removing linestrings (e.g. simple non-closed Ways). We should add the ability to add/remove/modify polygons and multipolygons. This will be a little hard.

Polygons without holes are simply closed Ways in OSM, which means we basically already support creating new ones as a part of changefile generation.

However, they're (obviously) not represented as Linestrings in PostGIS (like other Ways are, e.g. non-closed ones like actual lines), which means we need to detect whether a given polygon has holes (à la ST_NumInteriorRings) to determine whether we can use the existing Way logic that we've already designed.

If we can't, that means we need to treat these Polygons (the ones with holes) like Multipolygons. (They need to be Relations.)

Spatial considerations

There are a few cases to consider:

• Adding a New Polygon
  1. If the polygon doesn't have holes, we just convert it to a closed Way (e.g. get the exterior ring) and use our existing logic.
  2. if the polygon does have holes, it means that it needs to be represented in the Changefile as a relation. We can create the constituent Ways (one for each interior and exterior ring) mostly the same, but (probably?) need to add role=outer to exterior rings and role=inner to interior rings when we write the <way> object to the changefile. Then we'll need a way to aggregate the new Way IDs and output a Relation with the right metadata. Getting the metadata right is a bit of a challenge coming off the imposm-based imported PostGIS database, and will probably mean that we have to require a relation_member or relation table instead of just a polygon table in the mapping.yaml imposm file. this is complicated.
• Modifying an Existing Polygon (e.g in the case of a new Way intersecting with an existing Polygon)
  1. If the polygon doesn't have holes: we can similarly extract the exterior ring of the Polygon, modify it in the same way that we usually do (e.g. adding intersection nodes), and produce a <modify> node for the changed Way.
  2. If the polygon does have holes, then it's a Relation problem again. In the case of an intersection, we can perhaps assume that the intersection is only relevant to a given Polygon's exterior ring, and therefore can only focus on modifying the Way that represents that exterior ring. To do this we need to know the OSM ID of the exterior ring Way, but I don't think we actually care at all about the parent relation. If we modify the exterior Way to contain a new node that represents an intersection, the parent relation is not affected. We can just modify the Way and output a <modify> tag for it.
• Removing Polygons (the trickiest case)
  1. If the polygon doesn't have holes
  2. AND the polygon is not part of a relation: we can similarly produce a <delete> node for the Way that we want to delete, representing the polygon.
  3. If the Polygon is part of a relation: we have to choose whether we also need to <modify> the Relation to exclude the Way that we're deleting, or if it doesn't matter (because downstream tools don't care if they can't find a Way that's constituent to a Relation

Source data considerations

The fact that we now need to consider relations (because we care about Polygons and Multipolygons) means that there are likely more constraints on the schema of PostGIS tables in the conflation database. For example: using the polygon imposm table type may not itself be sufficient information to enable generating changefiles, because those tables contain both polygons and multipolygons: in the case of multipolygons (that come from relations), the osm_id field is set with the relation ID, which makes getting the constituent Ways difficult.

We can fix this issue either by requiring the presence of a relation_member table that enables us to access constituent geometries of a given relation, or by looking up these constituent members during the changefile generation process.

The former is probably a better option, because we can use PostGIS queries to enable the necessary spatial comparisons more easily. However it's potentially more complicated.