Road condition ratings have been a fundamental aspect of this site since its inception. However, it's had some major limitations. Namely that the condition ratings apply to the entire road and that each road can only have one condition. As you can imagine this leads to an inaccurate picture for many roads. Some are smooth sailing for the first half and completely impassible after. Do you then mark the road as good condition or impassible? I've long known that multi-condition road ratings were the answer to this and it's been one of the most requested features for the site. However, it's technically quite challenging. There's the issue of how to render/display a road with multiple conditions, how to store it in the database and how to handle users adding new reports, road geometry changes and so on.
I finally set about tackling this issue over a month ago. I won’t get too technical, yet, but there were multiple complex changes that had to be made to support this functionality. I had to develop a custom plugin for rendering multi-coloured roads, custom merging and reconciliation logic for condition ratings and a simple to use condition rating slider for users to add their ratings.
So with that, I’m pleased to announce multi condition road ratings! I hope you all enjoy the feature. It was a major challenge to create, but an enjoyable one at that.
I've been working behind the scenes to get multi-condition road bulletins up and running, but there's lots of work left to do. In the mean time I've made a few small tweaks/updates
It's long been time to have a more official website name than roadstatus.searchthesummits.com. So I've migrated the site over to backroadstatus.com! I'll keep the old domain around for awhile to ensure content stays accessible, but in a month or so I'll officially shut it down. This new URL will hopefully be much easier to memorize and type in!
I've also included the Alberta Wildfire's layer so users can view active fires for both BC and Alberta now!
It's officially been one year and a few days since I started testing out an idea for making a service road status site! At the time there were a number of resources like Backroad Mapbooks or Bivouac.com which all had a road report feature, but required a paid subscription. I felt very strongly that for a site like this to succeed it needs to be free and open for all to contribute. So I set about seeing if I could make a free alternative. By some luck the BC Government had a pretty good dataset with all of the main service roads available for download and use. The data needed a lot of work to have it ready for the site and many roads have since had to be manually added in. But it was a great starting point and I'm very thankful for its existence.
Initially I wanted a very simple core set of functions:
I shared the site for the first time on October 4th, 2023 with those core functions in place and since have added a significant amount of features. Some user facing and some admin-side. I'll list a few of them below:
The list goes on, but you get the idea! Just for fun here's the very first photo of the website I took when I started development:
It's certainly come a long ways! Much more to do, but I'm very happy with where the site is. The main focus is on continuing to promote it as the more people use it the better it gets.
In other news, I've made a few changes to searching! The search functionality has always been a bit limited on the site and that's in part because the underlying datastore doesn't support a very rich search functionality. What's more is that you could only search roads. However, it occurred to me that most users don't know the specific roads to take. They're more concerned with the destination. So, I've overhauled the search bar and it now uses a third party API to search places as opposed to roads. For example, you can search Stoyoma Mountain and the map will zoom in on the peak and load all the roads around it. I think this will make planning for a journey, much much easier!
Other UpdatesIt's been a busy alpine climbing seasons, so I haven't had much time to make updates. However, the site is moving along well and I feel the site has reached a mature state. I still have lots of ideas for improvements but for now they will be small ones so I can focus on taking advantage of summer!
Another very small updated. Added support for uploading webp images from the bulletin as per a user request. Thanks to all who provide feedback, you help make this a better site!
I've been pre-occupied with some life events, so updates have been put on pause. However, reports continue to flow in so thanks to everyone who has been adding them. We're now at over 1,000 road reports!
With an early start to fire season, I realized it would be useful to find a way to display wildfire information on the map. After doing some sleuthing on the Wildfire Situation website I discovered there are a number of actively updated datasets available to the public. Normally, I'd import these datasets into the road status system, but for such a frequently changing set of information it didn't make sense to implement new logic for storing and displaying it. Thankfully leaflet/esri support adding layers from external datasets without any modifications required on the road status side of things. This made it fairly trivial to incorporate new data layers such as fire perimeters and fire points on the map! I did have some issues with layer ordering causing roads to no longer be click-able, but resolved it by using SVG rendering for fire information instead of the canvas renderer.
Other UpdatesJust a few small updates this time around, while I investigate multi-condition road lines and some other requested features.
UpdatesThat's it while I'm vacation for the next while! I have plans to support multi-condition roads next. For example a road that changes from good condition to impassible midway through
Updated the map editor to allow existing roads or roads that were just drawn to re-enter "draw mode" and continue adding new points and remove waypoints in bulk. This was a major pain point and sole reason for not allowing other users to edit roads. I felt the experience would be too buggy and unusable. What do I mean by that though? Well the map editor has two modes: draw & edit. When you create a new road, the map editor uses the "draw" mode and any time you click on the map it will add a new point and connect the road segment from the last drawn point. The map editor will consider the road complete when you click "finish" or click on any existing point on the road you've just drawn. However, if you're drawing a super long road and it happens to have tight switch backs then you'd end up turning off draw mode accidentally when clicking on a nearby waypoint on the switchback. There was no way to re-enable draw mode and so you'd either have to start all over again or put the road into "edit mode" and manually drag each road waypoint along the map. Another pain point was removing parts of a road. The government datasets tend to have very dense amounts of way points for each road and so you'd have to remove 500 waypoints just to delete one kilometer of road. Now you can select an area of waypoints and simply delete them! These updates were long overdue both for my sanity but also for opening up the editor to allow others to make contributions. It paves the way for the "suggest an edit" feature I've had on my radar for awhile now too.
I've also completely overhauled wildlife closure zones and how they work. When I first added them in, the government only had zones from the Sea2Sky available for download and import into the system. So I added them with the intention of manually drawing the rest. However, I started to realize that the closure zones further east were quite complex. They had numerous exceptions like "road A open Jan 1 to April 1, road B closed all year, road C open...". I made the decision to add logic to support these exceptions/overrides while still marking roads in the closure zone as closed. A week ago I discovered that the complete set of closure zones had been added to the government data catalogue at last and immediately looked into incorporating them into the site. I realized after looking through the data, there was no sane way to manually add in all these road exceptions. So I decided to simplify everything! Closure zones no longer mark roads as closed. Instead a notice will be posted on the road (thanks to the notice system overhaul) with a link to the regulation/map. Users can then figure out what the policy for the closure zone is. This ensures that the regulation can change without updates needed on my side, while still informing users that a given road may be affected by vehicle closures.
UpdatesI've added another small update and that's the ability for admins and maintainers to pin bulletins to the home page. The hope is that especially important bulletins can be highlight on the home page for a longer period of time.
Other UpdatesI haven't done many updates in the last month, but that's because the site has reached mature point where I feel enough features are in place for it to run itself. With that being said, I was feeling another wave of motivation to make some improvements this week. One feature I've wanted to add for a little while was the ability to include road features such as bridges, gates, etc into the GPX download on the road page. I recognize not everyone wants waypoints included and so I've introduce a new download dialog that lets you select whether you want to include features or not. This work required a bit of an overhaul on how I store features in the backend, but now that's completed and in a much better place.
Other UpdatesSince adding in a basic map legend, many new features and map elements have been added to the map. None of these have been added to the map legend, as it was difficult to update. The design was also limiting and would be challenging to accommodate all the new map features. I've had it on my list to update for a while and now it's complete! See below or click the map legend icon on the map!
Other UpdatesUsers can now view pending, active and retired cut blocks on the map! Roads alone don't tell the whole story and if a given road has no reports, recent logging activity can give you clues about the status of the road. New cut blocks also indicate where logging road access is going to improve and what new areas will open up to explore. This update really starts to form the map into a cohesive road research tool. I hope everyone enjoys using the new overlays as much as I do!
Other UpdatesI designed the system from the get go to support importing new roads as the FTEN dataset (BC Gov's road data) evolved! When I first imported the road data, I kept track of a unique object (road) id from the government dataset, so that when I would reimport new data, I could check and deduplicate existing roads. In the name of moving quickly to develop features, I didn't do my homework and discovered a major issue with my approach. Yes.. this is a common pattern in my project, but so it goes in the pursuit of trying to deliver features as quick as possible.
Anyways, I found out the unique ID I was using changes any time a road is updated and as such not useful at all for eliminating duplicates. From this began a long journey of finding out that the BC FTEN dataset is managed by a lot of people, each with their own methods and processes and none of which are standardized. That means finding a set of properties to uniquely identify a road and track its evolution through the system is only possible in about 96% of cases. That's not bad, but 4% of ~269,000 roads is a lot roads to clean up and fix still. I even reached spoke with some of the GIS support team from FTEN and it turns out that most people simply import the latest version of the dataset, do their analysis and discard it. They usually do not need to persist road information and as such uniqueness of each road is not important. I also learned the reason that my existing road set has quite a few overlapping/duplicate roads. When a road is marked as retired, they generally stop displaying it on the map. So rather than modify retired roads, employees will simply draw over new roads and as such duplicates are born. I could resolve this issue for myself too by only displaying roads marked as active in the system. But I want to preserve all roads for historical reasons and because they may be of use for foot/bike travel still.
Through lots of trial and error I did find a somewhat palatable solution and had to adorn all existing roads in my system with a new set of fields from the dataset to make it possible. I couldn't and won't ever be able to eliminate all duplicates as it requires too many heuristics. But, I can get close enough to manage it for now. With that you'll notice that around ~3,000 new roads were added to the system today. The first of a likely bi-annual process to import the latest datasets.
I am considering one alternative, which is to take the latest road dataset and simply apply existing road reports/created roads on top of that. In that way, I won't have to do any deduplication checks. But it's risky if they remove old roads, or roads with reports associated to them. Something to think about for the future.
Other Updates:
An important aspect of any road system like this is being able to easily highlight key information to users. These are things like road closures, construction, gates and more that are important to know right up front. Prior to today, a big notice would appear on a given road page for any posted road closures. However, this system was limited as there are other types of notices that are worthy of being highlighted. What's more is that notices in most systems can become stale if they are not being actively cleaned up. That's a hard task in a system with 290,000+ roads.
That's why I spent a fair bit of time implementing a better notice system. Now admins can post important notices about anything that's worth highlighting and it will appear at the top of the given road page just like road closures. I've also added in an expiry mechanism so that notices can be given a specific end date and the system will automatically clean them up. I used this to my advantage to automatically post notices to roads where flooding was detected. Users viewing previously flooded roads will be made aware of the recent flooding and that road conditions may have changed. After 5 days the notice will expire and be removed!
Now I'm working on getting the system ready to import new road updates from the FTEN dataset. That's exposed a whole whack of issues that I'll dive into more on the next site update.
These were just some minor updates while I work on overhauling the system that displays important notices about roads. I'm going to add support for temporary notices and displaying multiple notices at a time.
In order to protect wildlife during sensitive times, the government of BC often restricts motor vehicle access to roads running through certain areas for fixed periods. However, finding out about these closures requires you to consult this massive document and look for all roads you intend to cross. That's if you're even aware the document exists. These closure zones are poorly advertised and most people find out the hard way. Either driving for long distances to reach a locked gate or getting yelled at on social media after the fact for not knowing better.
Well the days of guessing are over! I've now added closure zones directly onto the map. You can see active closures as well as currently inactive ones to get an idea on whether your route will be impacted. Furthermore, if a zone becomes active all roads within that zone will automatically get marked as closed with a notice on the road page as well.
I'm starting with the closure zones in the Sea2Sky area first as those were available for download from here. However, the other zones need to be hand drawn and imported. I will do this in my spare time until they're all complete.
While working on a new feature to display wildlife closure zones, I had to reduce the number of waypoints used to draw these zones on the map. I was using a Kotlin version of Simplify JS and it occurred to me that maybe I could run this when returning road waypoints as well. It's actually not the first time I thought of using this, but my original idea was to modify all the underlying data to remove unnecessary waypoints. However, I never quite found it palatable to irreversibly modify all the road data like that. Simplifying the coordinates before returning the road waypoints to the map might be the best of both worlds here. It should in theory drastically reduce the amount of data transferred and time spent drawing the roads as well as leaving the underlying data untouched.
I had a feeling that it would incur a high server-side time penalty doing all that extra processing, but there's only one way to find out! So, I added in a test parameter to the api called tolerance that I could then set to different numeric values to find the balance between reduced road waypoints and a still well defined road. You see if you remove too many waypoints the roads will look like straight lines with sharp jagged corners. Not great for a map! The results were pretty spectacular. To my surprise the server side penalty was negligible. We're talking just a few ms!!
There was one problem though. If I reduced the number of way points by a certain amount, it would look fine at the given zoom level, but then as you zoomed in further the roads would look horrible. It then occurred to me that I could set the optimization level based on the zoom level of the map. When you're very zoomed out you can't see the finer details of the road anyways, so might as well aggressively reduced the number of waypoints. These zoomed out requests also happen to be the slowest as it's' including roads from a massive area. As you zoom in, you want more granular road data and so waypoints are reduced even less. Finally at the smaller zoom levels, the amount of data being returned is so minimal that no optimization is needed and we can return the highest fidelity road data. LeafletJS, the client side javascript map I use, actually already does this to save map drawing time. But the server still has to send all those unoptimized coordinates first. So it makes sense to do it on the server side too,
To test the results, I chose 3 different zoom levels on the map and picked a relatively dense area. I then ran the requests multiples times for each zoom level to get a sensible average.
Zoom Level | Average Response Time Before | Average Response Time After | Delta |
---|---|---|---|
11 | 955.83ms | 532ms | -45% |
12 | 359.67ms | 219ms | -39% |
13 | 135.5ms | 102.8ms | -24% |
Zoom Level | Data Transfer Before | Data Transfer After | Delta |
---|---|---|---|
11 | 1540.00kb | 159.61kb | -90% |
12 | 538.49kb | 100.60kb | -81% |
13 | 241.39kb | 98.53kb | -60% |
As you can see the response times and total data transferred are drastically reduced. This will make the map feel snappier than before, even with slower connections. The minor trade off is that some roads have a lower fidelity appearance at certain zoom levels, but its subjectively quite negligible.
Alright, this update is a subtle one, but in my opinion the numbers show it's worthwhile. It all started a few weeks ago when I discovered what each decimal place in the latitude/longitude waypoints of the road represented. I found out that in a pair of coordinates like 49.123456789, -121.123456789 the 5th decimal place represents 1.1m of precision and the 6th decimal place represents 1.1cm. Beyond the 6th decimal place the precision is so small that it's really no use for something like road waypoints.
Why is this relevant? Well the government dataset that the Service Road Atlas is based off uses coordinates with up to 13 decimal places!! Not only is it highly unlikely the government was measuring roads with nanometer precision, it's way more information than we'd ever need.
Let's take a road like Harrison East FSR. It has 2368 waypoints with a latitude/longitude having 13 decimals each. Remember, we only need 6 decimal places. So, that's 7 extra numbers for each part of the coordinate pair. Not only is that a lot of extra data to store in the database, it actually significantly increases the load times on the road map because all of that extra data which must be transferred to your browser.
I was aware of this issue a few months ago and put a small band-aid in place. Before serving the road waypoints, I would truncate the lat/long values to 5 decimal places which reduced the network transfer time. However, all that extra processing had a noticeable increase in CPU time taken to process the request before serving it. I knew I'd need to address it by updating all entries in the database to use 6 decimal places, but it's a bit scary to change the ~260,000 road entries in one shot.
With some testing, I decided that I wanted to use 6 decimal places instead of the 5 I had been serving. The reason was 1.1cm seemed better than 1.1m even if it's unlikely the dataset is really that accurate. The one downside to this is I'd be serving up slightly more data (there's one extra number in each coordinate now) but with less CPU time spent compressing/truncating the values. After some rigorous testing and backup policies in place I finally ran a coordinate optimization pass today and the results are instantly noticeable! The data transfer time for the extra decimal place is definitely offset by the reduction in CPU time spent serving up the request.
Testing was done against the same set of coordinates and the numbers are as follows:
Average Response Time Before | Average Response Time After | Delta |
---|---|---|
610ms | 480ms | -22% |
Data Transfer Before | Data Transfer After | Delta |
---|---|---|
2.96mb | 3.18mb | +7% |
So we saw ~7% increase in data transferred but that still resulted in 22% reduction in response time overall. Now for users with extra slow connections they may not realize this benefit, but I feel the average user will certainly feel the map being much zippier!
First update in the new year, as I was quite busy participating in interviews for a new role! I ended up getting an offer and so work on this site will slow a bit as I transition to a new company, but rest assured I will continue to develop some new ideas I have! The new updates this time around are minor but worthwhile changes and some bug fixes
Last big update of the year: "road watch" is now live. Registered users can now subscribe to road updates and receive notifications and emails whenever a road they're watching has a bulletin posted. I've also extended this system to forward comment notifications to your inbox if they go unread for more than 24 hours
Don't want to receive emails? No worries, there's an email preferences page where you can unsubscribe from your profile or through an unsubscribe link in your email.
Another big site update! You can now add replies to user contributed bullets! Have a clarifying question or just a general comment? You can now leave a reply and the creator of that road bulletin will get notified. This work required creating a notification system which paves the way for notifying users when roads change.
A few other changes of note:
I will work on a road watch system next and email notifications (unless there's no desire for this)
Just a few small updates this time around, while I work on implementing comments/replies on bulletins
Facebook Login is now available through the login page! It has been my goal to have this feature enabled from the start, but other priorities took over. Many of the communities that might find this site useful are organized around Facebook Groups and so being able to seamlessly login and contribute has been a fundamental part of the experience I’ve been hoping to create. I originally created this site to improve on the existing services that are available. Many are behind a paywall or have a lacking user experience and I always felt that in order for a site like this to succeed, adding reports needs to be as frictionless as possible. The metrics and time will now tell whether this was a worthwhile addition, but if even 10% more users want to contribute via Facebook Login then that’s a success in my books!
Head over to the login page and try it out for yourself! Note that if you already have an account with the same email address as your Facebook, this login won't work. You'll need to continue to use your original email + password combination. For new users this should reduce any friction to sign up!
As for the technical details... because who doesn't love those? Well, it seems the golden era of Facebook API usage is over. Even Facebook Login which has traditionally been quite easy to setup, now requires a registered business and passing a vetting process in order to enable it. Thankfully, I was in a position to set this up, but I can see for most hobby style sites or personal projects it's a non-starter and that's a bummer.
The integration itself wasn't too challenging as Springboot does a lot of the heavy lifting for OAuth integrations. However, some thinking was required to figure out how to integrate Facebook users with the permissions system in use for locally registered users. I think I've found a tenable solution, although I'm not sure how idiomatic the approach is, but hey it's working. Time to focus on some other key features! A notification system has been asked a few times now as well as a means for editing photos on bulletins.
This was quite challenging and honestly the work is far from over. I've decided to release it in its current state to get feedback and to review the performance. I started out by using a Leaflet Plugin called StreetLabels. But it only worked well on very straight road segments and with numerous map breaking bugs. Adding to that FSRs have the unique property that they often have multiple steep curves and it makes rendering the road label quite difficult. To alleviate some of the problem I had to modify the plugin code quite heavily. I optimized the drawing of labels in a number of ways: