Add weather overlay to maps view

[barbeau]

Summary:

OBA iOS is in the process of a UI update (see OneBusAway/onebusaway-iphone#1303), and in the process @aaronbrethorst set up a nice weather API based on Dark Sky.

Example URL is:
http://onebusaway.co/regions/1/weather.json?lat=47.63671875&lon=-122.6953125

...where 1 is the region ID from the Regions API.

Details:

• The weather API is using write-through caching with a 30 minute TTL and constraining results to grid squares of approximately 20km on a side
• lat and lon are optional, but they’ll give you better, more accurate data, especially in larger regions
• Planned addition of etag support, so we could set up conditional GET support so that the client only continues the request if appropriate
• I'd also like to cache results locally on Android device with ~10 min TTL to avoid hitting battery too hard.

For UI, I'd like to have a transparent overlay on the maps view, like the below iOS view, but ours should be at the top of the screen or bottom left. We have My Location and Layers FABs in bottom right corner, and optional zoom control at bottom middle of screen. IIRC the Maps heading view appears in the upper left when you rotate or tilt map, so that area is off limits too.

Steps to reproduce:

Go to "Nearby" map view

Expected behavior:

Show me current weather info

Observed behavior:

No weather info is provided

Device and Android version:

N/A

[barbeau]

@aaronbrethorst Did the oba.co API for weather change?

http://onebusaway.co/regions/1/weather.json?lat=47.63671875&lon=-122.6953125 is giving me a 404.

Seeing your demo made me want to add it to Android again ;)

[aaronbrethorst]

Yes sorry I was hoping to have this documented. It’s moved to its final home, though, which is available through this versioned API: https://onebusaway.co/api/v1/regions.json The path templates hew to the IETF’s URI template spec, or you can just directly hit the API like so: https://onebusaway.co/api/v1/regions/0/weather.json And include lat and lon as query parameters if desired. I promise it won’t move again :)

…

Sent from my iPhone

On Jun 29, 2018, at 2:34 PM, Sean Barbeau ***@***.***> wrote: @aaronbrethorst Did the oba.co API for weather change? http://onebusaway.co/regions/1/weather.json?lat=47.63671875&lon=-122.6953125 is giving me a 404. Seeing your demo made me want to add it to Android again ;) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[tuesd4y]

Hi, all!

I was thinking about doing a PR on this issue in the near future, is there anyone working on that right now?

And last but not least:
I was thinking about implementing the weather view on the bottom left side of the MainView since it looks better, do you have any thoughts on that, @aaronbrethorst and @barbeau ?

[aaronbrethorst]

@tuesd4y Behind the scenes, the iOS app's weather feature is powered by the Dark Sky API, which is going away in the not-too-distant future due to Dark Sky's acquisition by Apple. Accordingly, I'm going to transition the feature over to the U.S. National Weather Service for regions that are in the United States and hide the feature for regions outside of the U.S.

OneBusAway/onebusaway-ios#223

[barbeau]

@tuesd4y No one working on this for Android that I know of, so feel free to tackle it! It needs to be positioned in bottom left or top right because of other controls:

The only tricky part with the bottom left is that you'll need to dodge the "Google" icon - we can't cover that per the Maps API license, so it would need to be above it.

If you could post mockups of the visuals too before you implement that would be great, if those aren't included in the API response. I try to stick to the material design icons whenever possible, and from a quick search it looks like wb_sunny, wb_cloudy, ac_unit, nights_stay could all be good options to start with:
https://material.io/resources/icons/?search=wb&icon=wb_sunny&style=baseline

One caveat is that we need to figure out the source of weather data given the changes @aaronbrethorst mentioned, and if there are costs associated.

@aaronbrethorst So could we still leverage the onebusaway.co API for Android, or will that change with the iOS transition? If so, is the API expected to change? If not, are there client costs with NWS?

[aaronbrethorst]

NWS data is free (in the sense that there are no secondary costs for it beyond our federal tax dollars), and they have a pretty decent API. I am going to deprecate the OBA.co weather API after rolling out the NWS-based weather service on iOS and directly interface with the NWS API on the new iOS client.

