marker support

[incanus]

Something I'd like to see is applying marker imagery points on the map, using a quad tree for efficiency, anti-rotating against angle changes to remain upright, and supporting z-indexing (markers closer to the bottom of the screen are in front of those closer to the top).

Basic POIs are done over in WebGL:

• POI markers & icons mapbox-gl-js#43
• https://github.com/mapbox/llmr/blob/master/js/render/drawpoint.js
• https://github.com/mapbox/llmr/blob/master/shaders/point.vertex.glsl
• https://github.com/mapbox/llmr/blob/master/shaders/point.fragment.glsl

What I want is the ability to replace this from the SDK:

https://dl.dropboxusercontent.com/u/575564/rotatepins.mov

I'm going to start working on this.

[kkaefer]

WebGL isn't using a quad tree.

[incanus]

Yeah, seeing this as I dig in. I will keep at this as a port over from current WebGL functionality, despite us possibly throwing this away as I'd like to get a bit more familiar with the whole style/bucket/parse/tag/vertex/shader/render flow we have for things like lines and fills.

After getting basic POI working, I'll look into arbitrary external content (GeoJSON/whatever) for drawing actual markers.

[incanus]

Getting there.

[incanus]

Breaking this down a bit:

• Get POI in the current stylesheet to render.
• Build out more POI in stylesheet as on WebGL.
• Handle arbitrary point data (GeoJSON etc.) with configurable markers.

[incanus]

First task done; next up is more Maki in the stylesheet, which hopefully looks better, then arbitrary data, which is a bigger hurdle.

[incanus]

Making progress on GeoJSON support. Most of the feature tiling is done. Will round that out + bucket parsing + rendering next.

[incanus]

Ok, parsing properly and rendering... almost properly. Problem is related to what @kkaefer is working on with universal clip id's so that we can have multiple sources overlaid.

Right now I only get masking in tiles where the route overlaps, but then don't get the baselayer actually drawing there (exclusive clip id's):

I'm going to get #167 merged into master, then break this out into another pull that depends on the clip id work before getting merged.

But basically at this point we can throw arbitrary GeoJSON LineString features into llmr-native and have them pre-tiled and just about rendered.

[incanus]

Closing in favor of #170.