Codecov Report

❌ Patch coverage is80.76923% with5 lines in your changes missing coverage. Please review.
⚠️ Pleaseupload report for BASE (branch-3.9@db2574a).Learn more about missing BASE report.

@@              Coverage Diff              @@##             branch-3.9   #14656   +/-   ##=============================================  Coverage              ?   91.82%           =============================================  Files                 ?      288             Lines                 ?    20786             Branches              ?        0           =============================================  Hits                  ?    19086             Misses                ?     1700             Partials              ?        0

I left a few initial comments. I am not sure I thrilled about making users explicitly coordinate

x_axis_type="mercator_lon", y_axis_type="mercator_lat"

It seem like it would be super easy for users to supply these backwards.

I had always previously envisioned this as an input and formatting issue... i.e. we'd keep the existing mercator machinery always working in terms of meters (northings and eastings) but make it so that "lat/lon" inputs were understood and would set an (overrideable) config automatically.

I left a few initial comments. I am not sure I thrilled about making users explicitly coordinate

x_axis_type="mercator_lon", y_axis_type="mercator_lat"

It seem like it would be super easy for users to supply these backwards.

I had always previously envisioned this as an input and formatting issue... i.e. we'd keep the existing mercator machinery always working in terms of meters (northings and eastings) but make it so that "lat/lon" inputs were understood and would set an (overrideable) config automatically.

I agree that this is certainly not a good solution. However I'm not sure about other good options that help with knowing what data to expect. Do you think about this config as an additional keyword argument of the figure class describing the data coordinate system?
Setting this config automatically and reliable based on the data is a bit tricky. Of course the lat/lon limits are much smaller compared to the meter limits however in edge cases they will overlap. Additionally this is also not only about the data but also the range, as they might also contract themselves. Realistically I think this requires switching to lat/lon as the default input while trying to understand if data input or range is in meters. As far as I know most real world data deals with lat/lon values instead of meters from the web mercator projection.
I also thought about keeping the mercator machinery in meter/untouched but as you can see with I decided against it (at least partially, tile fetching is still done completely with meters). If I understand your point correctly, you have transformation of the data in mind instead of the transformation of the axis/scale (as in this PR)? I think the former is much more complex and will make debugging a nightmare.

ping@philippjfr@jbednar etc for geoviews thoughs.

Currently the mercator axis expects data as web mercator coordinates (EPSG: 3857). Most real world datasets are however available as lat-long coordinates (EPSG: 4326) and therefore cannot be used directly.

I'd love to see this natively supported in Bokeh! Wondering the reason behind naming itmercator_lon instead oflon, e.g.
p = figure(x_range=(-30, 30), y_range=(-40, 40), x_axis_type="lon", y_axis_type="lat")

Dumb question, but does this allow mixing mercator tiles with lon/lat data? i.e. would I be able to get away with using lon/lat data in this without ll2en (lon_lat_to_easting_northing) called? I suspect not?

https://examples.holoviz.org/gallery/ship_traffic/ship_traffic.html#us-ais-vessel-traffic-data-jan-2020

If I understand your point correctly, you have transformation of the data in mind instead of the transformation of the axis/scale (as in this PR)? I think the former is much more complex and will make debugging a nightmare.

Oh I see. I think this is still useful.

Currently the mercator axis expects data as web mercator coordinates (EPSG: 3857). Most real world datasets are however available as lat-long coordinates (EPSG: 4326) and therefore cannot be used directly.

I'd love to see this natively supported in Bokeh! Wondering the reason behind naming itmercator_lon instead oflon, e.g.p = figure(x_range=(-30, 30), y_range=(-40, 40), x_axis_type="lon", y_axis_type="lat")

There is no strong reason behind this. Based on the previous comment the API is still undecided anyway.

Dumb question, but does this allow mixing mercator tiles with lon/lat data? i.e. would I be able to get away with using lon/lat data in this without ll2en (lon_lat_to_easting_northing) called? I suspect not?

https://examples.holoviz.org/gallery/ship_traffic/ship_traffic.html#us-ais-vessel-traffic-data-jan-2020

If I understand your point correctly, you have transformation of the data in mind instead of the transformation of the axis/scale (as in this PR)? I think the former is much more complex and will make debugging a nightmare.

Oh I see. I think this is still useful.

@ahuang11 My wording was probably not precise here. With "the data" I was basically referring to any data except for tile data as the latter is handled internally anyway. Therefore this PR indeed targets to support both tiles as well as "external" coordinate data. The idea is to get rid of the upfront data conversions.