Tormi Tabor tormi

There are a bunch of reasons why this is convoluted, mostly in building the URL to make the request:

You have to rely on an AJAX request, this example uses jQuery
To make a GetFeatureInfo request, you must provide a BBOX for a image, and the pixel coordinates for the part of the image that you want info from. A couple of squirrely lines of Leaflet code can give you that.
Output formats. The info_format parameter in the request. We don't know a priori which will be supported by a WMS that we might make a request to. See Geoserver's docs for what formats are available from Geoserver. That won't be the same from WMS to WMS, however.
WMS services return XML docs when there's a mistake in the request or in processing. This sends an HTTP 200, which jQuery doesn't think is an error.

Moral Concerns

JSONP is not actually JSON with padding, it's Javascript code that's executed. JSON is not a real subset of Javascript and the way it is not is important to us: via UTFGrid, we are all UTF-8 masters.

JSONP is not safe: it's Javascript that's executed. It's trivial to XSS with JSONP, because JSONP is XSS. Just have a call like mapbox.load('foo.tilejson', …) and if foo.tilejson gets replaced with destroyYoursite(), it gets run. Compare to JSON.parse, which is, on purpose, not eval.

Practical Concerns

JSONP is questionable in terms of performance. To be fast, you want to have the same callback all the time so that you can cache the response. But this leads to a page like

I had previously implemented a basic styling interface, but dropped it for the time being, because of a few factors:

No established standard for GeoJSON styling (GeoJSON CSS is a flawed spec without any implementations)
The focus of GeoJSON.io is data, not styling
A styling interface is likely its own thing.

Basically, given that GeoJSON is taken as the language of the site, I don't want to create expectations of compatibility that won't stand - if I invent some styling language, people will expect it to work, or at least be supportable, outside of the editor, and this promise will quickly be broken. I think conceptually the way to 'fix this' is to tie styling strongly to a publish interface that can make that guarantee, and write implementations in d3/openlayers/leaflet/etc for the language if/when it exists.

A bit of a big task :) The experience of working on CartoCSS has given me a bit of appreciation/fear of the area of styling languages in general and I think they should diverge from CSS a bi

	var fs = require("fs");
	var path = require("path");
	var _ = require("lodash");
	var utf8 = require('utf8');
	require("natural-compare-lite");

	var IGNORE = [
	"node_modules",
	".git",
	"SUMMARY.md",

	SELECT n.title, SUM(w.count) as total
	FROM project_usage_week_release w
	INNER JOIN field_data_field_release_project r ON w.nid = r.entity_id
	INNER JOIN node n ON n.nid = r.field_release_project_target_id
	INNER JOIN
	field_data_field_release_version v ON v.entity_id = r.entity_id
	WHERE LEFT(v.field_release_version_value, 3) = '7.x'
	AND FROM_UNIXTIME(w.timestamp) BETWEEN CURDATE()-INTERVAL 2 WEEK AND CURDATE()
	GROUP BY n.title
	ORDER BY total DESC;

	<?php
	/**
	* Implementation of hook_drush_command().
	*
	* In this hook, you specify which commands your
	* drush module makes available, what it does and
	* description.
	*
	* Notice how this structure closely resembles how
	* you define menu hooks.

	/**
	* This file is licensed under Creative Commons Zero (CC0)
	* http://creativecommons.org/publicdomain/zero/1.0/
	* Source: https://github.com/shramov/leaflet-plugins/issues/59
	*/

	L.Control.Permalink.include({

	initialize_overlay: function() {
	this.on('update', this._set_overlays, this);

	<?php
	$ch = curl_init($_GET['url']);
	curl_setopt($ch, CURLOPT_HEADER, 0);
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
	$output = curl_exec($ch);
	curl_close($ch);
	echo $output;
	?>