Here's the NWS's FAQ about their API: https://weather-gov.github.io/api/general-faqs

and here's the API client we're going to use on iOS: https://github.com/WeatherProvider/NationalWeatherService-Swift (which was written by @ualch9, who's been helping out a ton on the development of the new OBA iOS client.)

[ualch9]

FYI, I am currently working on WeatherProvider, which will combine multiple government sources into a single API. It will have a server app (non-functioning atm) that we can use on oba.co.

[tuesd4y]

@barbeau Yep I thought about just moving it a few pixels above the google logo. I'll send you a screenshot once I've done more in the ways of design!

Also thanks for the suggestion with the icons. Is there any general style-guide for designing components to follow?

@aaronbrethorst Okay, then I probably will use the NWS API instead of the OBA.co API right away. My approach would be to (for the time being) not use an external API wrapper, but just do these two REST calls more or less manually.

[barbeau]

FYI, I am currently working on WeatherProvider, which will combine multiple government sources into a single API. It will have a server app (non-functioning atm) that we can use on oba.co.

@ualch9 Looks like cool stuff! What's your expected timeline for the server app? We'll have to decide which path to take...

Okay, then I probably will use the NWS API instead of the OBA.co API right away. My approach would be to (for the time being) not use an external API wrapper, but just do these two REST calls more or less manually.

If we go this path of client code, I'd suggest following the same builder pattern for the OBA API requests/responses (for example, OtpBikeStationRequest, and use Jackson data binding the same way as well (which means you'll need to add model objects for the response like the existing model objects). The OtpBikeStationRequest is a good model as uses the OpenTripPlanner REST API, but it builds on the RequestBase used for the OBA REST API. This NWS API client could follow the same model - re-using the OBA REST API code but targeting a different API endpoint. Ideally any new model classes would be in Kotlin, as well as any other new classes. If you're new to Kotlin model classes are a good way to start.

Is there any general style-guide for designing components to follow?

For Android I'd follow the material design guidelines, if there aren't specific existing material design icons that work:
https://material.io/design/iconography/system-icons.html#design-principles

I'd prefer to import any assets as vector icons into OBA Android, versus adding more PNGs to the project.

@aaronbrethorst @ualch9 What assets are you using for the iOS UI? I'd be curious if there are any we could re-use on Android.

[ualch9]

@barbeau definitely before Dark Sky ends, I'm hoping for barebones functionality by the end of the month and the server to work by the end of October.

For assets, we're using the Apple SF Symbols, which can only be used on apple platforms. Therefore, I'd recommend Material icons. There are also icons that the NWS and Canada provides that is free to use, i can provide more details on that if interested.

[tuesd4y]

@barbeau Sounds good to me. A kotlin model won't be a problem for me as well and I'll take a look at the OtpBikeStationRequest next. In the meantime, I've created a first draft of how this feature could look like (similar to the iOS variant). Looking forward to feedback / improvement ideas!

The NWS API also responds with some "icons" but I think they don't really fit the app's design.

[barbeau]

@tuesd4y That looks like a good start! A few suggestions:

1. I like the unobstrusiveness of the Google app weather icon (see below). I'd be in favor of getting rid of the text description, and shrinking the text to be the same height as the icon. Rounding the corners would be good, too - perhaps using a similar oblong shape if it fits.
2. We should add "F" or "C". There is a "preferred distance unit" preference - we could do something similar for "F" vs "C".
3. Maybe tint the black overlays to the theme color, or dark theme color if that's not enough contrast?
4. We should probably align with the same left padding as the Google logo so they look aligned
5. Should we link this to something on touch that shows a weather forecast? If so, what? Does NWS have a good forecast page?

Google App weather icon:

[amrhossamdev]

I can work on this.

[aaronbrethorst]

@amrhossamdev sounds good. Please write up a plan that describes how you're going to tackle it and share it with me before you get too far into coding, ok? Talk w/ me on Slack if you have questions!

[amrhossamdev]

Sure, I will be sharing a plan soon.

[aaronbrethorst]

fixed by #1174