openstreetmap / iD

🆔 The easy-to-use OpenStreetMap editor in JavaScript.
https://www.openstreetmap.org/edit?editor=id
ISC License
3.34k stars 1.2k forks source link

Allow some kind of "over-zoom" on ESRI World Imagery #4327

Closed mboeringa closed 7 years ago

mboeringa commented 7 years ago

While a nice addition to iD and other editors, the ESRI World Imagery seems not to be available in some of the highest zoom levels possible with iD. If you zoom in to far in a certain region, you end up with grey tiles with an error text "Map data not yet available" visible in the editor.

This somewhat limits the usefulness of this imagery layer, compared to e.g. Bing, where I have never witnessed this behaviour.

Actually, it seems to depend on the specific spot as to what zoomlevel you still get imagery, e.g. I have seen the imagery being replaced by the warning at Z19 or 20 in different locations.

I have no idea if it is possible to detect this based on the imagery service, but it would be kind of nice if iD allowed for some form of "over-zoom" on the ESRI layer, never showing the warning, but instead showing enlarged / interpolated (but blurred) tiles of the last available zoom levels.

Of course, the quality will suffer, but at least you would still have some guidance when zooming and trying to make some edit.

afbeelding

bhousel commented 7 years ago

I don't think there is much we can do with this, as the server returns a valid response for those zooms, and iD can't really tell whether the tile has imagery in it or not. If we received an error response, like a 404 or something, iD would lookup to a lower zoom and overzoom it.

bhousel commented 7 years ago

cc @jgravois for ideas - we might be able to use their metadata service (see #4280) to know which zooms will return imagery, but that's a bunch of extra lookups I'd rather avoid.

jgravois commented 7 years ago

thanks for pointing out the issue @mboeringa!

We could have locked the Esri Imagery at zoom level 19 and overzoomed everything beyond that (like the DigitialGlobe and Mapbox layers) but I made a concious decision to allow requests all the way to 22 because we do serve higher resolution stuff in some areas.

The downside of the current implementation is, as you noted, that imagery is lost entirely as soon as the highest native zoom is exceeded. it would be a substantial improvement to overzoom selectively.

We have a couple options here:

  1. from @bhousel's reply, it sounds like tacking on ?blankTile=false might be sufficient all on its own to leverage logic already present in iD 1

  2. we could check ETags instead of appending the discouraged parameter above in a similar effort to intercept blank tiles.

  3. at closer zooms, we could make requests to the service's associated tilemap to determine whether individual tiles are present. this is an optimization, the most complicated option and what is done in other ArcGIS clients. that said, i fully support @bhousel's desire to keep it simple.

1 More info about the use of tilemaps, ETags and a recommendation to not use blankTile=false can be found in the article below

https://developers.arcgis.com/documentation/tiled-elevation-service/#detecting-missing-tiles-on-esri-tiled-basemap-and-elevation-servers

related: https://github.com/Esri/esri-leaflet/issues/240

mboeringa commented 7 years ago

@bhousel , @jgravois

How does JOSM solve this? If I zoom in at a zoomlevel that does not exist (both the ESRI layer and Bing), JOSM initially shows an error, but then happily loads the correct image of the highest zoom with larger "pixels". This happens both on the ESRI World Imagery layer, and for Bing:

afbeelding

afbeelding

bhousel commented 7 years ago

from @bhousel's reply, it sounds like tacking on ?blankTile=false might be sufficient all on its own to leverage logic already present in iD 1

Nice! I'll try this first, thanks @jgravois..

bhousel commented 7 years ago

Adding ?blankTile=false did the trick 👍

mboeringa commented 7 years ago

Great! So that's going to be part of the next roll out of changes to iD?

bhousel commented 7 years ago

Yes!

jgravois commented 7 years ago

:saxophone:

jjiglesiasg commented 6 years ago

I would be more than happy if ID allow zoom level edition of ANY Imaginary above the 400 meters high. I use and love ID over JOSM and Potlatch but mapping large areas with 400 meters height of view is almost impossible. In Bolivia we have really large areas of parks and naturals that exceed by far the 400 meters level

runrun1234 commented 5 years ago

Any idea why Strava heatmap disappear when zoom > 16 ? I would like to have some overzoom like with other imagery sources. I am using https://heatmap-external-{switch:a,b,c}.strava.com/tiles-auth/ride/hot/{zoom}/{x}/{y}.png?px=256&Key-Pair-Id=xxx&Policy=yyy&Signature=zzz

I tried adding &blankTile=false without success... (I know that current status about Strava heatmap and tracing allowance is no clear, but this does not answer to the question "why nothing beyond zoom 16 ?")

bhousel commented 5 years ago

Any idea why Strava heatmap disappear when zoom > 16 ? I would like to have some overzoom like with other imagery sources.

I'm not sure.. You could open the developer console and see what responses you get from their tile server. If it returns things like 4xx or 5xx errors, it means that there is no imagery at that zoom.

I tried adding &blankTile=false without success...

Yeah, that's something that works only for the Esri tile servers.

runrun1234 commented 5 years ago

According to Firefox developer console (that I opened the first time in my life yesterday to get those Key-Pair-Id and so on...) it seems like I get "empty" tiles of 1.20 kB each...