Shape annotation z-order is reversed

[1ec5]

We have a proof-of-concept application that draws an arrow on a route line at the location of each maneuver. Because the arrow’s stem must follow the path of the route even as it twists and winds, the arrow is implemented as a couple of polylines instead of a point annotation or annotation view. Because a polyline can only be stroked, not outlined, we’ve implemented the arrow as two similar pairs of polylines, a thinner, white pair of polylines atop a thicker, blue pair.

Here’s a patch to iosapp and macosapp that draws the arrow the way this proof-of-concept application does. This is what it’s supposed to look like, seen here in aa1a54c (ignore the fact that it’s backwards):

8985b13 introduced a regression that incorrectly closed each polyline:

0fba70d introduced another regression that reversed the z-order of the polylines:

As of 44406e9, the polyline-closing bug has been fixed, but the z-order bug remains:

In some cases, we’ve seen mixed behavior:

What should happen is that each added annotation is drawn above the annotation that was added before it.

/ref #5200
/cc @jfirebaugh

[jfirebaugh]

I think prior z-ordering behavior of shape annotations was mostly accidental rather than an intentional API contract, but I can see how it's desirable. I bet reverting these unordered_maps to map would restore the prior behavior.