Closed roblabs closed 2 months ago
- public let relativeLocation: MKGeoJSONFeature
+ import GEOSwift
+ public let relativeLocation: Feature
IIRC, I didn't want to use GEOSwift.Feature because I didn't want to make this library expose third party framework as public. MKGeoJSONFeature is MapKit, which is okay.
I wrote this a while ago, and didn't write comments. I'm assuming that MKGeoJSONFeature doesn't cleanly decode from NWS's API, which is why I commented it out. I can take a look at this further.
[...] gum up the returning result object with data not in line with the NWS API [...]
Most data should be in line with NWS's schema, however, I think it's okay to be slightly different as long as it improves interoperability with Swift STD and Foundation.
I'm assuming that MKGeoJSONFeature doesn't cleanly decode from NWS's API [...]
after reading the docs, I think that I binned MKGeoJSONFeature since its MapKit, which is not available on Linux.
after reading the docs, I think that I binned MKGeoJSONFeature since its MapKit, which is not available on Linux.
I was thinking that may be the case to allow it to run as a Lambda or a Swift Docker image.
The NWS API is returning
relativeLocation
in empirical testing.It looks like its fairly basic to implement (example on my branch), but I was wondering what would be the best way to return
relativeLocation
with theForecast
object?The current Swift API is very straightforward. But how should we return some of the useful data from the
Points
object? I didn't want to gum up the returning result object with data not in line with the NWS API, so I wanted to see what others thought.Example,