Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!
FYI, Limn is also sort of taken in the MediaWiki/WMF namespace: https://www.mediawiki.org/wiki/Analytics/Limn Yep, but that Limn is dying slowly. If we do this new extension properly, it will take its place. As Erik said, this is not staffed for success right now but it would address many shared needs. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!
Update. There is now a Special:Map which when passed API parameters can construct a map from the corresponding API request. This would give us the opportunity to create maps around existing data. This would support a Nearby map view. See this link for more: http://wikimaps-ext.wmflabs.org/wiki/Making_maps_via_the_API All of this is very prototypal and can be removed if there is no need. I plan to get this off Github and on to Gerrit sometime next week. On Tue, May 20, 2014 at 6:48 PM, Dan Andreescu dandree...@wikimedia.org wrote: FYI, Limn is also sort of taken in the MediaWiki/WMF namespace: https://www.mediawiki.org/wiki/Analytics/Limn Yep, but that Limn is dying slowly. If we do this new extension properly, it will take its place. As Erik said, this is not staffed for success right now but it would address many shared needs. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!
On 05/14/2014 12:43 PM, Dan Andreescu wrote: * File namespace serving raw data from Commons (where people are familiar with take down notices and have the infrastructure to deal with that) We shouldn't let copyright considerations dictate which WMF project hosts the data. https://wikimediafoundation.org/wiki/Designated_agent covers all the projects. The WMF is responsible for handling official DMCA takedown notices (which means they should generally be covered by the Safe Harbor), However, editors (e.g. on Wikipedia, Commons, etc.) can and do take a proactive role in fighting copyright infringement above and beyond that. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!
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
Re: [Wikitech-l] [Maps-l] Output from Zurich Hackathon - yet another maps extension!
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
