Skip to content

Geo Ramblings

Jump to bottom
Sarah Bird edited this page Nov 17, 2015 · 7 revisions

Things to make Geo usable

  • patches with hole (we can't support patch)
  • plot projections (at which level do we coordinate this - a concern of frame?)
  • mapped axes (so can display lat lon when plot is projected)
  • color map
  • fixed aspect ratio ranges (i think this will solve resize and wheel zoom isues)
  • +/- zoom (with some kind of controllable rate - would feed back into tilerenderer)

Slightly less important:

  • remote geojson data source (pass in a geojson url) - easy win i think
  • hover gets gross on things like zommed in states - may want a fixed position over interaction
  • topojson (ok to deprioritize - but it's a pretty useful thing and I don't think that hard to support)

Less important:

  • axes in Degrees/Minutes/Seconds
  • Handle MultiPoint now or later

Renderers & Non-columnar data sources

Non-columnar GlyphRenderers

Right now, there seem to be not clean breaks between Glyph and GlyphRenderer, and it accesses implicitly columnar data. e.g. Glyph "maps data" (by calling GlyphRenderer method) and every render method has for i in indices.

Proposed separation of concerns (broad brush strokes):

  • A data source understands its own data structure
  • A glyph knows how to render itself
  • A glyph renderer connects / coordinates a data source, a glyph (and has knowledge of the plot).

I think the sequence of things should be something like:

  • GlyphRenderer should be handing Glyph an iterable of things to render
  • DataSource should produce an iterable of its data
  • GlyphRenderer will convert this to screen units, with knowledge of plot's frame

GeoJSONGlyphRenderer

GeoJSON without GeoJSONGlyphRenderer

If we had the above connection between DataSource, Glyph, and GlyphRenderer I still don't think you need a GeoJSONGlyphRenderer, what would be different would be the implementation of the data source which would be handing back an iterable of its data for Bokeh to handle.

Use case for GeoJSONGlyphRenderer

The use case I can imagine for a GeoJSONRenderer is when you want to do something like:

plot.add_geo_glyph(geojson_source, circle, geometry_types=['Point'])
plot.add_geo_glyph(geojson_source, multi_line, geometry_types=['MultLineString', 'Polygon'])

In the same way that GlyphRenderer creates a shadow decimated_glyph; GeoJSONGlyphRenderer would create, if needed, shadow GeoJSONDataSources point_source, multi_line_source, polygon_source etc. The GeoJSONGlyphRenderer would keep track of:

  • updating selections (if a set of circles was selected, then the selection would be reflected on the shadow data source and the main one that the user passed down).
  • if the user updated the main data source, the shadow data sources would be updated too etc.

We could make this transparent like we do with selection_glyphs and nonselection_glyphs or shadow like decimated_glyph. Personally I think shadow is better because it keeps the API cleaner and I can't think of anything a user would want to change - it's just a behind the scenes filter.

Next steps

  • build a GeoJSONColumnDataSource gives us a quick win into existing machinery, and lets us focus on building out other things to make geo usable

  • re-factor glyph renderer as described above

  • coordinating data sources

  • mappers - done through Spec.

  • expose 2d mapping you want on python side (complicated becasue ranges are on mappers)

Clone this wiki locally