SignalK / specification

Signal K is a JSON-based format for storing and sharing marine data from different sources (e.g. nmea 0183, 2000, seatalk, etc)
Other
91 stars 69 forks source link

Weather Forecast #215

Open raffmont opened 8 years ago

raffmont commented 8 years ago

Hi! I lead the development team of this project: http://meteo.uniparthenope.it We produces multi-daily accurate weather forecast over southern Italy, seas around Italy and Mediterranean Sea. I'd like to add APIs compliant with SignalK. Any plans to add weather forecast in the data model? -- Raffaele

tkurki commented 8 years ago

It sounds like you would have way more expertise on this field than anybody else involved with the project.

I know that people have great interest in weather routing, but sadly it is a field I know next to nothing about.

Is this an area that would benefit being in the Signal K data model, at least so far that there is metadata about weather data/services available and relevant to current vessel / in particular circumstances.

I assume that this field has established data formats. Is there something like GeoJSON - WeatherJSON? Because I don't think SK data model needs to be everything for everybody, but it can be the connecting point for information about information of interest aboard.

Could you share your thoughts on this?

raffmont commented 8 years ago

Of course! Two main points:

  1. Point based vs area based weather forecasts
  2. [Geo+Weather] JSON Let discuss briefly:
  3. The most part of web APIS return point based weather forecast. For example Open Weather return a json with 3hourly point-georeferenced weather forecast. This is good in terms of space complexity but not really useful for sailing when you need weather forecast on a area. For that grib files are the best choice even because ready for weather routing and map overlay.
  4. Unfortunately there is no one really world spread standard json schema for weather forecast. Nevertheless the beloved GeoJSON could be used as container for json forecast using the properties. The GeoJson could represent a point or an area. In both cases storing time series in properties work as well. This approach could appear reasonable even for area based forecasts because the properties could embed the grib file remote url and the local path. I attached an example of grib/geojson and weatherjson/geojson

signalk.openweathermap.json.txt signalk.grib.json.txt

sumps commented 8 years ago

Hi Raffaele, Weather support in Signal K would be welcomed by many boaters around the world. It is important that whatever format we use is open and as standard as possible and that it provides users with a basic worldwide weather service that is free and provides the sort of information that you can get online or from a local news agency. Then if 3rd party companies want to develop higher resolution, more accurate, marine focused weather services that they want to sell as a premium service, there is an open and free format and API mechanism within Signal K for them to publish their paid data through. I think there is some room for point based forecasts, for instance once a user has defined a route, it would be possible for them to check the predicted weather at each waypoint or at the final destination based on their estimated speed and therefore time of arrival. That said, area GRIB files would allow this and much more and should be our focus. I am surprised that there is not more weather data being done with JSON although it does seem that a lot of the APIs are moving in that direction and the results can be quite amazing... http://www.oceandrivers.com/earth-project/ GRIB2JSON seems to be an open source project that might help.... https://github.com/cambecc/grib2json We are busy trying to release Version 1 of Signal K at the end of this month, but I think weather should be an area that we start to work on very soon after V1.
Best regards PAUL

rob42 commented 8 years ago

Hi Raffaele,great idea, and Ive also had some experience with it. I sailed about 6000 miles around the Pacific and Australia, all using GRIB files downloaded over HF radio. It was very successful, we had excellent conditions over most of the journey, and avoided many storms etc that others 'enjoyed'.

So the technical issues are interesting. What I used was a GRIB file for a region, usually wind/waves/temp/pressure over now+7 days, for a region bounded by a rectangle around my location.

So we can do the same in signalk. We already use GeoJson to describe shapes, so I would start with a geojson region defined by a simple rectangle. Its also easy to draw in a browser or other mapping tool.

The obvious and well known format is GRIB, for weather data over time for a region. If we can convert to json thats nice, but its not critical. We can store it as a binary blob. We need a weather structure to define the time period, the resolution for both data points, and time intervals. We need to define a source (uri) and a key to store the geojson and the grib.

With that data structure defined the following should be possible: 1) drag a weather rectangle across your chartplotter, which pops a form 2) Add details like interval, resolution and time span 3) Send - which makes a request to your site, the data is generated and returned asynchronously, possibly some time later 4) The returned message is drawn across the chart. A slider lets you look forward into the future time periods

That was basically how it worked on HF. But it was via SailMail, and very slow. You send your request, and pick up the reply 20 min later. Then a whole lot of work to overlay it on the chart :-)

Id suggest starting with a structure rooted at environment.weather. Add what you need for your site to return a GRIB file, and we will comment and adjust

rob42 commented 8 years ago

Ive been looking at this again as I want to implement real-time observations of weather into my chartplotter. This requires also requires the same technique as the grib forecast, that is to request data for a region rather than a point, or vessel.

I think the solution using signalk is to use a SUBSCRIBE message and include a region and data keys. This implies that a region is equivalent to a vessel in some respects. eg Given we have the region defined locally on our vessel:

"resources": {
            "regions": {
                "urn:mrn:signalk:uuid:c0d79335-4e25-4245-8892-54e8ccc8021d": {
                    "geohash": "rbej:TasmanBay",
                    "feature": {
                        "type": "Feature",
                        "geometry": {
                            "type": "Polygon",
                            "coordinates": [
                                [
                                    [171.0, -40.5],
                                    [170.0, -42.5],
                                    [174.0, -42.5],
                                    [174.0, -40.5],
                                    [170.0, -40.5]
                                ]
                            ]
                        },
                        "properties": {
                            "name": "Tasman Bay"
                        }
                    },
                    "timestamp": "2015-03-06T16:57:53.643+13:00",
                    "source": {
                        "label": "region",
                        "type": "manual"
                    }
                }
            }
        }

Then we can send it to a remote server (weather server):

{
    "context": "regions.urn:mrn:signalk:uuid:c0d79335-4e25-4245-8892-54e8ccc8021d",
    "put": [
        {
        "path": "",
        "value":{
                                "geohash": "rbej:TasmanBay",
                                "feature": {
                                    "type": "Feature",
                                    "geometry": {
                                        "type": "Polygon",
                                        "coordinates": [
                                            [
                                                [171.0, -40.5],
                                                [170.0, -42.5],
                                                [174.0, -42.5],
                                                [174.0, -40.5],
                                                [170.0, -40.5]
                                            ]
                                        ]
                                    },
                                    "properties": {
                                        "name": "Tasman Bay"
                                    }
                                }
                            }
                        }
            ]
        }

and subscribe to parameters within its boundaries

 {
    "context": "regions.urn:mrn:signalk:uuid:c0d79335-4e25-4245-8892-54e8ccc8021d",
    "subscribe": [
        {
                    "path": "environment.wind",
                    "format": "delta",
                    "period": 10000,
                    "minInterval": 5000
                }
        ]
}
rob42 commented 8 years ago

This approach is also applicable to any data based within a region rather than a point or a vessel. AIS data is essentially a region centered on the boat, with a given radius. The data can be taken from marineTraffic.com or other source.

rob42 commented 8 years ago

A region should have environment and notifications. that would allow weather data, and weather reports and warnings, plus Notices To Mariners etc and even emergency alerts to be announced to a geographic region.

toqduj commented 7 years ago

Just here to revive this old thread since I had the same idea but didn't see it yet in the schema. environment.forecast could be a decent addition, e.g. with subgroups for the individual forecast models (GFS/WMF/etc.). Each of these in turn can have a GRIB blob in them, in addition to timestamps for date received, period valid, region, average wind at location, temperature at location, etc ...