Vega Tile Maps (Vega API wrapper around OpenLayers)

[Erik Anderson]

Hi everyone.

I am the R&D Lead for Data Visualization at Bloomberg in New York City.

Been a follower of Vega for 3 years (or so). Now a lover because of the reactive interface so thank you Jeff Heer and team. Great work on the Vega API. A good API is much harder to develop than drawing some pixels to a screen.

Question for the group, Maps. Real maps support in Vega.

This would require adding a new widget type to the vega schema (or marks type)

1) This will allow you to consume general raster tiles generated by NASA, USGS, Open Street Maps, CartoDB, Mapbox, etc.

2) Later will add vector tile support for like mapzen vector tiles (vector tiles will require WebGL though)

More than happy to write up a proposal but I dont want to waste my time if the community doesnt want a feature like this.

Thoughts?

Erik Anderson
Bloomberg

[Enrico Spinielli]

Very interesting feature, but IMHO componentisability (is it English of some sort?) is a more pressing need...

Regards

Enrico Spinielli

--
You received this message because you are subscribed to the Google Groups "vega-js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vega-js+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Erik Anderson]

componentisability? No google hits on that word.

Abstract idea around what ability a component exposes?

Thx in advance,
Erik Anderson

[Yuri Astrakhan]

I would love for this to happen - I am leading both the graphs and the maps projects at Wikipedia, and i feel they have a lot in common. I would like to offer our editing community a way to add more data to the tiles (some ideas), should support various POI popups and region highlighting, but also blend in the data processing pipeline and visualizations from Vega.

P.S. We have been looking at Leaflet rather than OpenLayers for its mobile support and compactness, but this hasn't been finalized.

[Arvind Satyanarayan]

Hi Erik,

I'd definitely be interested in hearing more, particularly as I don't know much about how to support real maps. For example, one immediate question I'd have is could we extend the built-in image mark type rather than introducing a new one? https://github.com/vega/vega/wiki/Marks#image. 

As has been mentioned in a few other threads, we're working on creating a plugin infrastructure for Vega. A new "map tile" mark type sounds like a great candidate for a plugin!

-Arvind

[Enrico Spinielli]

yes, new lingo ;-)

IMHO we need to be able to build components out of pieces of Vega specs and combine them together for the final visualization.

It already started with the first implementation of the signals and the attempt to make them reusable, see the original Reactive Vega article.

Bye

Enrico

[Erik Anderson]

On Tuesday, November 17, 2015 at 7:32:29 PM UTC-5, Yuri Astrakhan wrote:

> I would love for this to happen - I am leading both the graphs and the maps projects at Wikipedia, and i feel they have a lot in common.

> I would like to offer our editing community a way to add more data to the tiles (some ideas), should support various POI popups and region

> highlighting, but also blend in the data processing pipeline and visualizations from Vega.

> P.S. We have been looking at Leaflet rather than OpenLayers for its mobile support and compactness, but this hasn't been finalized.

Yuri, Leaflet is great when you want to do something simple. The API is easier. Since I need to solve business cases around analytics, leaflet just wont cut it. Also, try and zoom into a map with leaflet vs openlayers. Openlayers handles the transitions perfectly.

Yuri, didnt we meet at UN building for Open Street Maps here in New York City? I am pretty sure we met as I never forget a face. I believe I introduced you to our Maps business manager at Bloomberg.

> On Wednesday, November 18, 2015 at 4:15:32 AM UTC-5, Enrico Spinielli wrote:

> yes, new lingo ;-)

> IMHO we need to be able to build components out of pieces of Vega specs and combine them together for the final visualization.

> It already started with the first implementation of the signals and the attempt to make them reusable, see the original Reactive Vega article.

Enrico, I am very familiar with the Vega 2 reactive grammar. Jeff Heer forwarded me the white paper several months ago. This reactive feature has the potential to allow me to create a visualization out of different visual component all via a grammer.

Internal to Bloomberg we call these "vislets". Basic reusable building blocks of a visualization. Example:

1) Legend window

2) Axis

3) A line on a chart

Would love to have a call about this. I think Vega should be the defacto way to create bindings between data, and vislet primitives to create an overall visualization.

In addition, W3C has tried to create a way to standardize data visualizations on the internet. Vega could be that standard.

I have data vis developers that can start working on this immediately if we can iron out the details.

> Arvind Satyanarayan

Would love to hear more about the plugin interface. Plugins always sound like a great idea but always falls short of expectations. Code is easy but designing interfaces that dont suck is the real hard work. I would rather see a "tile mark" as a core part of Vega that supports interactivity between Maps and other visualizations. The interconnetivity and interactivity are the core business needs that I intend to solve.

Erik Anderson

Bloomberg

[Yuri Astrakhan]

On Mon, Nov 23, 2015 at 5:15 PM, Erik Anderson <xdpr...@gmail.com> wrote:

Yuri, Leaflet is great when you want to do something simple. The API is easier. Since I need to solve business cases around analytics, leaflet just wont cut it. Also, try and zoom into a map with leaflet vs openlayers. Openlayers handles the transitions perfectly.

 

Good to know, thanks.  My biggest concern is with feature vs size balance: for each map, the client should get only the modules needed for that map - if every Wikipedia article starts sending the entire OpenLayers lib, we might double the traffic. OL3 seems to be module based, but also encourages custom compilation, which I will need to explore.

 

Yuri, didnt we meet at UN building for Open Street Maps here in New York City? I am pretty sure we met as I never forget a face. I believe I introduced you to our Maps business manager at Bloomberg.

Yes, we met at the state of the map )) 

In addition, W3C has tried to create a way to standardize data visualizations on the internet. Vega could be that standard.

I have data vis developers that can start working on this immediately if we can iron out the details.

There are a few aspects I feel we should iron out before standardization:

* The current error handling is basically "log to console and ignore", which is not good for server-side rendering, or when hosting code needs greater control. My code patch with @jheer's help addresses that, but i feel we need to formalize it further.

* I also feel we should adapt JS promises for all async calls - all major browsers supports it, and it greatly simplifies both the internal implementation and the way the code is used.

* Modularization - Vega code keeps growing in size, which is bad for slow connections and device power consumption.  Ideally we should have a way for Vega to load just the components it needs, e.g. a bar graph should not load geo projections code.

[Jeffrey Heer]

Thanks all for the input!

We'd love to add richer map support at both the Vega and Vega-Lite levels, but still need to plot out an ideal path. My current sensibility is to keep things cleanly decoupled. I would prefer Vega/Vega-Lite to not have a direct concept of a tile provider, but instead use something more along the lines of vega-embed or some other external coordinator. That way changes in the map tile layer (whether it be Leaflet, Open Layers, Google Maps, etc) could propagate as signals triggering appropriate updates in the Vega view (or vice versa). Still, that is just an inclination and I'd love to see more concrete proposals on how to proceed.

Erik -- I'm excited to hear that you might be willing to allocate some engineering cycles for Vega related projects. If you'd like to shoot me a direct email perhaps we can schedule a call to talk more?

-jeff

--

You received this message because you are subscribed to the Google Groups "vega-js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vega-js+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Download free Trifacta Wrangler today!