Add MD Three Inch Aerial Imagery

[simon04]

For #171.

This is the first imagery where the geometry is specified as MultiPolygon. This requires adapting convert_xml.py.

[tyrasd]

Ack! 😱

This is the first imagery where the geometry is specified as MultiPolygon.

Well, actually, there are already a couple of "multipolygon" sources in the repo (for example the South Tyrol 2014, or the Tiris * imagery), but which we forgot about in the geojsonification process in #191. Instead, they continued to use the slightly odd (and incompatible to GeoJSON) convention where the rings in the coordinates array are all outer rings and inner rings are not allowed.

It's probably best to fix those all in one go and to apply an additional fix (very similar to yours also to fix the legacy json output).

For this particular layer this means that we can either wait until this is all fixed in the data processing before adding the source, or that we merge it using the old&incorrect coordinate scheme (because the PR as-is will probably break things for users of our legacy-json output).

[bhousel]

Well, actually, there are already a couple of "multipolygon" sources in the repo (for example the South Tyrol 2014, or the Tiris * imagery), but which we forgot about in the geojsonification process in #191. Instead, they continued to use the slightly odd (and incompatible to GeoJSON) convention where the rings in the coordinates array are all outer rings and inner rings are not allowed.

Yes, I just realized this as well.. @tyrasd should I do one last sync of the imagery as-is into iD before we change this?

I do think going forward we should use the correct geojson conventions for rings and holes..

[tyrasd]

should I do one last sync of the imagery as-is into iD before we change this?

ok 👍

Imho, it would make the most sense for iD to consume the imagery.geojson output, and for this repo to keep around the old scheme in the imagery.xml and imagery.json output (since we don't version this repo it could mean to be problematic for existing users if we change anything that's not backwards compatible – e.g. for someone who's running iD v1 for whatever reason).

[simonpoole]

Rather a weird place to discuss this, but I consider the issue that @tyrasd touched on, that we are not versioning at least the output the most annoying thing about the current setup. Besides that having the unversioned output files in the repo itself is simply messy, it further makes it difficult to consume the output automatically without having to fear breakage (as we had with the transition to GeoJSON).

Is there any fundamental problem with say generating a (github) release per week if something has changed and uploading the generated files to the release section of github?

[iandees]

Versioning is a good idea. Can you open up a new ticket for that, @simonpoole?

[simon04]

Let's use the "slightly odd (and incompatible to GeoJSON) convention" for this source as well and discuss the MultiPolygon change in #217.