Microsoft and Bing Maps - reference implementation
Showcase of capabilities of a Microsoft-based system architecture and Bing Maps API.
The Mapcortex UWP Free Edition is nothing more but a reference application on a proposed geospatial infrastructure and Bing Maps API based think client that is integrated to the Windows Store or any other Microsoft Application distribution (Intune) environment. This reference system and application was developed in 2015 targeting Windows 8.1 - since then the Azure cloud and identity/access management offerings have been vastly improved yet our core concepts of such application is still relevant and indeed still fully operational.
Our primary aim with this system was to reveal that whilst rolling out your own GIS system might be rather daunting and complex work but with Windows UWP SDK and Bing Maps API you can reasonable easily create a customized thick client using nothing more than C# and Xaml. But why would you want to do such work when you can get a very robust and world class GIS desktop system such as QGIS free of charge?
Mapcortex UWP Free Edition does not try to compete with any of the commercial or open-source GIS desktop systems - its functionality are not even basic in contrast of these well-known desktop brands. But what Mapcortex UWP Free Edition does out of box is a full integration with Microsoft Identity and Access Management with Microsoft Graph as well as enjoying all benefits what Microsoft Store was able to provide in 2015.
Business case and business considerations
Unless your business is related to land and spatial information management, defense or any other industry where spatial alignment of assets are required to a low sub-meter accuracy then you are probably reasonable happy to use WGS84/EPSG4326 coordinate system - which is used as deafult by many major web mapping providers (Bing/Google/etc).
It is also very likely that your business is already using several relational database systems to store your data - whether this to be Microsoft SQL Server, Oracle, Postgres, MySQL - on prem or cloud. These database systems are fully capable to deliver very complex spatial calculations, able to create and maintain spatial indexes and essentially provide core geospatial capabilities. Moreover, the latest releases of many NoSQL databases also capable of geospatial indexing and management of such data.
In short - if your IT infrastructure is based upon the usual Microsoft offerings (MS SQL Server/Azure AD/Active Directory and/or Office 365) and you have access to a few, seasoned C#/T-SQL developers - then your organization is already geospatially enabled on a fundamental level. All you need now is a simple Bing Maps API license (which is often free of charge for many use) and a solid set of business requirements.
Technical architecture and presentation
As with every system, the Mapcortex Microsoft Stack also has several sub-components. High majority of these already exists in your organization - so all you need to do is to set it up and organize it well. When an organization has a clear line of sight of its own data assets, data management procedures and concrete goals what they need to achieve in terms of its geospatial offerings then the solution is actually way more simple than it is often believed. So let's start to dissect this architecture - starting at the core of the system - the database.
Database server with geospatial capabilities
As we have mentioned previously since any major database server possess the capabilities of complex geospatial indexing and calculations with the right skillset and understanding of your organization data it is reasonable easy to create the SQL routines/functions and manage the spatial indexing thus being able to acquire the necessary geospatial information out from your database.
When an organization utilize an enterprise-grade geospatial server or just a desktop client connecting to a remote database server - the first shortcoming they notice is that the geospatial processing script execution is rather slow. This often happens because the commercial GIS application runs a plethora of validation routine internally and that can be a detrimental factor on processing speed. It is a normal practice in the geospatial industry that if you need to run a script processing significant amount of data - its better to do with direct database routines utilizing PostGIS or any other similar functions. This means - if your DBA's know exactly how to write/store/manage database functions in both higher and lower environments - then your organization is in full control over its own geospatial data.
Relation database engines used to be able to create web services directly out from their engine. These features are not present in newer versions anymore due to increased security hardening of the server products. In short - despite your organization can create the necessary routines on the database level - you still need to somehow direct the resultsets from spatial DB queries to the client side applications.
Geospatial web-service
If you are willing to invest into a fully-fledged geospatial server - either commercial or open-source - then you will have a first-class system in place that has GIS-standards compliant service capabilities as well as a most likely a very complex - and often opinionated - enterprise integration pattern that requires specialized skills to operate - which your classic IT organization might not have. These geographic information server products are normally very good what they are designed for - but they can indeed be an overkill for many small and medium sized organizations. They can also be very slow due to their complexity - which is normally balanced out with huge server requirements thus adding to their already expensive price tags.
With our current reference architecture you have 3 other options to provide data to your application from your database:
1. Utilize Bing Spatial Data Service
Bing Spatial Data service is simple enough to be user friendly ad useful even for free tier users as well as to be rather resource rich for enterprise customers. With the underlying API system you can programmatically manage what to add/remove from your either private or public data service and you can also control access to these services with Bing maps API credentials.
The significant advantage of this system is that your organization desn't need to worry about the management of the infrastructure - you just create the web service either manually or via the API and manage the data that comes and goes. The free tier service is heavily restricted on how many spatial features can a service has - these limitations have been significantly extended for enterprise account holders, which makes the whole spatial data service enterprise-ready.
There are obvious shortcomings of using this system - and these are mainly related to data storage and feature limits. When you load your data in to a Spatial Service - well you just cannot know which country it will actually be stored. The number of features limitations can be lifted by subscribing from free tier to enterprise account and the rest in general can be managed by appropriate data management practice. The other disadvantage is perhaps more related to mix-up of marketing of technologies and provisions - there is another way of utilizing similar spatial data routines using Azure Maps - but in that environment the pricing regime is different and some features are not yet implemented - whilst some new ones are there.
2. Your own REST-based spatial service
There are endless number of ways how to create, manage and deploy a REST service. You can pick any programming framework, any OS, container, managed systems or even serverless infrastructure. There is no real difference between a spatial and non-spatial REST service in terms of implementations - perhaps the output and input should be compiled into a geospatial standard (like GeoJSON/KML/etc). There are a number of programming libraries that can do this for you.
How you authenticate and authorize the service users - this is up to you really. Cloud providers do have a wide range of IAM systems in place that you can integrate and they follow up all the required industry and security standards.
So what is the disadvantage of using your own REST service? Well you have to write it, manage it, deploy it and maintain it. This can either be a significant task to your organization or just a bit more ellaborate BAU activity - it really depends on your current IT team's capabilities.
The other main risk using REST is security. Whilst it is ensured that transport layer encryption is in place - it is only an encrypted channel where your data is coming and going - it is as secure as the network provider wants it to be.
3. SOAP-based geospatial web service
Contrary what the current IT trend is promoting, developing an ASMX-based SOAP service and integrating it with one or two .NET-based desktop applications is actually not a very complex task. As long as the development/product manager team is able to contain the SOAP service within its fundamental design principles and changes to the service is conducted in a more robust/planned manner there should not be significant issues using SOAP.
The other advantage here is security. Your organization can include WS-security features in this service - in such case your communication is truly encrypted rather relying on transport-level security. This however can add a significant increase to the complexity of the service.
Lastly - if your organization IT team are normally confident to use one programming language such as C# and they know how to develop WPF/WinForm desktop applications - then developing a SOAP based ASMX service can make sure that your team does not get bogged down on various web-standards and HTTP-protocol/HTTP-headers related issues - they write the service in C# and consume it in C# and the nitty-gritty configurations are pretty much sufficient on the default/out-of-box settings that comes with Visual Studio.
The major disadvantage of SOAP is that it is XML-based - so you will need to send over way more data then with REST/JSON. Also - if the service is changed then the object-oriented mapping of service descriptor needs to be re-mapped in the client application and it is often needs to be completely re-built - and if this application is distributed via Windows Store/Intune then you will have a rather ellaborate release life-cycle. In short - SOAP services are nowhere near as agile in terms of usage then REST - but let's never forget that many good system were developed with Waterfall techniques in the past.
Our technology stack
