![]() ![]() ![]() Logs are generally plain text, timestamped entries that can be compressed and copied off and archived, whilst a database can be used to obtain different reports. Now you need to store it - write it to logs, and/or to a database store. expected forecasts over 6 hours are required, but it only goes to 3 hours etc. There is a possibility that it won't e.g. Second then look at the sources and see if they can match what you need Do you have screens / keyboards that can be used when crew are fully kitted out, or is this only before getting dressed and responding? Do you need to be able to pause, and go back or forwards to obtain information. The exact way can be entirely dependent on how you want it to run - just leave a screen running 24x7, some action to get it to update.įirst sit down with paper and diagram out what information needs to be presented and how, for example a current radar map, a current wind map and a weather ticker does it also need an animated forecast map if so 1hr? 2hr? 3hr? does it need to be presented all on one map, or split out into several and if so can they be on one screen or flip between every 10 sec. So far you have pulled the information from a source, then you need to validate the information (for example does it show 10M waves, howling winds,etc, and by looking outside it is calm and sunny), and then represent it onscreen. You may want to use multiple sources for the same information and see which closely matches reality at the time, and those that match after an hour or so. In general you will find that public api information might have some delay in it, so you will need to validate to meet expectations particularly with it being a system that can potentially put lives at risk. It might be possible that you have better resolution sources or access through the the RNLI or however you get funded. The last is so that you can determine whether it meets your needs and possibly if used for "after action reports" if you do those, (in other words did it give timely relevant information that is better or worse than your current sources, was it acceptable for use in the situation, did it make it worse by giving incorrect information etc.)įor tidal information, there appears to be several with different licenses on using the information, and can be used with a particular port if you are in the UK, otherwise it will be a google search for "tidal information api ".įor weather, you can pull from any number of sources including the UK metoffice marine weather, , accuweather etc. You will also likely need to archive it to a database, and possibly an offsite store. To cover other uses, and ones that I haven't thought of or mentioned, then you need a method to get the information, manipulate it, store it, then to display it. I believe you can have the browser on the pi automatically position themselves on reopen (you'll need to have resume from "last pages active" in the browser settings rather than "new page") ![]() This could be as simple as just having 2 permanent bookmarks open to webpages containing the data from the metoffice, and for example - you might need to hook in a tool to autorefresh the page periodically depending on the browser you use. ![]() So to start with you need to get the data and examine its reliability and whether it covers the range that you need, then to manipulate it, and present it. You aren't wanting to overlay distress position and current response position or similar You have no current existing access or subscription to weather information systems or tidal information presently (metoffice/accuweather/etc.) that is delivered over the internet (I am disregarding sources such as inhouse weather receivers, radio, fax, pagers, crew mobiles etc.) We will disregard inshore lifeboat as that can be covered by reducing the map presentation of the offshore system. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |