I guess it has to do with their support/maintenance guarantees, release cycles and standards compliance. If this page is correct, then Microsoft is following the standards that are specified by OGC and ISO: https://postgis.net/docs/using_postgis_dbmanagement.html However, PostGIS as well as Oracle are adding their own extensions which has yet to be included in the above standards, including 3D and SRID support. If you build a solution to work only for one type of SQL accent, there will always be issue to move to another DBMS, this has been true for most of my career, moving systems from Oracle to SQL Server, always small differences in SQL and stored procedures. Ex: SDO_GEOM.SDO_DISTANCE (Oracle) <-> geography.STDistance (SQL Server) PostGIS and Oracle are going in different directions with their extensions, and a lock-in is guaranteed if you choose either solution. Microsoft is not extending the Spatial features much for the 2016/2017 releases: https://blogs.msdn.microsoft.com/psssql/2016/03/03/sql-2016-it-just-runs-faster-native-spatial-implementations/ I agree that Microsoft could be pushing more extension features into their product at a faster pace, but only as per industry standards or as Open Source extensions. If they would add more and more proprietary custom extensions then they risk falling into same trap as in the early days of IE/Netscape, where the two browsers didn't follow same HTML standards and deviated from each other, which still today are causing many enterprises headache as the standards have evolved since they built their huge enterprise app. When a company invest, they expects the standards to be there 10 years later and their system to run without a need to upgrade. Microsoft support their SQL Server products for minimum 10 years, PostgreSQL support their product 5 years. PostGIS is not covered by any minimum and it relies on 3rd party companies to support from the Open Source community. It's my experience that most enterprises buying these kind of systems have to consider long term support in the bid. For most of my customers the Spatial storage is just a small part of the reason why they use SQL Server. They like the integration of Spatial with ETL, BI, R Analytics, Reporting, Mobile and Cluster/HA which are all features that are included in SQL Server. It's easier for us to integrate and support one vendor solution than a mix of technologies and vendors, which is very important. SQL Server certainly have limitations as you have noticed, SRID is a bit more headache as we have to process outside with FME, OGR, Manifold or ESRI. New spatial data sources like 3D CAD, Lidar and BIM is coming more and more and I don't expect that SQL Server will be able to keep up in a reliable way, flexible integration with other systems will be more important. Manifold and now Radian are great tools to avoid this headache and have a powerful ETL/GIS service layer in between the databases and the customer applications, they are certainly more economical choices than ESRI and FME for the same job.
|