facebook
Imagery Vintage not displayed in background panel
Description
When bing imagery is selected with the background panel enabled, it does not show the imagery vintage.
In the inspector, I am able to see that the tile requests contain the following header:
X-VE-TILEMETA-CaptureDatesRange: 10/21/2022-10/21/2022
This is what I suspect is supposed to be shown in the pane, but it is not there.
Version
2.1.1
What browser are you seeing the problem on? What version are you running?
Firefox 117
The OS you're using
Fedora 38 Linux
Steps to reproduce
- Enable "Show Background Panel"
- Select Bing imagery
The browser URL at the time you encountered the bug
https://rapideditor.org/edit#background=Bing&datasets=fbRoads,msBuildings&disable_features=boundaries&map=19.52/30.40879/-97.67310
The auto-detected useragent string for your browser (leave blank if you're manually filling this form out)
No response
This might happen with other imagery sources, but I am not sure which ones are supposed to have a vintage. For example, Mapbox Satellite imagery returns Last-Modified header that seems like it might be the imagery vintage, but it also shows "Vintage: Unknown."
Ooh thanks for the report!
If I recall correctly, the ESRI Clarity Imagery vintage was the only thing we used to show.
ex. from Rapid v1:
So for sure this is a regression. I'll take a look. While I'm at it I'll investigate the ~Maxar~ er, I mean Bing - imagery vintage information- we definitely never surfaced that info to the UI before.
I see. In the network panel I can see that the following sources return some sort of imagery capture date:
- Bing aerial:
X-VE-TILEMETA-CaptureDatesRangeresponse header - Esri World: separate request which returns tile metadata
- Mapbox Satellite:
Last-Modifiedheader
they all return it in different ways, but I have to hope that other tileservers also return the capture date. It's very useful information for the mapper to have.
It's very useful information for the mapper to have.
For sure, and understood. I will work on getting this fixed today.
Just spoke with @bhousel - apparently there have been some changes in the various ways the Bing endpoint has historically served things over time. ESRI however has remained unchanged and that is a regression from 1.x/2.0 code.
I'll try to restore both imagery vintage/metadata and post some vids of when I get it back to working.
Begin debugging info dump:
Rapid v1 and v2 generate identical request/response URLs/payloads while the ESRI World Clarity imagery is loaded. Example request/response for posterity:
Request URL: https://services.arcgisonline.com/arcgis/rest/services/World_Imagery/MapServer/3/query?returnGeometry=false&geometry=-73.96397904120785,40.58676563039312&inSR=4326&geometryType=esriGeometryPoint&outFields=*&f=json
Response json:
{
"displayFieldName": "NICE_NAME",
"fieldAliases": {
"OBJECTID": "OBJECTID",
"SRC_DATE": "DATE (YYYYMMDD)",
"SRC_RES": "RESOLUTION (M)",
"SRC_ACC": "ACCURACY (M)",
"SRC_DESC": "DESCRIPTION",
"MinMapLevel": "MinMapLevel",
"MaxMapLevel": "MaxMapLevel",
"NICE_NAME": "SOURCE_INFO",
"DrawOrder": "DrawOrder",
"SRC_DATE2": "SRC_DATE2",
"NICE_DESC": "SOURCE",
"BlockName": "BlockName",
"ReleaseName": "ReleaseName"
},
"fields": [
{
"name": "OBJECTID",
"type": "esriFieldTypeOID",
"alias": "OBJECTID"
},
{
"name": "SRC_DATE",
"type": "esriFieldTypeInteger",
"alias": "DATE (YYYYMMDD)"
},
{
"name": "SRC_RES",
"type": "esriFieldTypeDouble",
"alias": "RESOLUTION (M)"
},
{
"name": "SRC_ACC",
"type": "esriFieldTypeDouble",
"alias": "ACCURACY (M)"
},
{
"name": "SRC_DESC",
"type": "esriFieldTypeString",
"alias": "DESCRIPTION",
"length": 25
},
{
"name": "MinMapLevel",
"type": "esriFieldTypeSmallInteger",
"alias": "MinMapLevel"
},
{
"name": "MaxMapLevel",
"type": "esriFieldTypeSmallInteger",
"alias": "MaxMapLevel"
},
{
"name": "NICE_NAME",
"type": "esriFieldTypeString",
"alias": "SOURCE_INFO",
"length": 50
},
{
"name": "DrawOrder",
"type": "esriFieldTypeSmallInteger",
"alias": "DrawOrder"
},
{
"name": "SRC_DATE2",
"type": "esriFieldTypeDate",
"alias": "SRC_DATE2",
"length": 8
},
{
"name": "NICE_DESC",
"type": "esriFieldTypeString",
"alias": "SOURCE",
"length": 25
},
{
"name": "BlockName",
"type": "esriFieldTypeString",
"alias": "BlockName",
"length": 100
},
{
"name": "ReleaseName",
"type": "esriFieldTypeString",
"alias": "ReleaseName",
"length": 15
}
],
"features": [
{
"attributes": {
"OBJECTID": 147663,
"SRC_DATE": 20220316,
"SRC_RES": 0.14999999999999999,
"SRC_ACC": 0.59999999999999998,
"SRC_DESC": "NYS ITS GIS Orthos",
"MinMapLevel": 16,
"MaxMapLevel": 19,
"NICE_NAME": "Brooklyn2022",
"DrawOrder": 100,
"SRC_DATE2": 1647388800000,
"NICE_DESC": "New York State",
"BlockName": "Brooklyn-NY-USA-15-CMP-20230216",
"ReleaseName": "Maps 2023.R04"
}
}
]
}
So, since the shape of the data collected is identical, there must be a logic flaw somewhere in the imagery code. I stepped through v1 and v2.1.x code and noted one discrepancy: in V2, the code is throwing an error that is getting eaten / silently spiked into the dirt with this line in UIPanelBackground.js:
// attempt async update of the rest of the fields..
source.getMetadata(center, tileCoord, (err, result) => {
if (err || this._currSourceID !== source.id) return; // ERR is getting returned from the metadata callback
The 'err' string is as follows:
Cannot read properties of undefined (reading 'localeCode')
It looks like this line got missed during a systems refactor in ImagerySource:
const localeCode = this.context.localizationSystem.localeCode();
The systems refactor now neatly tucks each system into this.context.systems.*systemname*.
Changed the line to
const localeCode = this.context.systems.l10n.localeCode()
and the ESRI metadata is coming up once again! Now for Bing....