Talk:Bing
Age of images
The linked site does not display the real time when imagery was captured. For my region the site sais imagery was taken in 2005, but the images show an epmty place where in 2002 a restaurant was erected. -- Malenki 12:24, 5 December 2010 (UTC) PS: right south of the building in the middle here 2002 a restaurant was erected. -- Malenki 14:49, 12 December 2010 (UTC)
- The dates are definitely not always 100% accurate. They seem to be in many places though, so the site can be a useful resource. Obvious errors can be reported here. Martijn van Exel 16:07, 5 December 2010 (UTC)
- I've found another error. The BING images for Wernigerode, Germany show both the old and new Hasseröder Brewery and the page says the images are from Jun/2005. The new brewery has been built in 1995, and later in 2001 the old one has been demolished. I was not able to get a permalink to the mvexel page, but this one shows the images at the right zoom level: [1] --Brian Schimmel 19:08, 5 December 2010 (UTC)
- Russia, Moscow [2]. The BING images are not older than 2008-09 --Canabis 15:46, 9 December 2010 (UTC)
At higher zoom levels, 1980 is reported for the Innsbruck, Austria aera. This is definitely wrong (e.g. a roundabout under construction is visible, it was finished in early 2008). Probably 1980 stands for unknown date. However, only a few kilometres south the analyser says Dec 2007. So it may also be that there is some glitch in the database (tile infos shifted southwards). --BorisC 11:34, 19 December 2010 (UTC)
- I would say that 1980 is certainly a null indicator, and not meant to be a real date. Any unclassified imagery from that time would be black and white, and just barely usable to see major arteries and buildings - on the order of 10-100m/pel (as opposed to the 0.06-1m/pel that we are used to seeing now). Here's another example of this: http://mvexel.dev.openstreetmap.org/bing/?lat=33.61711049738656&lon=-117.92901206994054&zoom=20 AM909 14:21, 23 December 2010 (UTC)
It would be nice if the zoom level in the analyzer would go up to zoom 22 instead of stopping at 20. I work on areas where zoom 21 is available. AM909 03:08, 22 December 2010 (UTC)
In some places, it shows a range of dates, which I can understand at lower zoom levels where two different sets of imagery interface. However, that doesn't make sense when zoomed all the way in, like here: http://mvexel.dev.openstreetmap.org/bing/?lat=33.99994248883285&lon=-118.14406622886628&zoom=20 . I'll note that the highest level available here is actually 21, but then I'd expect to see the date range over only a few tiles, but it is over the whole area at z20. Is this a bug, or does it really just mean that they used a composite of tiles from diff dates? AM909 14:26, 23 December 2010 (UTC)
In Freiburg, Germany the date is wrong. It says 2005 but the pictures are older than 1999. Have a look at the Tunnel work: http://mvexel.dev.openstreetmap.org/bing/?lat=47.98679394594158&lon=7.8879317638028645&zoom=15 and http://de.wikipedia.org/wiki/Sch%C3%BCtzenalleetunnel .--Skyper 11:54, 28 December 2010 (UTC)
In this area the age which is shown is June 2005, but is older than February 2004 (http://mvexel.dev.openstreetmap.org/bing/?lat=50.74827341811076&lon=10.80927124023438&zoom=14) --Benschi 13:19, 1 January 2011 (UTC)
This area in Thuringia, Germany, is reported as June/2005, but the images are from about 2001-2002. --Scai 11:04, 14 February 2011 (UTC)
- The same (reported 2005 but aerial is actually from 2001) is true for middle franconia, the area around Nuremberg. You can see that if you look at the "icestadion Linde" which is already demolished but the 'Mercado' has not yet errected. --Kellerma 17:41, 25 June 2011 (BST)
Dates from meta-data no longer available?
I took at look at the http://ant.dev.openstreetmap.org/bingimageanalyzer/ resource today and find that the date information for tiles appears to no longer be available. Is this across the board for all areas, or only dropped where there was significant uncertainty? Thanks for the information. --Ceyockey (talk) 11:22, 26 December 2013 (UTC)
Dates are right in the tile's HTTP headers!
In your browser's Developer Tools "Network" tab you can see the headers, e.g.,
X-VE-TILEMETA-CaptureDatesRange: 4/19/2011-4/19/2011
I.e., many years ago. Jidanni (talk) 02:25, 26 December 2019 (UTC)
And checking the same tile right on maps.bing.com shows
x-ve-tilemeta-capturedatesrange: 4/19/2011-4/19/2011
i.e., Bing apparently long ago ran out of "bang" (for the buck) :-( Jidanni (talk) 02:30, 26 December 2019 (UTC)
Poor alignment
In a random test on flat well surveyed land near sea level I'm seeing an offset of more than 20m from where Google's map places an object. e.g. the Foxton Windmill in New Zealand, which maps.google.com puts at -40.47404, 175.28095.
My serious suspicion is that Bing is rather wrong for many parts of the world and my fear is that OSM is going to get polluted with high resolution mistakes because of it as people trace and "fix" existing data to the poor georegistration.
bing doesn't have a nice link-to URL API AFAIK, so just cut and paste in that lat/lon coord into maps.bing.com's search box and you'll see that they are more than 20m different from each other. Short of any other commentary on the two companies I'll just say that I trust Google more- if for no other reason than they've had their mapping tools around longer and stronger, and I suspect they've used their fleet of survey-grade GPS enabled streetview cars to better tie down the satellite imagery, or at least I'd think they'd be silly not to.
Caveat emptor and please use the source=bing_imagery tag. [AM909 is right; updated]
- I'd rather see bing_imagery, since we're only sourcing the positioning with bing imagery, not the name or other characteristics. I'm actually using bing_imagery_res_date where "res" is the approx m/pel of the scale I'm using and date is the imagery date. e.g. http://mvexel.dev.openstreetmap.org/bing/?lat=34.133339923641394&lon=-117.53588832914821&zoom=20 is bing_imagery_0.12m_200701. See below for list of bing scales AM909 02:42, 21 December 2010 (UTC)
TODO: test to see where JOSM's slippymap, Merkaartor.svn's TMS/WMS, and Potlach's Bing backdrop places stuff before blaming it all on Bing. Bonus points for RTK GPS surveyed ground control points.
--Hamish 03:56, 20 December 2010 (UTC)
- It seems to be confined to outside urban areas - the Sky Tower in Auckland (-36.848502,174.762159) is almost spot on in both (note it points to the base because Google makes the tower point southeast, while Bing makes the tower point northeast).
- Masterton is off too - the top of old CentrePoint tower at Majestic Motors is off 20m to the north like the Foxton Windmill. In Dunedin is only 10 metres and to the south (based on University clocktower) Lcmortensen 10:14, 20 December 2010 (UTC)
- You can link to bing maps using the mail icon in the bottom left. It gives you URLs such as: http://www.bing.com/maps/?v=2&cp=-40.47404~175.28095&lvl=18&dir=0&sty=a
- You should avoid using google imagery, even for assessment of accuracy, since we don't have any permission to use it (all very debatable what counts as "using" for OpenStreetMap purposes. Safest thing is to avoid it totally)
- Also comparing one imagery with another isn't really the best approach. It tells you that one of them is wrong of course, but the possibilities for confusion are multiplied.
- On the whole though, I'm sure you're right. Bing's imagery is less accurately aligned in some areas. This varies by different survey companies, different days flying, whether the specific point was directly beneath the plane or off to one side, and whether the guy doing the alignment had had his morning cup of tea yet. There's also warping introduced by hills and mountains. I'd be interested to know how much that factor comes into play.
- -- Harry Wood 10:19, 20 December 2010 (UTC)
- And another factor is the number of control points. How have alignment of these sources been done anyway? I have seen that alignment can be very accurate close to the center of the area (usually in highly detailed urban areas) while the edges is less accurate, also some coverages consists of several flyovers, some for extending coverage, and some for cloud patching. One example I have seen is along BR-101 from Vitória (ES, Brazil) to Rio de Janeiro (RJ, Brazil), misalignment between two flyovers can be as much as 50 meters, while the general coverage is consistent with several logged GPX tracks. Are we able to add further control points to enhance the accuracy? --Skippern 10:35, 20 December 2010 (UTC)
- If you are curious about how orthorectification software works and what it considers, here are the manuals to one such bit of software. --Hamish 07:00, 21 December 2010 (UTC)
- And another factor is the number of control points. How have alignment of these sources been done anyway? I have seen that alignment can be very accurate close to the center of the area (usually in highly detailed urban areas) while the edges is less accurate, also some coverages consists of several flyovers, some for extending coverage, and some for cloud patching. One example I have seen is along BR-101 from Vitória (ES, Brazil) to Rio de Janeiro (RJ, Brazil), misalignment between two flyovers can be as much as 50 meters, while the general coverage is consistent with several logged GPX tracks. Are we able to add further control points to enhance the accuracy? --Skippern 10:35, 20 December 2010 (UTC)
- As others have said, Google may not be "correct" either. I looked for some other control points in the area and ended up with a list of CGPS stations from http://www.geonet.org.nz/resources/network/network-web-services.html , but imagery in the area doesn't seem sufficient to see these, as it is with some of the IGS stations (http://igscb.jpl.nasa.gov/network/list.html) I've found.
- So, I went looking for airport runway coordinates, which are IME spot-on when they are given for the runways themselves. This one (http://www.airport-data.com/world-airports/NZOH-OHA/) has the approach end of runway 9/27 spec'd with 6 decimal places of degrees (~ +/- 0.1m) at -40.202269, 175.372619. If you look at the point in GE, it shows that the GE imagery is shifted ~13m @ 169 deg.
- Unfortunately, we can't see the Bing imagery in that area to sufficient resolution to compare, but if GE is offset by the same amount at the windmill position, that would place the windmill at -40.474153, 175.280981 instead - only 11m away from its apparent position in Bing.
- Finding closer benchmarks visible in multiple imageries will get you more solutions to find a decent average. Of course, getting someone to sit at a position nearby and collect a 60-minute average with a consumer GPS receiver could get you a sub-meter-accuracy position.
- There are a number of suitable spots, like the parking spaces along the road (confirm that the number and gaps match with some measurements on the ground), the little parking spaces/turnouts along the road to the west, etc. Stick an external antenna on the car, have a nice walk, and be sure to draw a diagram with measured distances to different points (sidewalk, painted lines, etc.), since the imagery is still not great, and you'll be doing some approximation. The more data you have, the better. Personally, I keep the antenna in the same spot on the car, and I've carefully measured the distance to the right-front-wheel-center, so I only have to measure to that point when surveying.
- Get more points some distance away and you can start to get an idea of whether the error is in overall position, rectification, rotation, etc.
- Do remember that benchmark locations on top of buildings are problematic, as you have to be able to visualize where the benchmark lies on a line between the place you see it on the imagery (on top of the building) and the center of the earth. Different imagery sources are taken from different positions - some of them very difficult to visualize correctly. AM909 21:38, 21 December 2010 (UTC)
- Fully surveyed trig stations might be visible in the satellite images (shadows may help). "Correct" lat/lons for them for NZ can be found here: http://www.linz.govt.nz/geodetic/
- click on Search for geodetic marks, then "maps" to get the Google mash-up.
- For the 1st-Order station on the roof of the building I'm in right now (city of Dunedin), google maps and sat are pretty much exactly right in the mash-up. Bing imagery for the same lat/lon is off about 20m to the SSE from where I think it should be, but I'll have to climb up there to check the monument ID code to be really sure.
- I notice when zoomed in the LINZ mash-up says in red letters: "Warning: Geodetic marks may appear out of place by tens of metres with respect to the underlying map."
- I wonder if it would be helpful to ask LINZ if we could upload their Geodetic marker database into OSM? (with "please do not move this" tags)
- --Hamish 06:19, 21 December 2010 (UTC)
- update: I've just checked a local neighborhood gedetic mark. Google street maps & satellite imagery from maps.google.com is exactly right (to the limits of what you can see), Bing road maps are also seemingly exactly correct (probably using the same gov't provided road dataset [provided under a BSD w/Attrib-like license]), and Bing Aerial maps is a whopping 38 meters offset to the west in both JOSM slippymap backdrop and from maps.bing.com. This is on flat land near sea level. Other spot checks of geodetic marks around NZ by the NZOpenGIS group show errors in Bing placement ranging from 10-25m. sigh. --Hamish
The island of Madeira's another example of poor alignment. The imagery is offset to the southeast by about 500m. SomeoneElse 20:32, 8 January 2012 (UTC)
"True Offset Process" is an idea to try and tackle this problem in a more organised way -- Harry Wood 13:06, 14 February 2011 (UTC)
Bing Scales
Exact spec is z1 = 78271.52 m/pel at equator. Multiply by cos(latitude) to get scale at that latitude. Tiles are 256x256 pels
So, at 34 degrees latitude:
78271.52 m/pel @ eq @ z1 / 2^16 = 1.1943290 m/pel @ eq @ z17
1.1943290 m/pel @ eq @ z17 * 0.8290376 = 0.9901433 m/pel @ 34 deg lat @ z17
| Zoom | Tile† | m/pel | JOSM‡ |
|---|---|---|---|
| 17 | 253.5 | 0.990 | 99.0 |
| 18 | 126.7 | 0.495 | 49.5 |
| 19 | 63.4 | 0.248 | 24.8 |
| 20 | 31.7 | 0.124 | 12.4 |
| 21 | 15.8 | 0.0619 | 6.2 |
| 22 | 7.9 | 0.0309 | 3.1 |
†Tile = meters per side of 256x256 tile
‡JOSM = JOSM zoom level = m/100 pels
| Approx. m/pel values at different latitudes (N/S) | |||||||
|---|---|---|---|---|---|---|---|
| Zoom | 0° | 10° | 20° | 30° | 40° | 50° | 60° |
| 17 | 1.2 | 1.2 | 1.1 | 1.0 | 0.91 | 0.77 | 0.60 |
| 18 | 0.60 | 0.59 | 0.56 | 0.52 | 0.46 | 0.38 | 0.30 |
| 19 | 0.30 | 0.29 | 0.28 | 0.26 | 0.23 | 0.19 | 0.15 |
| 20 | 0.15 | 0.15 | 0.14 | 0.13 | 0.11 | 0.10 | 0.07 |
| 21 | 0.07 | 0.07 | 0.07 | 0.06 | 0.06 | 0.05 | 0.04 |
| 22 | 0.04 | 0.04 | 0.04 | 0.03 | 0.03 | 0.02 | 0.02 |
AM909 04:23, 21 December 2010 (UTC)
fwiw, I've written some GPL'd code to do this calc:
- Matlab/Octave code:
for lat=0:5:75; disp( [lat (a * 2*pi * pixelfact * cos(lat * pi/180)) / (256*2^zoom_level)]); end
- C -- see line 188:
http://gpsdrive.svn.sourceforge.net/viewvc/gpsdrive/trunk/src/map_download.c?revision=2593&view=markup
- Perl -- see line 1141:
http://gpsdrive.svn.sourceforge.net/viewvc/gpsdrive/trunk/scripts/gpsfetchmap.pl?revision=2593&view=markup
- --Hamish 05:44, 21 December 2010 (UTC)
Bird's Eye view
Are we allowed to take a look at the Bird's Eye view (diagonal angle) from time to time to get hints while tracing Bing's vertical aerial imagery? For example, if the vertical imagery doesn't clearly show whether a gray rectangle is a roof or a plaza, can I look it up on Bing's website from a diagonal angle? --Head 13:47, 9 February 2011 (UTC)
- According the license text we are not allowed to "use Bird’s Eye, Street Side, or Photosynth imagery". --Jkjk 21:25, 9 February 2011 (UTC)
Coverage
Discussion of http://ant.dev.openstreetmap.org/bingimageanalyzer/.
High resolution images, but they are red.
Please visit this place: [3] And zoom it to 18-19 zoom too.
"sing" on Pacific
I found this: http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=31.830285800493265&lon=-47.669580078121356&zoom=6 Maybe it should be there, but I'm not sure... Polanin 10:09, 3 March 2011 (UTC)
- You mean "on Atlantic", don't you? ;-) --Ant 11:50, 5 March 2011 (UTC)
updates showing up
- Updates on Z14 don't always show up on lower zooms. Usually this is fixed by browsing the desired area on Z12, but that's inconvenient. --AMDmi3 05:56, 17 February 2011 (UTC)
- Yep, that's right. Could somebody PLEASE fix this issue? --ALE! 07:44, 17 February 2011 (UTC)
- This limitation is intended, because the rendering is very computational intensive. I will try to optimize the algorithm and do some tests. Please be patient :) --Ant 17:53, 17 February 2011 (UTC)
- Update: I've made improvements to the code that enable tile rendering in z10 immediately after browsing in z14 (up to four zoom levels are taken into account now). Please note that this does not work for tiles that have been created before now - but then you could browse z12 and z8 consecutively. Please report any errors... --Ant 15:50, 20 February 2011 (UTC)
images aren't detected
- There seem to be areas of imagery where the images aren't detected. For example this area has imagery at zoom 20 (as shown), but only detects up to 19. --EdLoach 14:42, 18 February 2011 (UTC)
- Thanks Ed, I've fixed it. No idea however why those tiles haven't been recognized in the first place... --Ant 20:57, 18 February 2011 (UTC)
Automated tools
Obviously, some people do use tools to trace new metadata. I found the following, let's call them "behavioural patterns":
- random dots: especially recognizable in the oceans
- fixed space dot pattern: first seen in Turkmenistan/Uzbekistan, now on a lot of places (india, china, africa, ...)
- images: see the face and other icon in north africa
- edge-tracing tool (written by me, --quarksteilchen February 2011) currently testing in syria, jordan, ... but also traced the edges of italy.
does anyone know who is behind those tools, and if it is allowed (by bing and/or ant) to do such things?
-- User:Quarksteilchen 16:54, 23 February 2011
- I don't know who is behind them, and I think this practice is okay as long as it doesn't put too heavy loads on the servers, i.e. a fixed space dot pattern seems okay while requesting all tiles in the same area definitely wouldn't be acceptable. --Ant 20:58, 24 February 2011 (UTC)
Zooming
Am I the only one for whom it doesn't zoom with mousewheel? Zooming with icons and doubleclicn works. --AMDmi3 20:15, 3 March 2011 (UTC)
- Mousewheel works for me... --Ant 11:51, 5 March 2011 (UTC)
Old coverage tiles cached?
Here is an high-res area that expanded to the right lately. But still the tool render parts of it as red in lower zoom levels. --Kslotte 11:31, 4 March 2011 (UTC)
- Indeed... I haven't thought about expansion of imagery in the first place, so green tiles still can't override red tiles. I'll try to find a solution as soon as I have time for it. --Ant 11:53, 5 March 2011 (UTC)
- I've fixed the behavior (a while ago), the analyzer re-checks the availability of imagery whenever you zoom in. --Ant 15:28, 20 November 2011 (UTC)
- That's good because bing just expanded their coverage. In fact from a brief look around it seems massively extended. For example the whole of rural Spain is suddenly now turning green! Some good news for some HOT initiatives e.g. in Indonesia too.
- Obviously this tool will be very useful in mapping out the new coverage, but what can be done to make this work better? e.g. to achieve a more rapid transition to accurately representing the new coverage areas. Maybe whoever ran the grid probing bots needs to set them going again for example. But also maybe it could show the old records faded out, so we can see which bits of coverage boundaries may be now out of date.
- -- Harry Wood 01:30, 9 February 2012 (UTC)
- I'm not sure if fading out old records is a good idea... because also very old tiles may still represent the coverage situation correctly. Besides, writing a grid bot is actually really easy: just hit the script with the first i digits of the t parameter fixed (area of interest), the following j digits looping over (0,1,2,3) (i+j = grid cell zoom level), and the remaining k digits being 0 (i+j+k = testing pixel zoom level). But please don't turn this into a DOS attack - keeping j small and inserting sleep() between requests is encouraged. --Ant 10:43, 9 February 2012 (UTC)
- Maybe I was getting over-excited. We were talking about Indonesia during the HOT chat. Then later last night, Spain was one of the first places I tested in europe. A lot of spain is flipping red to green (but not all it turns out) and there aren't that many other additions. e.g. there's still funny chunks of Scotland missing, and most of Denmark. No changes there. ...but worldwide I wonder how many other additions have occurred. A systematic re-sampling of it all would be good. I wonder who ran the bot worldwide last time. It would make most sense for them to just run it again. -- Harry Wood 12:14, 9 February 2012 (UTC)
- You can look at http://www.digitalglobe.com/precision-aerial-info?s_cid=26#/coverage-maps to download pdfs which will show you what areas have already been acquired as part of the Global Ortho program. Not all acquired areas are visible on bing yet but will give you hints at what areas to check IrlJidel 12:53, 9 February 2012 (UTC)
Wrong Color Displayed in Los Angeles area
At http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=34.0726061652493&lon=-117.9074449300766&zoom=17 , for example, it shoes light green (14+). Pretty much all of LA, including this area, have at least z=19, and often z=20 and z=21 imagery available. It would be nice to see where these are. It appears there is even z22 available from Digital Globe, and so will probably be available in bing.
Also, the super-high category should say 20+, since 21 (maybe 22) is available in places, and it would be good to be able to zoom to at least that level (instead of the current max of 20).
(time passes...)
Now I see what is happening. The area above now has some 20, some 19, some 18, and some 14 after I zoomed all the way in to 20 in part of it. It seems that it doesn't evaluate what's available until someone actually looks at a tile at that zoom level. Is there any way (in the background perhaps) to get it to analyze and update an entire area? —AM909 (talk)— 08:14, 29 April 2012 (BST)
Analyzer update
The Bing analyzer has now switched to Leafpad, and the Bing road map layer has been replaced by an OSM Mapnik layer. --Ant (talk) 21:40, 6 April 2013 (UTC)
removal of hires images
Well today I realised that lots of areas lost highres imagery which was there last week, it seems they have updated a few areas with 2011 imagery and in due course removed "overlapping" highres images, which sometimes covered a larger area. Very great. :-( --grin ✎ 11:44, 18 April 2011 (BST)
I recently noticed that a lot of the imagery in the area i grew up has lost it's high-res tiles in JOSM and the online editor. What's even worse is that the imagery is still visible if i go to the bing maps website. InsertUser (talk) 18:04, 17 December 2013 (UTC)
- This has been noticed and discussed before on the help site: aerial background imagery disappears in P2 if I zoom in to a high level, it did not in the past at 7th December 2013. I think we cannot do anything here. Well, you can try to contact bing and ask if may be a accidental mistake. If you do please note it here. --Aseerel4c26 (talk) 19:51, 17 December 2013 (UTC)
Updates?
So, this is probably a question which has been asked a zillion times before, but as a newbie to this wiki, I am not entirely sure where to look... anyway, when/how does Bing actually update their maps with high-res aerial imagery of areas previously low-res? As it is right now, I cannot map a certain area just because the aerial imagery isn't as high-res as a few klicks to the east... Riggwelter (talk) 19:29, 9 June 2016 (UTC)