FME’ers; I’ve covered QR codes before, but looking up that post I’m astonished to find it was six years ago. Six years! FME is certainly a lot different from then, and so is the world of GIS and mapping. In particular, one area of increasing importance is the spatial tracking of mobile assets.
Let’s pretend you’re a city maintenance department responsible for recycling bins; or a utilities company putting temporary equipment into the field. You would certainly want to know where those assets are, and you’d want a way to identify them. You might even like a way to update their status when they’re moved, or to get help finding missing equipment.
Well I think you can do all that and more with a combination of FME and QR codes. So if you thought QR codes were of no interest or use to your organization, read on and I promise to show you something special to change your mind!
What are QR Codes?
First a brief refresher: if you remember, QR (Quick Response) codes are simply a form of two-dimensional barcode. Once created people scan it with their phone and get directed to a specific web page, map, or other resource:
Previously I’d shown how to use FME to create codes, and Dmitri has an FME hub transformer to do that. I also think one of our users had a solution for reading them with FME. Plus iOS now allows scanning codes directly with the camera – no app required – which makes these codes much more usable.
QR Codes and Assets
I don’t think it’s unique to stick QR codes onto assets such as benches, lampposts, or other street furniture. In fact the city of Beijing does just that, so that malfunctioning equipment is brought to their attention more quickly. A colleague told me that QR codes in general are a big deal in China, so that project’s not a surprise.
What about spatial data? Well it’s true that a lamppost (or “street lighting column”) does have a position in the real world. But as a permanent asset in a fixed position, its location is less important. We already know where it is and it’s not going to move.
But say the asset is something mobile, or it’s only a temporary placement. In that scenario location is much more important. But it’s also why traditional QR codes fail us, because QR codes deal only with coordinates that are fixed and written into the code. To record an asset’s location when the code is scanned is not possible.
What we need is some way to send location coordinates (to FME) via the QR code, and a tool called qrd°by lets me do exactly that.
qrd°by is a tool that generates QR codes. There are many similar tools online. But what is unique about this service – or at least I could find no other – is that the GPS coordinates of the mobile device are included as part of the URL.
As you can see in the above image, I’ve created a QR code by entering a URL. To integrate with FME the URL is just a link to a workspace on an FME Cloud/Server instance. Because the GPS option is turned on, qrd°by amends the x/y coordinates to the end of the URL when it is activated.
How do I handle that in FME? I simply use Published Parameters. Let’s take a look at an example…
So of all temporary assets that are deployed into the real world, some of the most obvious are election campaign signs. I suppose that’s because they are brightly colored and meant to be seen.
However, such signs are small and lightweight, and prone to being moved or blown away. Additionally, because of their low cost and tendency to roam, many signs never get picked up and remain an eyesore long after the election is complete.
But put a QR code onto each sign, connect it to FME, and we suddenly have a solution for most of those problems. Here’s what I did to demonstrate that…
The FME Workspace
In the Vote FME campaign we want to know when and where a campaign sign is place, and when it is collected. Here’s my workspace (click to enlarge):
Here are the published parameters:
It’s really very simple. The workspace sits on FME Cloud and responds when the QR code activates it. No reader is necessary. A Creator kicks off the process. I’ve included a sign ID (more on that below) and the lat, lng parameters are what qrd°by adds to the URL (I couldn’t find those keywords documented, so be sure to remember them)! The coordinates are turned into a point geometry.
The DatabaseJoiner and FeatureWriter transformers are there to handle storage of the data. Obviously the project isn’t much use unless I store the location and other information. Here I am using a Spatialite database. The Joiner checks the sign ID to see if it exists already. If it doesn’t then we assume the sign is being put into position. If it does exist then we assume the sign is being picked up.
Finally I write a little HTML to give a response to the person scanning the code. I could also add an Emailer transformer (to let the property owner know we’ve delivered their sign) and a Tweeter transformer to boast about how many signs the Vote FME campaign is placing!
The workspace is then published to server and registered with the Data Streaming service.
Now let’s see the qrd°by integration.
Here I create the QR code, set a sign ID in the URL and turn on the GPS tracking option. And… well that’s it. All I do now is print the QR code on my sign and scan it:
When I scan the sign a web browser prompts me to open the URL and share my location:
The prompt can’t be bypassed, but qrd°by allows the message that’s presented to be customized.
At this point the URL is triggered, the workspace is run, and the location recorded in the database. I receive a confirmation message back:
And that’s the basics behind the project. Try it yourself by scanning the above QR code (remember, I will get to see where you scanned it)! It’s really very simple to both set up and to use. It took about 4 hours for me to create, but then I didn’t have a set of instructions like you do! I hope you can see that it forms the basis for any asset-tracking project, even if it is a bit basic. The qrd°by website talks about tracing pets, which is certainly a good use, but I think there’s definite potential beyond that!
Incidentally, their website also provides statistics about the QR code, including a map of where codes were scanned; though obviously most FME users have probably already got their mapping needs covered!
The Asset ID Number
The sign (or asset) ID is an interesting topic. Assets in a fixed location don’t need an asset ID; at least not in the QR code. If all my lampposts have the same QR code I can infer which lamppost is scanned by its location.
But if the asset is mobile I can’t do that. It needs an ID to identify it and so I need a sign ID number as a published parameter in the URL. This means that each QR code must be unique and the question is, how would I do that when handling hundreds of assets? Would I have to manually create all those codes?
Well, no. Like other services, qrd°by has an API, so a workspace with a HTTPCaller can create as many QR codes as necessary. Then we export them and pass them on to whoever is printing my signs (or stickers).
I bet you have a few questions, the main one being what happens if a member of the public scans the code? Well if someone did scan the code then there are a number of possible scenarios.
Firstly, my election signs are date sensitive. Say the election day (E-day) is 22nd May and sign collection day is E+1. If someone scans the code before that date then they are simply redirected to my web page. On E+1 the project flips into collection mode. If someone unintended scans it we simply add the message “If you scanned this unintentionally, replace it and scan again”.
Additionally, on E+2 we flip into lost-asset mode. Any scans alert us to a sign that has not been picked up – and where – and encourages the public to scan the code for that purpose.
Another solution is to have FME generate the HTML before the database is updated, and make that HTML a web form. An authorized user can enter a password to access a set of options for the asset, each option running a second workspace. A non-authorized user can report vandalism or damage, or report an asset in an unexpected place (like a shopping cart in a garden), but wouldn’t be allowed to report maintenance or collection.
Finally, there’s always the option to test spatial location too. For example if I scan the asset – whatever it is – outside of its expected location, that can trigger a different set of actions; like in the case of a lonely garbage bin.
Although my example was election signs, there are many other assets I think would be worth tracking, for example:
- Municipal assets like garbage/recycling bins (the wheely bins that can have a tendency to move)
- Bicycles or cars that are part of a sharing scheme (which would also give proof of a drop-off location)
- Shopping carts from a supermarket
- Railway assets like carriages and other rolling stock
- Utility company temporary assets, like portable generators, transformers, or electrical panels
- Medical samples! I’ve seen blood sample tubes with a QR code. I don’t know if location is as important, but who knows?!
Here are some other possibilities for this technology:
- Using a workspace with database allows multiple forms of FME data transformation. For my sign project when someone picks up a sign, FME can tell them where the closest other sign to pick up is (a simple NeighborFinder) and supply a route (ShortestPathFinder). It can also tag that sign in the database (SQLExecutor) so that no other helpers are sent to collect it. Alerts may also be sent by email, text, Twitter, or any other FME Server notification protocol.
- If an asset is known to be lost, then the HTML response to its tag being scanned could offer a small reward for finding it. That would particularly apply to lost pets (which is an example specifically mentioned on the qrd°by website).
- I mentioned online forms earlier, and recently a colleague pointed me towards tools such as Fulcrum which create/manage such forms. FME is very efficient for generating HTML reports, but less so at generating custom HTML like forms.
- I’ve seen some mention recently of Dynamic QR codes. That’s when the QR creation service actually encodes a URL of their own, which – when scanned – redirects to your URL. That means you can change your URL at any time without having to change the QR code. It’s true here and in fact this is doubly dynamic because the FME workspace it links to is dynamic as well.
- For fun you could also use this as a form of mobile geocache, on something like a vehicle. For example, Safe recently sponsored Driving Wintech a project involving driving across Canada on a fact-finding mission about women working in technology. Having a QR code of this type on their vehicle would have told them where the code had been scanned!
The more I think about the possibilities, the more excited I am about them, and I hope it makes you think seriously about whether you can incorporate QR codes into any of your workflows. As with most FME, it was absurdly quick and simple to prototype a solution. Of the four hours I spent most of that was setting up the workspace to read/write a database. I just couldn’t get the SQLExecutor to do what I wanted, so eventually switched to the FeatureWriter.
At the very least it’s a great example of how FME Server can integrate various other technologies and services together.
For the QR codes I used qrd°by. You should certainly look into what other services there are, and pick the most suitable. Or you could even write your own mobile app. But I can say in honesty that qrd°by was simple to use and their social media responsive to my queries. You should also note that GPS tracking needs their premium account, which isn’t free, but it’s not expensive either. It also has a 30-day trial which is more than enough to prototype an FME integration.
If you do implement anything with FME and QR codes, then please let me know or – even better – present it at an FME World Tour event!
And if you are new to FME, brought here by a search for QR codes, you can find out more about the product and download a trial copy from the Safe Software web site.