Support basic objects as map centers

[tmcw]

map.setView({ lat: 43.6, lon: -79.4 }, 10);

Is currently not supported but be quite easily if L.LatLng accepted this kind of basic object as a parameter. I can pull together a pr for this if it seems fine.

[mourner]

Hmm, what's the use case? Just a bit more descriptive way to pass coordinates in the API?

[tmcw]

It simplifies the surface of the API by only requiring you to use one API call. That, or when you're calling map.setView from data, it's nice to be able to interact with it with as little transformation of the data as possible (my dream api for leaflet et all is just geojson literals everywhere)

[mourner]

You can currently do map.setView([43.6, -79.4], 10). So I assumed it's just an alternative way to write coords.

[tmcw]

Yeah - so like map.setView([43.6, -79.4], 10) has lat, lon order, unlike GeoJSON/KML/WKT, so it's a bit confusing (at least to me)

[uberbuilder]

This does make the code easier to read, and doesn't leave one to guess "Which is first - lat or lng?"

Just my 2¢...

[mourner]

Initially I adopted lat, lng because Google Maps used this order, and GeoJSON wasn't as established when I started creating map APIs.

If I add this signature, should I use lng instead of lon for consistency? Or should both be supported?

[uberbuilder]

IMHO: Both, unless someone else has some reason we shouldn't do this. As far as I know all of Leaflet's documentation uses lng (which I think is better) - so if you pick one - I vote for lng.

[tmcw]

I'm used to lon, since it's used in modest maps, polymaps, d3, and so on, but uniformity wins.

[uberbuilder]

Like I said, my opinion was humble, and has changed, thanks to @tmcw ;)

Now I'd say both for sure since there seams to be this larger standard for the term. lng for all leaflet junkies, lon for complying with everyone else. Some people use D3 in conjunction with leaflet, why not cater to those folks too?

[tmcw]

(to make life more complicated, the public API of d3 deals exclusively in two element arrays which are, you guessed it, in [lon, lat] order)

[uberbuilder]

@tmcw, that does complicate things... and I I think that in the interest of Leaflet they have to draw the line somewhere.

The beauty of adding an object context like this is it doesn't matter which comes first.

[mourner]

Like this?

[kcivey]

Google LatLng objects have .lat() and .lng(). Would it make sense to support those too, or is that a step too far?

[mourner]

It's not possible with current JavaScript to have a property that acts both as a number and as a function.

[kcivey]

Sure, but this would be accepting an object that could have either a number or a function, not both. I'm not talking about adding .lat() and .lng() to the Leaflet LatLng, just accepting a Google LatLng in the constructor. Something like

if (typeof a === 'object' && 'lat' in a) {
    return new L.LatLng(getValue(a, 'lat'), getValue(a, 'lng' in a ? 'lng' : 'lon'));
}

function getValue(obj, prop) {
    return typeof obj[prop] === 'function' ? obj.prop() : obj.prop;
}

[mourner]

I see, thanks! But are there actually any real world use cases for this?

[kcivey]

I don't know how common it is, but I had it come up recently. I had a position from a Google Street View panorama and wanted to use it to set a Leaflet map center. Of course it's not that hard to use [googleLatLng.lat(), googleLatLng.lng()], but it did mean creating an extra variable instead of just passing panorama.getPosition() directly.

[mourner]

I think it's pretty normal to use [googleLatLng.lat(), googleLatLng.lng()] instead of trying to account for all possible coordinate formats.

[kcivey]

Fair enough. I just thought Google LatLng objects might be more common than the objects that have .lat and .lng or .lon. But if I'm part of a tiny minority, it's definitely not worth adding.