Is it possible to use Geography data type of SQL Server 2017 in ASP.NET application using .NET 4.8?

Question

I have not been able to configure to use database with Geography datatype in SQL Server 2017 in an ASP.NET application.

In my other question I have outlined various workarounds which do not work. Link: SO Question

Can anybody confirm successfully using Geography type in SQL Server 2017 in an ASP.NET application. If yes, what is the configuration?

For the only workaround is converting geography data to string, and then deserializing it on the client, which is a horrible way to do things...

Answer 1

I use an OData v4 API in a solution that allows farmers to map their farms and paddocks and they can place gates on those maps.

In your model, use System.Data.Entity.Spatial.DbGeography as the data type for your fields that you want to be Geography in SQL

In our solution the Paddocks are stored in DbGeography fields as POLYGON and MULTIPOLYGON , gates are stored in DbGeography fields as POINT . We can query for all the paddocks in a bounding box, calculate areas and distances... pretty much all Geospatial queries our clients can throw at us...

Notable Current Packages (However previous versions of the same packages have been running for the last year):

• Entity Framework 6.4.0
• Microsoft.AspNet.OData 7.3.0
• Microsoft.AspNet.WebApi 5.2.7
• Microsoft.Spatial 7.6.2
• Microsoft.SqlServer.Types 14.0.1016.290
• Newtonsoft.Json 12.0.1

If you need to interface with GeoJSON sources, either for imports or exports, I use these packages as well, but you should be able to write a contained application without them:

• GeoJSON.Net 1.1.72
• GeoJSON.Net.Contrib.EntityFramework 0.1.3
• GeoJSON.Net.Contrib.MsSqlSpatial 0.3.2
• GeoJSON.Net.Contrib.Wkb 0.1.3

The OData serializer has not caused any trouble with serializing or deserializing these types, a query for one of the perimeters returns this:

{
    "@odata.context": ".../$metadata#Paddocks(17518)/Perimeter",
    "Geography": {
        "CoordinateSystemId": 4326,
        "WellKnownText": "POLYGON ((145.27786016464236 -37.855119294600946, 145.27687250851116 -37.855329119608058, 145.276149480753 -37.855902375057504, 145.27588481613736 -37.856685463693672, 145.2761494445584 -37.857468560509645, 145.27687247231654 -37.85804183231879, 145.27786016464236 -37.858251665505662, 145.27884785696818 -37.85804183231879, 145.27957088472633 -37.857468560509659, 145.27983551314736 -37.856685463693672, 145.27957084853173 -37.855902375057504, 145.27884782077356 -37.855329119608058, 145.27786016464236 -37.855119294600946))"
    }
}

If you are having trouble using Geography data types in the client side, you'll find its just syntax, and as such can be overcome but you'll need to post more specific issues that you are experiencing, you may find more tooling and generic support if you use GeoJSON on the client side, mapping components like leaflet js use GeoJSON natively so if you are starting from scratch on a mapping solution you may find it easier to go straight for GeoJSON integration.

In my other question I have outlined various workarounds which do not work

As you didn't include any links back to your previous questions, I am not sure what your previous related issues are, but I hope this gives you the confidence to persist with your solution.

---

UPDATE

Instead of following the advice regarding SqlServerTypes.Utilities.LoadNativeAssemblies(Server.MapPath("~/bin"));

I manually copy the x86 version of the types dlls into the bin folder during deployment (because the server is running IIS 32-bit. Use the x64 versions if your server runs in 64-bit mode)

I also have added this binding redirect in web.config:

<assemblyBinding>
    <dependentAssembly>
        <assemblyIdentity name="Microsoft.SqlServer.Types" 
                          publicKeyToken="89845dcd8080cc91" culture="neutral" />
        <bindingRedirect oldVersion="10.0.0.0" newVersion="14.0.0.0" />
    </dependentAssembly>
</assemblyBinding>

There's nothing special in the connection string or anything else really.