Thanks for starting this Jon, the end result is going to be awesome. So here's how I see things, it's roughly along the lines of what you've been saying:
Server-side rendering and scaling is important. This is one of the main reasons I picked Vega [2] for my hack. The same visualization grammar can be used to generate png or svg [2]. I see the approach to visualization as being similar to Parsoid: * user creates a visualization (with a visual editor) and saves * Vega parses that server side and generates an image, then refreshes the caches accordingly * a transcluded visualization renders the image from cache as a link to the interactive version * when the link is clicked, something like MediaViewer shows the interactive visualization * alternatively, we can allow editors to show the interactive version in the transclusion itself, but that has performance implications until browser caches are filled. Now a little bit about where I see the Map namespace. A visualization in the world of Vega has three parts: * Data (one or more sets of data, can be geojson, topojson, tsv, csv, layers from OSM [3], OHM [4], etc.) * Transformations on that data (scales, normalization, etc.) * Marks (visual representations) Transformations and Marks can be written by hand or by a visual editor that introspects the specification to show what's possible. Data to me is the tricky part. We may need to restrict Vega to only consume open data that's hosted and curated by us, and that could be done in a few different ways: * Namespaces like the Maps namespace that enables awesome collaborative editing of geojson * Datasets in WikiData using an alternative data model * File namespace serving raw data from Commons (where people are familiar with take down notices and have the infrastructure to deal with that) But yes, I do see the Maps namespace as one of the sources of data that we could visualize with Vega. And recent developments in Vega make me feel that it's really a solid choice for generic visualization. We have interactivity, headless mode, a seemingly clear path to a visual editor via introspection of the grammar specification, and pretty much everything I can think of needing from such a tool. For the short term, I think further exploration of the Map namespace is great, but I think generic visualization work could go into the Visualization namespace. My suggestion for a name for this namespace may seem a bit obscure. It's a word that means "to illuminate": Limn [5]. There's an old project by that name of which I'm not very fond (despite writing some of it myself), but I've always thought the word was beautiful and fit. To what Antoine was saying earlier, we should illuminate the world's knowledge with beautiful visualizations. [1] https://github.com/trifacta/vega [2] https://github.com/trifacta/vega/wiki/Headless-Mode [3] OSM - Open Street Maps http://wiki.openstreetmap.org/wiki/Main_Page [4] OHM - Open Historical Maps http://wiki.openstreetmap.org/wiki/Open_Historical_Map [5] Limn - depict or describe in painting or words: https://github.com/wikimedia/mediawiki-extensions-Limn On Wed, May 14, 2014 at 9:43 AM, Jon Robson <jrob...@wikimedia.org> wrote: > Tim I completely agree. This is something we need to setup. > Patches very much welcomed! :-) > > > > On Wed, May 14, 2014 at 7:51 AM, Tim Alder <t...@alder-digital.de> wrote: > > I think the most important feature is to create on serverside a > > thumbnail for each map by using something like http://phantomjs.org/ > > This thumbnails should than be in the big WMF caches. The map would > > become interactively only in the case a user click on it. > > This would reduce the numbers of request for loading a page and JS > > overhead and it would increase the stability of the system. > > Without this feature I afraid to never see the extension live in > Wikipedia. > > > > Other nice features you can see at umap.openstreetmap.fr: > > *Choosing different backgrounds > > *POIs with interactive descriptions > > *Geometry import from OSM (WIWOSM) > > *different layers > > *... > > > > Greeting Tim alias Kolossos > > > > > > Am 14.05.2014 00:34, schrieb Jon Robson: > >> During the Zurich hackathon, DJ Hartman, Aude and I knocked up a > >> generic maps prototype extension [1]. We have noticed that many maps > >> like extensions keep popping up and believed it was time we > >> standardised on one that all these extensions could use so we share > >> data better. > >> > >> We took a look at all the existing use cases and tried to imagine what > >> such an extension would look like that wouldn't be too tied into a > >> specific use case. > >> > >> The extension we came up with was a map extension that introduces a > >> Map namespace where data for the map is stored in raw GeoJSON and can > >> be edited via a JavaScript map editor interface. It also allows the > >> inclusion of maps in wiki articles via a map template. > >> > >> Dan Andreescu also created a similar visualisation namespace which may > >> want to be folded into this as a map could be seen as a visualisation. > >> I invite Dan to comment on this with further details :-)! > >> > >> I'd be interested in people's thoughts around this extension. In > >> particular I'd be interested in the answer to the question "For my > >> usecase A what would the WikiMaps extension have to support for me to > >> use it". > >> > >> Thanks for your involvement in this discussion. Let's finally get a > >> maps extension up on a wikimedia box! > >> Jon > >> > >> [1] https://github.com/jdlrobson/WikiMaps > >> > >> _______________________________________________ > >> Maps-l mailing list > >> map...@lists.wikimedia.org > >> https://lists.wikimedia.org/mailman/listinfo/maps-l > >> > > > > > > _______________________________________________ > > Maps-l mailing list > > map...@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/maps-l > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
