Various RAWR tile fixes

[zerebubuth]

A slightly random grab-bag of changes that were necessary to get RAWR tiles rendering in a not-awful way.

• Cache the bounds of a LazyShape, and use that to skip unnecessary calls to geometry intersection. This doesn't save as much time as I'd have hoped, but it seems like a relatively benign bit of code to leave in.
• Store sorted list of route names, rather than set. Some versions of ujson seem to be unhappy with serialising a set. I think the version we're using in prod is okay, but I managed to randomly update mine locally while playing around with different Shapely versions.
• Handle missing nodes, ways and relations in the index. In an attempt at efficiency, I try to only index elements which are "interesting" and have a high likelihood of being looked up. However, at index-build time we don't have full information about relation membership, so there can be members of relations which I didn't deem "interesting". I think this is okay, and these elements wouldn't have contributed to the tile data.
• Be consistent about line / linestring usage. Move it all to Enum-land instead.
• Handle small numerical precision issues in conversion of bounding box to tile coverage. This was causing a slight (around 1e-6) change in coordinates to grab the data for the tile above, most of the contents of which were promptly discarded as they were outside the bounding box. Added a test for this too.

[iandees]

Might be better to have this lookup stored somewhere outside the function so it doesn't have to get re-created for every call of parse_shape_types(). It might fit in as a @classmethod on ShapeType?

[rmarianski]

We might be able to be even more clever by leaning on enums.

  class ShapeType(Enum):
      point = 1
      line = 2
      polygon = 3
  
      multipoint = 1
      linestring = 2
      multilinestring = 2
      polygon = 3
      multipolygon = 3

Lookup is then just:

ShapeType[value.lower()]

which raises a KeyError if not found.

Although the code as it is should work, I don't think this is a good idea since it can lead to some confusing behavior:

>>> ShapeType.multipolygon
<ShapeType.polygon: 3>

Anyway, just mentioning this but I like @iandees more. We could even just stick the lookup at global scope if the interaction with sticking it on enums is awkward.

[rmarianski]

We might be able to be even more clever by leaning on enums.

  class ShapeType(Enum):
      point = 1
      line = 2
      polygon = 3
  
      multipoint = 1
      linestring = 2
      multilinestring = 2
      polygon = 3
      multipolygon = 3

Lookup is then just:

ShapeType[value.lower()]

which raises a KeyError if not found.

Although the code as it is should work, I don't think this is a good idea since it can lead to some confusing behavior:

>>> ShapeType.multipolygon
<ShapeType.polygon: 3>

Anyway, just mentioning this but I like @iandees more. We could even just stick the lookup at global scope if the interaction with sticking it on enums is awkward.

[zerebubuth]

I ended up using the Enum aliases in 2cb637f because I couldn't figure out how to get a dictionary defined at class level to refer to the enumeration values, also defined at class level.

The alias method seems to work well, and I think it's quite readable. I put a comment in there to hopefully warn people away from using the aliases, and we'll have to see whether any other unexpected behaviour crops up as a result.

Please let me know what you think.

[rmarianski]

Sorry! :(

[rmarianski]

The alias method seems to work well, and I think it's quite readable. I put a comment in there to hopefully warn people away from using the aliases, and we'll have to see whether any other unexpected behaviour crops up as a result.

Yea, this seems fine to me 👍 . I like that you put in a comment in there.

[zerebubuth]

Thanks!