-
Notifications
You must be signed in to change notification settings - Fork 91
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
Wayback followup fixes #1388
Wayback followup fixes #1388
Conversation
Seems to be best practice for svg icon alt-text accessability these days? We can retain the <title> element for backward compatibility too.
Before, the tooltip would not show the description if it was a background being swapped, it would show "Switch back to this background" Now, it will show the description and just append the "Switch back.." text Also I don't know when the `⌘B` key handler went away, but it's back now.
(Also fixes tooltip situation, closes #1377)
This means that the urlhash can handle `sourceID` that look like `background=EsriWayback` or `background=EsriWayback_2024-01-01` This is important for preserving the Wayback imagery across refreshes. The ImagerySourceEsriWayback now has a date getter/setter, and correctly returns a reasonable `.imageryUsed` that includes the date if there is one. It is not yet fetching or checking all the available dates - I need to restore that code next.
Copying the Esri World Imagery props means we have less values we need to hardcode. This also adds a `.key` getter for sources. It usually returns the `.id` but for Wayback, it will include the date as well. This is for places in the code that need to uniquely identify different wayback sources, such as: - ImagerySystem where it writes this value to the urlhash - PixiLayerBackgroundTiles tile rendering code - UIPanelBackground info panel
Lots in here: - The `ImagerySourceEsriWayback` class now contains most of the responsibility for setting up Wayback. - Fetch all the sources at init time, this is pretty quick and ensures that if the url hash contains a wayback source, the user will see it right away - Fill in all the necessary methods for dealing with the current date (stored in startDate/endDate). All dates in imagery sources are really strings formatted like 'YYYY-MM-DD'. - Fix the `background_list` code so that it refreshes the list of changed dates sometimes. This step is expensive and will need to be improved to avoid fetching all this data unless the user has moved the map a lot.
Because this is an expensive call, we will cache the results in a spatial rbush index and only do this once per z14 tile.
This looks like great improvements! FYI I used the feature recently to check out walter level changes and wrote about it in https://en.osm.town/@tordans/112301870063364573 Side note: I still don't understand if/when a branch preview is created :-). |
We aren't totally sure either 😆
|
Thanks @tordans ! |
The wayback-core library includes a helpful `getMetadata` function! This replaces the kind-of-complicated `getMetadata` in ImagerySourceEsri
I fixed the metadata display too, the wayback-core library has a helpful function that made this really easy! 🎉 Interestingly, with the metadata now available, it becomes obvious that the release dates don't match the vintage dates. This makes sense when you think about it - there will be a lag between when the imagery is captured and released - but I wonder whether it will be confusing to users. Users seeing a date will probably assume it's the "captured on" date. |
closes #1377
closes #1379
closes #1380
closes #1381
closes #1382
cc @tordans
This moves Esri Wayback to its own source in the main background list, and fixes a bunch of other stuff.
background=EsriWayback_2024-01-01
, it will be available when Rapid starts up and will just work. If the user manually manipulates with the urlhash, the code will pick the closest date that makes sense.