Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add DigitalGlobe imagery vintage overlays #371

Closed
bhousel opened this issue Nov 1, 2017 · 6 comments
Closed

Add DigitalGlobe imagery vintage overlays #371

bhousel opened this issue Nov 1, 2017 · 6 comments
Labels

Comments

@bhousel
Copy link
Member

bhousel commented Nov 1, 2017

DigitalGlobe has put together some raster overlay layers which display the imagery vintage for the DigitalGlobe Premium and DigitalGlobe standard layers. The layers show the boundaries of the imagery sources, and at zooms 14 and above, some text labels showing when the imagery was captured.

Currently this is a "beta", and we're thinking of ways to improve the visibility of the labels at higher zooms. (The labels are sparsely distributed, because they were placed along z11 tile boundaries, so they are easy to miss).

Here's what it looks like:
digitalglobe-vintage

@bhousel bhousel added the imagery label Nov 1, 2017
@bhousel
Copy link
Member Author

bhousel commented Nov 1, 2017

cc @kevinbullock & @marracci who may be able to answer any questions that people have 👍

@bhousel bhousel closed this as completed in 9194844 Nov 1, 2017
@imagico
Copy link
Contributor

imagico commented Nov 1, 2017

The information is certainly most welcome but having this as a raster layer is technically not ideal. The editors cannot easily interpret this information to for example suggest to the user which image might be outdated. Having this data available as tile metadata like in case of Bing or as a (tiled) vector data set would have many advantages - including better options for zoom independent rendering.

Looking over the data in a few places it seems the dates for the premium layer are often of questionable validity (mostly through the there is no way this image was taken at that time of year test). You can also see clear cutlines in the image layer that are not represented in the vintage overlay.

bhousel added a commit to openstreetmap/iD that referenced this issue Nov 1, 2017
@bhousel
Copy link
Member Author

bhousel commented Nov 1, 2017

The information is certainly most welcome but having this as a raster layer is technically not ideal. The editors cannot easily interpret this information to for example suggest to the user which image might be outdated.

Yes @imagico - ideally we'll eventually be able to store this in a vector tile layer or something similarly machine readable. Anyway for now, consider it a beta release. 😄

The issue of selecting the best imagery layer in the editor has always been a bit of a hack. We have a "best" flag in the editor-layer-index, but now with Bing, DG Premium, DG Standard, Esri, and Mapbox, and whatever local ortho layers exist, the situation has become a lot more complicated. All of the layers have different strengths and weaknesses.

Also worth mentioning, I believe the reported vintage dates only make sense at z13+ where the mosaic kicks in. (lower zooms seem to show a cleaned up Landsat imagery, similar to Mapbox Satellite)

For anyone who wants to see what the DigitalGlobe vintage overlay layers look like, you can try it out on the preview iD instance here: http://preview.ideditor.com/master/#background=DigitalGlobe-Standard

To toggle the overlays, make sure you have one of the DigitalGlobe layers active, then open the "Background" info panel:
⌘ Cmd+⇧ Shift+B (Mac)
or
Ctrl+⇧ Shift+B (Win/Linux)

Then click "Show Vintage" button in the panel. (This button is only available if you have a DigitalGlobe layer active).

Here is another screenshot:
screenshot 2017-11-01 14 08 41

@marracci
Copy link

marracci commented Nov 3, 2017

Thanks @imagico for your question/comment and also @bhousel for the follow up on this.

We are working to provide a higher-quality vintage overlay for our DigitalGlobe Premium Imagery layer. I expect this to be available in the next week or so, seamlessly. I'll make note of it here in the issue comments when released.

As @bhousel mentioned, this is still in beta as we continue to work through best options for displaying the labels as well as adding more clarity on dates collected.

@marracci
Copy link

marracci commented Nov 7, 2017

Hi @bhousel @imagico - we've updated our vintage display for DigitalGlobe Premium Imagery over the weekend, notably that we have introduced more granularity. Vintage overlay for DigitalGlobe Standard Imagery has remained unchanged, and both layers should still be considered as beta.

DigitalGlobe Standard and Premium imagery vintage overlays are best displayed at z13 and larger.

This update has been seamlessly published, try it out on the preview iD instance:

Our first version of DigitalGlobe Premium Imagery vintage contained polygons and metadata broken into small-scale 'partitions' or cells, whereas this update now contains large-scale vintage cells which will give users more detail than previously.

Original DigitalGlobe Premium Imagery vintage cells:
snip20171107_1

Updated DigitalGlobe Premium Imagery vintage cells:
snip20171107_3

As @bhousel points out, there is a distinct difference between the two DigitalGlobe imagery layers in OSM iD:

  • DigitalGlobe Standard is a collection of color satellite imagery strips sorted according to imagery collection date (vintage). This layer is best for getting a recent view of the earth. The imagery vintage boundaries reflect the layout/ordering of those scenes.
  • DigitalGlobe Premium is color satellite imagery that has been processed (color-balanced and mosaicked) across regional geographies. Note that this imagery vintage is broken into discrete squares (partitions/cells), reflecting our imagery processing and output.

@imagico
Copy link
Contributor

imagico commented Nov 8, 2017

I took a look - the cells you specify the date for are about 7x10km at central European latitudes - which is still fairly coarse for areas with fine grained image combinations. An example:

http://preview.ideditor.com/master/#background=DigitalGlobe-Premium&disable_features=boundaries&map=13.56/46.8169/10.2369

which is specified as 2013-10-25. That is clearly not correct here - a late October image is what you see 10km to the south of that location.

I will take a wild guess and say that the date you specify is probably the newest image used in the image assembly process within the cell. 90 percent of the cell might actually show a different image.

My assessment is that the cell size would be OK if you specify either the majority date of the cell or the date of the image at the cell center. But with the current logic you would need a much smaller cell size if you want to avoid the date being wrong in the majority of cases in areas like the above.

I will take another wild guess and assume that you only have the footprints of the images used and do not have access to the data from the actual assembly process (i.e. which image exactly is used at what location) which would make my suggestion above a bit pointless since you would not know which images are actually used. And smaller cells would not help. But i hope i am wrong about that one...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants