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

Wayback followup fixes #1388

Merged
merged 10 commits into from
Apr 26, 2024
Merged

Wayback followup fixes #1388

merged 10 commits into from
Apr 26, 2024

Conversation

bhousel
Copy link
Contributor

@bhousel bhousel commented Apr 25, 2024

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.

  • Having it as its own source means that there is no confusion about the relationship between the radio button and the previous checkbox
  • It also allows the user to lock in a date and switch between the wayback source and another source with the ⌘B shortcut
  • This fixes a bunch of tricky interactions with the urlhash too. We fetch all the wayback sources at init time - this means that if a urlhash contains a param like 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.
  • Also better defers the work of fetching the available "local release dates" (these are the dates that the imagery appears changed in the current map view). Because this is an expensive call, we now do it during idle time and cache the results per z14 tile, so it won't refresh unless the user moves the map a bunch, and there won't be a need for a spinner when the user tries to use the dropdown.
  • The dropdown will always show the current date, the oldest date, and the newest date. From what I can tell, the newest date seems to match "Esri World Imagery" and the oldest date seems to match "Esri World Imagery Clarity".
Screenshot 2024-04-25 at 1 41 24 PM Screenshot 2024-04-25 at 1 41 10 PM

bhousel added 9 commits April 22, 2024 10:41
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.
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.
@tordans
Copy link

tordans commented Apr 26, 2024

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 :-).

@bhousel
Copy link
Contributor Author

bhousel commented Apr 26, 2024

Side note: I still don't understand if/when a branch preview is created :-).

We aren't totally sure either 😆
It seems like the conditions are:

  • PR made by a project team member
  • and the PR will merge cleanly to main without conflicts

@bhousel
Copy link
Contributor Author

bhousel commented Apr 26, 2024

Thanks @tordans !
BTW I did change the source id for this layer to EsriWayback so it won't conflict with the other EsriWorldImagery source. I think this might be ok, but it will mean your URL that you shared on Mastodon would stop working after this merges.

The wayback-core library includes a helpful `getMetadata` function!
This replaces the kind-of-complicated `getMetadata` in ImagerySourceEsri
@bhousel
Copy link
Contributor Author

bhousel commented Apr 26, 2024

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.

Screenshot 2024-04-26 at 11 27 01 AM

@bhousel bhousel deleted the wayback_followup branch April 26, 2024 15:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment