Allow '{-y}' placeholder

[fredj]

No description provided.

[fredj]

The coordinate computation is done in a function for performance reason: the value is only computed if the url contains {-y}

[stoecker]

Why pow()? Shift operation should be MUCH faster.

[tonio]

Why pow()? Shift operation should be MUCH faster.

Looks like it’s only true on mobile: http://jsperf.com/math-pow-vs-bit-shift

[fredj]

Math.pow replaced by shift because it's usually faster (and saves 8 characters ...)

[ahocevar]

Looks good now.

[tschaub]

Post merge review:

It looks to me like this {-y} thing is for TMS which I think should be a different source type. If Yahoo! has a different addressing convention, that would be a third source type (not a third variant of the template syntax). I think this change clouds the meaning of ol.source.XYZ and I don't think our main XYZ example should use the "non-standard" (or less conventional) addressing scheme (this would instead be a separate TMS example).

At a minimum, documentation should be added here. It should clearly explain when to use a different template syntax and when to use a different source type.

[stoecker]

Yahoo actually is not really relevant anymore. They switch to the standard {y} with newer services - no need to care about that anymore. {-y} is not really a different source type, but simply counting starts at the south pole instead on the north pole. Everything is the same - It does not really verify a new source type for that.

I though source.XYZ is TMS now for OL3, otherwise I wonder why there is no TMS at all anymore, because all these example using XYZ actually are accessing TMS services.

[fredj]

@ahocevar you're right; the {-y} handling should be moved to ol.source.TMS:

new ol.layer.Tile({
  source: new ol.source.TMS({
    url: 'http://www.maptiler.org/example-usgs-drg-grand-canyon-gtiff/{z}/{x}/{y}.png'
  })
})

And in this context (ol.source.TMS) {y} will be (1 << tileCoord.z) - tileCoord.y - 1.

[stoecker]

No. That's wrong! TMS Does not mean OSGeo-Format! There are TMS using counting starting on north pole (i.e. Google style) and some others start counting on south pole (OSGeo style). What you propose is to have the more uncommon format named as TMS. That's simply wrong. If you rename it TMS, then you still need to support {y} and {-y}.

This is not a new service type, but actually a new tile coordinate system. As such thing as a tile coordinate system is not supported ATM and inventing one would be overkill I propose to use the current solution, which is easy and pretty straightforward (and I'm aware, that it is not 100% clean design, but who needs that).

[ahocevar]

@stoecker In OpenLayers 2, TMS is what you refer to as 'OSGeo style', and XYZ is what you refer to as 'Google style'. And it is not north vs. south pole, it is top-left vs. bottom-left corner.

Since our 'XYZ' source uses a coordinate system with x (tile index from left), y (tile index from top) and z (zoom level), I think it is fair to say that TMS is just a flavor of XYZ, with the difference that y is the tile index from the bottom.

Personally I find the {-y} notation very convenient, and since XYZ is a term not pre-occupied by any standard or convention, I'm not opposed to keeping these two flavors in ol.source.XYZ. But I agree with @tschaub that this needs to be documented, and that the XYZ example should use tiles from a service that counts y from the top, and a new TMS example should show the use of the {-y} option.