So, I began some preliminary design work on WeatherMan the other day. For this first run I’m probably going to use the UIKit navigation tools for organization. I don’t know whether or not I’ll stay with them, depending on how things look down the road.
For the most part, the program will be fairly straightforward. All data will originate from the National Weather Service. The program will need to be able to take location data (supplied either by the user in the form of city/state or zipcode, or supplied by CoreLocation) and translate it to figure out the correct NWS zone. From that point, it’s a pretty simple retrieval of data from the NWS public access servers, and then format that data for the user. There will probably be a backend hosted on my Dreamhost account to take care of much of the heavy-duty work.
While most of this will be straightforward, there are two or three specific things that will need some major work:
- Geocoding. I will need to make a database of NWS zones and their boundaries, and also figure out a way to translate the city/state/zip user data into latitude/longitude. I believe Google Maps offers this functionality, but I don’t know what limits it has and/or what the cost is for commercially licensed software.
- Radar. My plan is to use the raw radar data provided by NWS and overlay that data onto Google Maps. Unfortunately, that means I need to come up with a way to translate touch events into Google API events, as there is no Google Maps frameworks in the iPhone SDK (WHY?!?!?).
- Advisory notification. This could be the most difficult part. There are two major challenges here: Getting the data, and then getting it out to the end users. There are two options for getting the data: push and pull.
- For the casual end-user of this data, pull is the obvious method. The data can be easily retrieved from the NWS servers on demand. However, since I want to provide notification, this muddles things up a bit. How often do I pull the data to check for new notifications? Too often and I become an unwelcome drain on their servers, and too infrequently I limit the usefulness of the software, as watches and (especially) warnings are very time sensitive. Pulling the data is not a very good option.
- Having the data pushed to me is my other choice. This is how your local news channels and other websites receive their NWS data. I did some research on this today, and it may actually be feasible. The big guns receive their data via a satellite feed. This has very high initial and recurring costs, and is not really an option for a small-time developer like myself. However, the contract between the NWS and their data provider specifies an internet delivery option, which in its most basic form has a one-time $75 charge associated with it. When I say basic, I mean basic: You establish a telnet connection to their server and the data is streamed in realtime. The uptime is a little less reliable than the satellite options, but it should be good enough, especially if I write a cron job to check the status of the process that is reading the data. I’ll need to figure out how to parse the data; though the service has a 30-day trial period I haven’t been able to try it out as the sign-up page is currently offline (hoping that’s not a bad omen). If I can figure things out, this should be the way to go.
As far as sending the data out, it’s not an option at all until Apple implements their notification services. After that time, we’ll see. I’d like to be able to target specific users with specific notifications if I can, but at the same time I’d like the application to be useful from first launch, without the need for registration or anything of that nature. Again, a moot point until the time arrives that these notifications can be pushed out at all.
Due to the costs associated with running this service (Apple’s developer fee, the access fee for the weather notifications, and the possibility of more hosting charges if this thing gets bigger than I think it will and Dreamhost kicks me off of shared servers), I will definitely be charging for this application. The price will be no higher than $4.99, and I’m actually leaning toward $.99 or $1.99. This will allow me to recoup costs associated with keeping this running without introducing a huge cost barrier to the consumer.
