sun exposure during polar day is always 12 hours

[twest820]

ShadeMap should be finding 24 hours' sun on higher elevations and less on south facing aspects. Instead, a flat 12 hours is returned. Easy repro here, for example. I get 120 for saved GeoTIFF cell values, consistent with the sun exposure mouseover but inconsistent with the shademap. The shadows with the sun in the north look reasonably correct for the topography at this site.

ShadeMap does find zero hours' sun exposure during polar night. However, the hovertext consistently said 0.3 hours the first time I flipped the render from summer to winter solstice. This cleared after zooming and repeatedly flipping between solstices consistently gives zero and 12 hours.

Another repro is here and the behavior's the same along the Arctic Cordillera in the Canadian high arctic. If one isn't already present it probably wouldn't be a bad idea to include an Antarctic site in the sun exposure unit tests as well.

[ted-piotrowski]

Ah yes! Good catch and thank you. I use a suncalc library to calculate the sunrise to sunset time intervals for each day but it returns Invalid Date if the sun never rises/sets. A bit embarrassing I didn't catch this before. I will update when I've deployed a fix.

[ted-piotrowski]

This should be fixed now. If you switch to sun exposure mode in the high arctic, sun exposure data should encompass a 24 hour period. If needed, you can also adjust the time period by clicking the date/time underneath the sun exposure legend. Let me know if you run into any issues.

[twest820]

I just tried a few Alaskan sites, such as Kotz and am consistently getting 12.5 hours daylight instead of 24. Not sure how the unit tests are still missing this.

[ted-piotrowski]

It looks like the 12 hours are encoded in the url. To reset the sun exposure interval from sunrise to sunset, you need to switch to "shadow" mode and then back to "sun exposure" mode or open the date picker at the bottom of the screen and select Sunrise and Sunset for the times.

https://shademap.app/@66.87334,-162.44237,8.1883z,1687377599500t,0b,0p,1m!1687334400000!1687420799000

[twest820]

I'm going to https://shademap.app/, moving to the desired location, and switching to sun exposure. If ShadeMap's inserting 12.5 hours into its url and then getting stuck when the map's moved to some other location with different sunrise and sunset times, maybe it should be able to automatically update its calculations?

Seems like there's also an issue where if you pick a date for sun exposure and press apply ShadeMap doesn't update sunrise and sunset times to match the new date (and location, if that's changed too). I can see the value in being able to manually override sunrise or sunset times but that's probably a niche use case?

It appears there's another limitation in that a constant sunrise and sunset time are used across the entire map viewport, leading to incorrect predictions when the view is large.

[ted-piotrowski]

I think I understand. If you go to https://shademap.app, it will load for today (3/23/23). If you then move to the desired location and switch to sun exposure it will calculate sun exposure for sunrise to sunset on 3/23/23 (which is 12.5 hours, let's say from 7am to 7pm roughly). If you now open the time range dialog and press June 21st, the date will update but the hours will remain 7am and 7pm unless you manually press the "Sunrise" and "Sunset" buttons next to the start time and end time input fields (pressing these buttons overrides the start time/end time values with your selected dates respective sunrise/sunset times). I think what you're saying is that anytime you change the date, you want to automatically update the start time/end time to sunset/sunrise for that date?

I think you also suggest updating the start time/end time to the corresponding location's sunset/sunrise anytime the map is moved, but there is a use-case where someone is going for a walk in the next hour and wants to set sun exposure for the next hour and pan around their neighborhood. If the start time/end time reset to sunrise/sunset each time the map was moved this would not work.

The sun exposure time interval is always defined in the time zone at the center of the screen, so when the view is large, the center timezone might have full light while timezones on the edge are partly experiencing night time. I'm aware of this issue but haven't come up with an acceptable solution yet.

[twest820]

Hi Ted, yes, the current UX assumes the initial geolocation and map zoom level are close to what the user wants to do and, therefore, that sunrise and sunset times can be fixed. We've seen here that can break down in several different ways, resulting in neither the default (sun exposure over the full day) or more specialized use (sun exposure during part of a day) cases working all that well. If this were my code I'd probably approach these issues by checking out how these two scenarios can interact through a redesigned UX which lets the user more clearly discriminate between sunrise and sunset as floating values which change based on location and time of year versus calculating sun exposure over fixed intervals.

Some more detailed things I'd suggest also considering, based on dealing with similar issues in other tools.

• The current UX is ambiguous about time zones. So calculations across longitude are potentially wrong or confusing any time the map view covers more than one time zone or if the map scrolled from one timezone from another.
• The international date line is a special case which will always make your code cry. Likely not too much of an issue for ShadeMap, though, so seems low priority.
• Somewhat analogous to longitudinal tiling by time zone and, as you touched on, large map views require primarily latitudinal tiling for variation in day length plus also longitudinal tiling for Earth's axial tilt for dates away from the equinoxes.

For example, some coding I did in collaboration with Parks Canada dealt with a Jasper National Park study where crews working from the British Columbia side were in UTC-7 or -8 while crews from the Alberta side used -7 or -6. I ended up building DateTimeZone controls and using those everywhere so datetimes were always shown together with their time zones in order to keep track of things. If that'd extended farther north into Kakwa Park there would have also been fixed UTC-7 sites.

What I'd probably do as a starting point to put a box around such considerations and limit code and UX complexity is

• Set a default tile size of 1°x1° as the validity extent of sunrise and sunset calculations. This has no effect on small maps but should do a lot for larger, multitile ones in the default case where sun exposure is calculated for a full day. If needed, the tile size can be made user adjustable. I think this is nearly compute cost invariant since the number of pixels to raytrace from doesn't change.
• If users want to move into calculating sun exposure for part of a day then they get to specify one starting and one ending sun position by picking start and stop times in a specific time zone. Those sun positions are then the same across all tiles. Defensive design would consider the possibility tiles may eventually need to follow time zone boundaries and sun positions vary by tile. But I suspect demand for such features is low.

My experience is picking up the machine's default time zone is transparent to many users and that people who need to work across multiple time zones usually already know what they need to change and just want the UX controls needed to make the changes.

With this type of design I'd test for significant edge artifacts across tiles here―2°x2° maps might be about worst case for showing them―but I suspect they should be negligible. Since the Earth spins 15° an hour, if sun positions are raytraced on 20 minute timesteps that's a 5° step that's comfortably outresolved by a 1° tile. Following from the discussion about six minute resolution in #6 I'm somewhat hesitant about larger tiles as six minutes is 1.5° of planetary rotation. (One could certainly get fancier about linking tile size, raytracing timestep, and latitude but it feels to me like avoidable complexity.)