OpenStreetMap
DigitalGlobe Satellite Imagery Launch for OpenStreetMap
Posted by @kevin_bullock on 9 May 2017 in English.Over the past few years, as I’ve attended State of the Map conferences, I’m consistently asked about satellite imagery: how it’s processed, accuracy, coverage, availability, resolution etc. I appreciate the fact that OpenStreetMap contributors are curious experts when it comes to satellite and aerial imagery. The reoccurring theme is: accurate, high-resolution and up-to-date satellite imagery is an essential component for improving this continuously evolving map of our planet – whether it’s to trace new features or to use as a reference layer for validation. Over the past few months, we have been working with several of our partners that share the common goal of improving OpenStreetMap. To that end, they have generously funded the launch of a global imagery service powered by DigitalGlobe Maps API. This will open more data and more imagery to help aid OSM editing for OSM contributors. OSM contributors will see a new imagery source in addition to imagery being provided by our partners Bing and Mapbox. You will now see the following two image services from DigitalGlobe:
DigitalGlobe-Premium is a mosaic composed of DigitalGlobe basemap with select regions filled with +Vivid or custom area of interest imagery, 50cm resolution or better, and refreshed more frequently with ongoing updates
DigitalGlobe-Standard is a curated set of imagery covering 86% of the earth’s landmass, with 30-60cm or resolution where available, backfilled by Landsat. Average age is 2.31 years, with some areas updated 2x year.
We anticipate there will be questions and feedback and want to make sure they are being addressed. We already have an active forum with FAQs here https://mapsapidocs.digitalglobe.com/discuss. This post is replicated on OSM Forum and I’m available on OSM help or you can hit me up directly with any additional questions. We are working to provide metadata (image acquisition date) for all of the imagery provided. This will be a huge tool for OSM mappers. We are also going to post the imagery specification.
We appreciate the OSM community’s awareness and diligence for licensing, so we wanted to be clear on the intended uses for this service. We have a short human readable EULA to summarize terms for editing OpenStreetMap :
DigitalGlobe Satellite EULA: DigitalGlobe, Inc. is pleased to provide its high resolution satellite imagery to OpenStreetMap in support of its mapping initiatives. By using our imagery in the OSM editor, you understand and agree that you may only use our imagery to trace, and validate edits that must be contributed back to OSM. You cannot download our imagery or use our imagery for any other purpose. We retain all right, title and interest in and to our imagery. We provide our imagery “as is,” with all faults and as available; we disclaim all warranties, express or implied, to the extent permitted by applicable law. You can recover from us only direct damages up to an amount equal to the fees you have paid to us to use our imagery on OSM, if any. We are not liable for any other damages, including consequential, lost profits, special, indirect, incidental or punitive damages. Happy mapping!
Attribution should be source=DigitalGlobe
DG Blog post: http://blog.digitalglobe.com/news/digitalglobe-satellite-imagery-launch-for-openstreetmap/
Sincerely, Kevin Bullock
Discussion
Comment from imagico on 9 May 2017 at 17:09
This is great news, thanks to DG and supporters for making this possible.
A quick look at the imagery indicates there is quite a lot of useful stuff in there - even if there is obviously a lot of overlap with imagery we already know from Bing and Mapbox there are also images were existing sources provide nothing of comparable resolution and furthermore there are many areas where having an additional, different image is useful for verification.
Two quick observations from looking over the new layers at a few places:
Comment from @kevin_bullock on 9 May 2017 at 17:21
thank you imagico for the feedback!
Comment from imagico on 9 May 2017 at 18:10
zoom levels: Yes, ideally all levels of course but practically adding z12 and z11 would already be good.
imagery offsets:
Most extreme case i remember was in the Lyngen Alps - around here: http://www.openstreetmap.org/#map=11/69.8068/20.1802
Differences with the same image source can be found here: http://www.openstreetmap.org/#map=13/62.5597/8.1576
Here i get ~50m difference even at sea level: http://www.openstreetmap.org/#map=13/70.1720/22.2797
I know these are pretty nasty areas due to steep relief but i generally would expect at least no larger differences with the same image basis (i.e. the same viewing direction) unless you changed the relief data basis. Offset at sea level to me also indicates insufficient quality relief data.
metadata:
Sorry i read over that part. Looking forward to it.
By the way i forgot to mention: Good to see you were able to keep the terms of use fairly plain and simple so you can actually read them without getting a headache.
Comment from @kevin_bullock on 9 May 2017 at 18:33
Thanks for the links to the offsets. In areas of high relief, we would expect offsets due to the “look angle” of the satellite and the “lean” of the mountain. As for the sea level offset, we’ll look into this. We typically use SRTM as the terrain model which only extends to +60degrees in the North. This is likely one of the contributing factors. Thanks again for the great feedback especially on the TOU!
Comment from Dalkvist on 9 May 2017 at 19:15
First thanks for making this available!
Regarding only using the SRTM data, there is a 50m resolution dem available for Sweden under ccby4 (the “GSD-Höjddata, grid 50+” data set) if that is of any use. I believe there are something similar available for Norway.
Comment from NunoCaldeira on 9 May 2017 at 23:33
great. looking forward! keep up the good job
Comment from Zverik on 10 May 2017 at 09:18
Hi Kevin, and thanks for these layers. They would surely boost the tracing activity in many areas.
Is it possible to add at least one “overzoom” level? That is, where imagery is only up to z17, add a z18 level with scaled-up tiles, using the source hi-quality imagery. That would make for easier tracing, since at the current quality most small features are too pixelated and suffer from jpeg encoding artifacts.
Comment from JimmyRocks on 10 May 2017 at 12:06
Thanks for all the great work you’re putting into this project! I am excited to use the new imagery for our marathons and import tasks! Keep it up!
Comment from @kevin_bullock on 10 May 2017 at 17:25
Hi Zverik - where we have imagery available, it should all overzoom or oversample to maximum zoom. I’m trying this right now over an area in the USA and seeing it oversample to z26. My guess is you found an area where we haven’t published imagery. We will have coverage and metadata soon, and in the Premium layer, we will have full global coverage in future updates.
Nuno and Jimmy - thanks for the feedback!
Comment from sommerluk on 10 May 2017 at 17:37
Thanks a lot! That’s great news!
There are many places in West Africa where your imagery is much better the what we had before. I love to see this, espacially because these countries are often forgetten because they are not a big market. Your imagery will help really much!
Comment from IrlJidel on 10 May 2017 at 17:40
re coverage and metadata - in the meantime is this an equivalent source to get coverage/vintage for the DigitalGlobe-Standard layer?
https://platform.digitalglobe.com/content/MapsAPI_Vintage-Leaflet.html#3/40.25/-10.55
Comment from Zverik on 10 May 2017 at 17:43
Ah, I’ve probably got it. The Premium layer falls back to the Mapbox imagery, which does not overzoom. Where there is a satellite photo special to that layer, it overzooms properly. Thanks!
Comment from alexkemp on 13 May 2017 at 14:55
Gosh, but I was eager to try this out but, in the end, have very mixed feelings. Most of my time is spent adding houses (currently in Mapperley, Nottinghamshire). Whilst I’m grateful to have something to use to draw house outlines from, I’ve kept having satellite envy at how much sharper Google imagery is than Bing. No longer!
In my neck of the woods:–
But then…
So, my search for sharper, newer satellite imagery continues (yet DG is providing much-needed, if blurry, imagery right now, for which many thanks).
Comment from amapanda ᚛ᚐᚋᚐᚅᚇᚐ᚜ 🏳️🌈 on 16 May 2017 at 07:47
This is great! Some of it is newer imagery than what we had before (Bing & Mapbox), so I was able to add some new things. It’s fantastic that we have another source for aerial imagery! 🙌🎉🎆
Comment from joost schouppe on 18 May 2017 at 18:28
This is really massive gift. I’ve heard from happy people in the Congo and Bolivia, and even here in Belgium it’s a great additional resource.
Comment from Stereo on 20 May 2017 at 18:36
Thank you DigitalGlobe!
The premium imagery is great; it covers places in Ireland that weren’t well covered by bing, or very badly. For example, Inishtrahull, off the coast of Donegal. It’s also great to then georeference the old gsgs map
Comment from Palolo on 22 May 2017 at 11:10
Having access to this imagery from DigitalGlobe is very nice.
The biggest problem I have with this is the lack of metadata: When was the imagery in a given area acquired? Here in Ethiopia we have some gaps in the nice Bing imagery, however, where both DigitalGlobe and Bing are at a suitable resolution it is important to compare the dates when each image was collected. There are places where it appears that DigitalGlobe is about 10 years out of date in this [example] (https://www.openstreetmap.org/edit?editor=id#map=17/7.03121/38.48663), but that is just a guess.
One of the biggest strengths of OSM is the history file for each feature, without metadata from DigitalGlobe we are reducing the quality of the OSM data we produce.
Comment from @kevin_bullock on 22 May 2017 at 15:40
thanks for all the feedback alexkemp, rorym, joost, Stereo!
Palolo, re: Metadata, we will make it available.
Comment from Palolo on 23 May 2017 at 13:07
Thank you, knowing more information about the imagery will make it much more valuable.
Comment from RespectableStreet on 21 September 2017 at 16:28
Kevin, your comment back in May said something about making metadata available in the coming weeks. A couple of days ago, I checked and still am not seeing dates. I know the best that the premium (vivid) service can offer is a date range. Will the standard service be able to provide specific dates, maybe with the exception of the landsat backfilled areas?
Comment from dikkeknodel on 22 January 2018 at 15:15
Hi Kevin,
Last few weeks I’ve used Digital Globe Premium imagery heavily to put in lots of details regarding natural elements of South Georgia and the Sandwich Islands, actual status to be found here. Thank you for putting in the effort to make this imagery data available for the OSM community.
At some point I started wondering about when the images were actually made. Date and time can help to determine the tide and thereby the most accurate location of the coastline and glaciers for example. Although for South Georgia it may be a less relevant, for populated areas changes may be much faster, so the date of the imagery is more important.
After some searching I found this Diary post. Do you have a progress update on getting the imagery meta data available (preferably in JOSM :-P)?
Keep up the great work and I wish you happy mapping.
Cheers, dikkeknodel
Comment from IrlJidel on 22 January 2018 at 15:26
dikkeknodel@ There’s some new imagery layers in Josm (at least) called ‘DigitalGlobe Premium Imagery Vintage’ and ‘DigitalGlobe Standard Imagery Vintage’
Comment from IrlJidel on 22 January 2018 at 15:29
This is in iD v2.5.0 as well.
see https://github.com/osmlab/editor-layer-index/issues/371
Comment from @kevin_bullock on 22 January 2018 at 16:20
Thanks for the feedback Dikkeknodel, your work on these islands looks fantastic and I’m happy the DigitalGlobe imagery was useful for this purpose. As noted by IrJidel (thank you!), we have deployed a beta version of Imagery Vintage that is functioning in both JOSM and ID. As an example, it looks like the imagery over the islands is from Feb18 2015. happy mapping!
Comment from dikkeknodel on 23 January 2018 at 11:48
Found it in JOSM, it had not been activated by default. I did not know this settings menu either. Thanks for the help to both of you!
Comment from Léo_M on 7 March 2019 at 13:10
Hi Kevin,
I’m using a lot free satellite imageries for my work (most of the time linked to OSM) so first thanks again to DG to share your imageries, it really opened new possibilities in the last years :)
But I’m also always amazed by how hard it is to find the capture date of the images …
Bing metadata is a nightmare and I came to the conclusion that it is almost impossible to know it precisely (on this subject here’s a really good article : https://philippgaertner.github.io/2018/11/microsoft-bing-maps/ )
Esri provides an good API but - as far as I know - no user friendly tool to extract the dates (so I coded one : https://jsfiddle.net/f0qo2j3w/1/ )
And now for DG, I checked the Vintage layers you provide but I have to admit that I’m quite skeptical about the relevance of it … I know it is still in beta but in almost all the areas I checked (and I took worldwide examples of areas I used to work on) I found that the date was wrong. Almost nowhere I could find dates more recent than 2016 (and in some areas the image is clearly from 2017 or even 2018) so I start to think that the raster of extent and dates was generated some years ago and never updated (?) …
Well, this comment is not a complaint but more an interrogation about the next steps of DG to improve the access to the metadata, which is almost as important as the image :)
Thanks
Comment from RespectableStreet on 8 March 2019 at 00:49
Leo, I suspect the imagery you are using is ultimately derived from DigitalGlobe’s +Vivid imagery. In past conversations I’ve had with DigitalGlobe(DG), the +Vivid imagery is comprised of many mosaicked images. Each mosaicked image in this service is comprised of multiple image strips. In some cases the image strips are all comprised from the same date to create the mosaic. But most of the time, the mosaic is made from multiple image strips that are from a variety of dates that could span a period of months or many years apart in age. The default date given for any of the mosaicked image in this service is the oldest date used to build that mosaic image. That would explain why the image is dated, say in 2016, but you are clearly seeing imagery much newer than that within that particular mosaicked image. DG has also told me that they have no way of discerning the actual dates of any pixel within the +Vivid imagery service images. They only know the oldest and newest dates of the imagery used for any particular mosaicked image within this service. The best imagery to use for mapping purposes that would provide reliable image dates would be DGs “Basemap +Daily” imagery.
Comment from Léo_M on 11 March 2019 at 10:07
Hi RespectableStreet,
Thank you for your answer ( I didn’t thought I would get an answer that quickly on a 1 year old thread :) ). Really good point about the mosaic, I think it is also the same issue with the Bing Imagery for which we get two dates in the metadata : VintageStart and VintageEnd.
The thing that still questions me is how can DG not be able (technically?) to get the date of their images …
On the picture below you’ll see a comparison between Esri World Imagery and DG for the same area. The satellite imageries are obviously the same but Esri can return with its API the exact extent (highlighted in yellow) and a date ( Dec 2016 ) that seems more accurate than the DG one (2014) from what I know of the area.
Image :
Esri is not a satellite imagery provider, they got this image from someone else (maybe even DG) so if they can provide a precise and reliable metadata, DG should too … Once again, not trying to trigger or defend anyone, just trying to understand what’s the real blocking point for accessing the metadata (technical? API still to be built ? confidentiality ? )
Cheers,
Comment from alexkemp on 11 March 2019 at 10:57
Hi Léo_M
Since I was working in JOSM using Esri World Imagery (much better than any of the other imagery) I right-clicked on the display & chose “Show tile info”. Annoyingly no Copy available so laboriously typed in the URL & downloaded the tile. The dates in the metadata were entirely for the instant that it was downloaded. What a waste of intelligence.
Comment from Léo_M on 11 March 2019 at 11:14
Hi alexkemp,
Yes, you won’t be able to access easily the Esri metadata directly from JOSM (as for as I know). Esri provides this app : Esri Imagery Date Finder that displays the date (and other metadata) of the satellite imagery on the area you clicked on.
Otherwise I created this small app to load all the images on the extent of the map so you don’t have to click on all the individual ones and see clearly the limits of each extent : https://jsfiddle.net/f0qo2j3w/1/
Cheers,
Comment from alexkemp on 11 March 2019 at 11:33
Excellent!
Gosh, but those extents are much bigger than I expected. As it happens, a dividing line for two extents goes clean through the houses that I’m currently adding to the map (would never have guessed it otherwise).
Map date appears to be 2016-05-09. That date is much older than I expected, although young enough for the houses I’m currently working on (but not for the estate that is next to be mapped).
Although Esri is good, appears to be younger than Bing and far better than other Imagery, I still pine to have imagery as good as Google’s. Other people have car- or house-envy, I have imagery-envy.
Comment from RespectableStreet on 11 March 2019 at 14:43
Leo, the DG +Vivid service was not designed to be mapping features. DG knows the dates before processing but purges that information after processing the +Vivid imagery service. Again, this service was basically designed to use as background eye candy vs collecting features for mapping purposes. The best service that would retain all of the individual image metadata would be the DG +Daily imagery service. I don’t know why that is not not being made available for OSM but I would suspect it has something to do with cost.