Click to read:

If you have read Part 1 of this, you might have wondered why it had such a rather abrupt end and did not show the end result in an actual map. I wasn't deliberately building in a cliff-hanger, but was having some issues with displaying the map. Read on to find out how this was solved. 

AzureMapsControl

To display the (indoor) map on screen I wanted to use Blazor. For this goal exactly, the excellent AzureMapsControl has been built by Arnoud Leclerc (https://github.com/arnaudleclerc/AzureMapsControl.Components). The component has recently been extended to support Indoor maps but, after following the instructions, I was not able to have a map show up on the screen. After cloning the repository, a fair amount of debugging and sniffing the network traffic, I found that the component did not yet take the geography where the Azure Maps Creator resources are located into account. All requests for my map where going to the US while I had been building my Datasets, etc. in the Europe region.
Once I found out what the problem was, I created a Pull Request to fix this shortcoming and now there is a version avilable where you can specify the region for the Indoor API calls. I extended the app I created in part 1 with a Map 'menu' entry and once you have gone through the necessary steps, clickin on that menu should give you a map as shown below. One caveat is that the level selector only shows up once you have clicked anywhere on the map.

Query extra's

I also dove a bit deeper into the data that the WFS API's can return. The app has been extended to query for all collections in your map and even offers the option to drill into the details of each collection. I defaulted to showing just the id and the name but a lot more is available. You can easily adapt the source to show what you want/need. I generated the needed classes by copying the JSON responses and the use the 'Edit'->'Paste Special'->'Paste JSON as classes' functionality in Visual Studio. This way, almost all the work is done for you! Only thing I changed was that instead of classes I want to have records (and init properties instead of set properties) and changed a couple of the generated names.

Feature stateset extra's

Now that I had found a way to retrieve more infrmation through the WFS API, I thought it would make sense to also try to change the way the app was handeling the feature stateset. Instead of statically changing the occupancy of one room, I now have information to work with all available rooms (the sample map used does not contain information on all the units/rooms in the map). So, for visualizing this on the Feauture page I came up with this:

You can change the status of the units (rooms) retrieved and then send it to the API with the button on the bottom. If you take a look at the map after doing this you get this:

Not bad if I say so myself! As always, the code is available in the GitHub repository.

p.s. You might notice that the screenshots are no longe showing the region and subsccription key. I changed the code so that these are now read from the Configuration (appsettings, secrets, etc.)

p.p.s I've updated the README in the repository and added steps to explain how you could run this from you own machine.

 

Hope this helps!

 

Comments


Comments are closed