You are currently reviewing an older revision of this page.
What is AWLRS?
AWLRS stands for AssetWise Linear Referencing Services. AWLRS is one of the core components underpinning the Assetwise platform and is a spatially enabled, network and asset editing application primarily focusing on Transportation and Linear Referenced networks.
So what happened to Spatial Manager?
Spatial Manager was based on legacy software and built around a single GIS vendor (ESRI). We wanted to move our users to modern technologies and at the same time to a more ‘open’ environment.
What do you mean by ‘modern’ technologies?
Mainly the web and the ‘Cloud’! Ok, so web applications may not be exactly ‘new’, but having the ability to have a single deployment either on your own or a hosted server, is -we would argue- a hundred times better than trying to install a desktop application on each individual PC or use virtualization software to access it.
And an ‘open environment’?
Well, ‘openness’ has to do with a number of things. It’s about the data formats we use. The map now displays the layers through WMS, WFS and WMTS. All of them OGC standards (and the hyperlinks are there to find more information if you want to). And it’s also about the underlying technology we use. Which, a big chunk of it, is based on open source components. We use Mapserver as the map rendering engine, and Openlayers for the UI map interactions.
Why should I care about your fancy acronyms? And whether a component is open source or not?
You should care because no matter which is your enterprise GIS, it can consume the data because it is based on open standards. You care, because you no longer have to create specific setups or users in your database just to get the software to work. And you care because your system will be fully interoperable since by definition, open source software does (and has to) rely on open standards.
I get it. It’s open and based on standards. But how difficult will it be to use?
Let us just say this: It’s a web application. And we feel that for web apps, if you have to read the manual, then we have failed. Undoubtedly, managing linear networks, linear referencing systems and assets, does involve some complex workflows so, yes we will provide a manual! But the concept is that your ‘work environment’ should look and feel very similar to the web maps you use in your everyday life, like Google or Bing Maps. And seasoned SM users should have no trouble getting accustomed to the new interface.
Some examples for this ‘ease of use’ you are referring to?
We designed AWLRS with ease of use in mind and a ‘clean’, uncluttered interface.
So for example, when you log in to AWLRS you see a very limited number of buttons. Most of them have to do with navigating the map and are pretty self-explanatory. Here’s what it looks like:
So where are all the editing tools?
Hidden! And they appear only when you need them to. For example, when you are in edit mode, you click on the feature you want to edit (a datum, a route, a node or an asset) and its then that the edit tools will display. And only the ones that make sense in that particular instance.
So if you click on a datum, this context-sensitive menu appears:
But if you click on a datum AND a node, an extra option (split at node) will be added to the menu:
When you click on a node on the other hand, this menu appears:
So you are saying that I can I do everything I was doing in the old SM in AWLRS as well?
Yes, all SM-specific functionality will be carried into the new product. However, workflows that you may expect from a desktop GIS, like advanced printing or spatial analysis tools, may have to change or carried out using different tools. Remember, your data is now open and interoperable by any application you chose.
Must be a catch somewhere… Looks easy but it’s also completely different. Will there be some sort of data migration? And will I lose all the customizations I did over the years?
Absolutely not. The back-end technology remains the same. Same, but enhanced. So any custom triggers, reports, integration with other systems will still work as they used to. All the changes have been made from the application server level and ‘upwards’.
Ok, but surely there will be some downtime when we switch to the new system?
No downtime whatsoever. In fact, you could run SM and AWLRS side by side which you may find helpful while you are getting acquainted with AWLRS (but we will ask you to de-commission SM eventually when it will no longer be supported)
Ok, so let’s be a bit technical now. What is the technology stack we need to have for AWLRS? I am sure my IT department would like to know.
And so they should. The components are listed below:
Maybe a diagram would also help with the architecture? And how SM and AWLRS compare?
Here’s a high level one showing both architectures:
Notice on the client side, that in SM, each SM user had to have its own copy of Arcmap. This is no longer the case in AWLRS as any user with a browser (and the right credentials) will be able to access the data. Which also means that any changes, updates, bug fixes and enhancements once rolled out, will automatically be available to all users.
Another thing to notice is that on the database server, there is no need any more for the Oracle SDE schema, or the ArcSDE binaries on the application server.
No ArcSDE?
None whatsoever. Not on the application server and not on the database. There are no dependencies on ESRI technology. This doesn’t mean that we will ask you to uninstall it (see also previous answer about downtime). We are just saying that we will not be using it.