PlaneCrashMap now has an updated look and feel! I've kept he same basic design and theme, but with some updated functionality:
Another major update is coming soon, with plenty of new data and additional details for existing crashes!
I have been busy with other things for almost a year now, and have neglected updates. I apologize to the people that have emailed me- updating the data has taken much longer than I anticipated.
Today I updated the appearance of several pages, with a goal of getting you to the information that you are looking for faster. Many pages have had more links added, and I have enlarged the map on the main page. Tables on list pages now allow for sorting and searching; I hope this makes the site much more usable. Loading time may be significantly reduced on many pages, but I'm still working on that.
I'm hoping to update PlaneCrashMap.com with some of the features of the new site, including a map that loads data when you scroll, instead of having to navigate to a different states' map. I don't have an ETA for these changes, but would expect them at the beginning of next year.
A few states (FL, TX, CA) have a disproportionately large number of accidents included. This leads to a lot of markers on the map, which may make your browser a bit slow. I have found all of these pages to be at least usable on my PC in Mozilla Firefox and Google Chrome. Internet Explorer, however, really has trouble with them. This was expected, as IE has pretty poor Javascript performance (relative to Firefox and Chrome). I've added (resurrected, actually) a warning to the top of the site recommending some other browsers.
My time has been spent more lately on some other projects, including another mapping site, covering a different subject. However, I have been able to port over some newer code from the other site in a way that makes the back end of this site more effienct, and and should enable some new features in the future. As traffic to this site goes up, I plan to give more attention to it. I have found a couple additional sources of data that I will be adding around the Christmas timeframe.
As usual, feel free to send me feedback on the site, or to suggest some new ideas. My contact information can be found on the About page.
I never have enough time to make the substantial updates that I want, so I'm adding a couple of easy states. I'm not very far away from just adding the rest of the US; however, it seems like around a dozen states have unexpected issues in the data that I have to deal with (for instance, one state I was going to include had a single quote in one of the plane's tail numbers- weird!).
The new data should increase my hitcount a bit, giving me more motivation to work on the site more. I have even more data to add to the site (from the NTSB databases), as well as some cleaning up to do to make the site more presentable. I don't have an ETA for these changes yet, but expect something in about two months...
I've added planecrashmap.com to point to this site as well. This should hit more keywords that people are using to find the information on this site. This should be tracked separately in Google Analytics, so I'm interested to see what it will do without many external links.
I've added ads today in order to try to pay for the site, rather than run it as a charity out of my own pocket. I hate to do this, but it seems like the only appropriate way to run the site. Asking for donations doesn't seem like a great thing to do. I hate ads as much as the next person, but hey, it seems to be good enough to keep most of the rest of the Internet paid for, maybe it can work here. I'm really just looking to pay for the hosting. It would be cool to develop this kind of site at home for a living, but I'm going to keep it as a hobby right now (and thus don't really need too much income from the site). So, if you've clicked on an ad, thanks.
I will try my best to minize intrusiveness of ads, as well as minimize their use.
Also- I'm noticing now that Google has deemed it appropriate to put ads in some oriental language on the front page, while using English ads (that seem a lot more relevant!) everywhere else. I wonder if I did something to bring this on?
I've been thinking about ways to fix this problem, possibly by presenting different pages to the Google indexing bots. This doesn't seem right, and seems like a lot of work. The future plans for the site have been modified to include many more static pages, or at least static-looking pages (through the goodness of apache's mod-rewrite). I think having more pages with static URLs, and static HTML content should provide much more information for Google to index, and provide a lot more hits, as well as be a useful way of presenting information. Static pages for each crash incident, as well as static pages containing lists indexed by date, by state, or other parameters should provide the content that Google needs to index.
I have also modified the maps to use the Google maps 2 interface. This has been in the works for a long time, as it required a bit of the code to be rewritten. During performance testing, I found that the bulkier Google Maps V2 interface worked much faster than Google Maps V3 in IE, despite claims that the V3 interface was a lightweight interface. I am happy to report big speed gains. I attribute much of the gains to more mature code, even if it is more bulky. The version 2 Maps API has many more available features and libraries, and I look forward to adding some of these to the map interface.
I'm about to finish a big update. I've been working on performance in Internet Explorer for almost two weeks now. Map initial render is really really slow (~2 minutes for some states) compared to other browsers (all under 7 seconds). Until a few days ago, I wasn't able to discover the reason for this. I finally figured out that IE doesn't perform well in code that heavily uses closures, a more advanced javascript feature. I have been using the Google Maps API version 3, which heavily depends on closures. This worked well in Google's browser and Firefox initially, so I stuck with it. It is supposed to be a lighter, higher performing API compared to the very popular but more bloated version 2. I didn't find this to be the case.
I've switched the state maps to the version 2 API, and have observed a large performance increase. I hope to land this update on Thursday, the next update day in the 3 day cycle that I am sticking to. I hope to also include several usability enhancements, such as the ability to dynamically load multiple states' maps on one page on demand. After these few map usability updates, I will focus on adding more detailed information about each crash to the site, likely to include pages for each crash, and likely a Wiki for each one. I'd like to eventually find more data sources, but I don't think that there are any more out there. The only remaining untapped data source is you, reading (and, in the future, contributing!) to this site.
I am pushing out an update that applies manual corrections to many of the city names. I continue to make progress in reducing the number of un-geocodable entries that are listed below each map.
Arizona and Colorado both a disproportionately large number of misspelled names. Arizona suffers from having many unusual town names, while Colorado has many two-word town names. In particular, the NTSB seemed to like to abbreviate any name that was over a certain number of characters. NTSB reports seem to be totally inconsistent in the way that "Springs" is abbreviated- Colorado Springs had 8 variations in different reports, as did Steamboat Springs. Pagosa Springs, Glenwood Springs, Hot Sulphur Springs and Eldorado Springs are also massively misnamed or misabbreviated. Some Arizona towns had almost funny misspellings: Mormon Lake, AZ was spelled as "Morman Lake." Truth or Consequences, NM was misspelled as "Truth&consequen, NM" which doesn't seem right at all!
In other news, I am preparing to deploy a solution that should yield faster loading and rendering, especially in Internet Explorer. I have been a bit worried that the site is totally inaccessible to IE users due to poor Google maps performance. While I provide a warning on the front page, I do think that it greatly decreases the appeal of the site. I expect this update to be ready on the next update day (8/31/09).
It is interesting to note how many more orange markers Oregon has than green. This indicates that the Air Force dataset that I draw exact locations from doesn't have many of these locations, meaning either that the air force doesn't have as much of a presence in that state, or that the aircraft are harder to spot from the air (or both). Montana is very similar in this respect.
There are two main sources of faster loading. First, the actual files downloaded for each page are much smaller. For instance, Colorado, which has approximately 740 accidents marked on the map, was reduced in file size by 65%. Most other states show similar amounts of reduction.
Page size is still the reason that I haven't included several more states in the maps. California in particular has so many aviation incidents that that the page with the map on it is the better part of a megabyte! Until I can implement a streaming data solution, or work on some kind of data compression, the bigger states are still right out.
The second optimization technique uses less Javascript to load the initial images on the Google map. While I was doing this, I also fixed the issue where you can have multiple information bubbles open at once, obscuring data. Information bubbles also close when you open another bubble. This should yield a noticable decrease in the amount of time that you wait for icons to show up on the map when the page is loaded. An informal test shows Colorado loading in about 7 seconds (from 12 seconds), and the more sparsely populated Wyoming improved from 4 to 3 seconds on my machine. I believe that these times can all come down to around the two second mark, and will continue working on improving the user experience.
I consider page load to be one of the largest user-visible problems right now. Other problems, like inaccurate data, or the weak selection of links to other data on the web probably harm the user experience more, but these will be fixed soon! There are many opportunities left to squeeze the page into a smaller size, and you can expect me to take these opportunities as time permits.
I plan on adding more dynamic loading of the pages soon, both to decrease load times, as well as to make moving from one state's map to another as painless as possible. With time, this transition may just happen automatically!