Spatial Types in the Entity Framework
This post has been removed.
Visit msdn.com/data/ef for the latest information on current and past releases of EF.
For Spatial Support in Code First see https://msdn.com/data/hh859721
For Spatial Support in the EF Designer see https://msdn.com/data/jj250903
Comments
Anonymous
May 04, 2011
Is this being designed with other DB providers in mind? Oracle for example has Spatial support as well and is now supporting EF. Will they be able to "plug-in" and provide Spatial support as well? Thanks.Anonymous
May 04, 2011
Our design will enable other DB providers to provide spatial support. If they do so, the EF spatial support will light up for them.Anonymous
May 04, 2011
I will absolutely be using these in both my existing HTML5 mapping apps as well as changing around existing work on an HTML5 book for Manning to support this shift. I like the canonical implementation of the OGC methods. This will keep us from having to add a bunch of additional references to the project. Regarding more specific types, everything helps coming out of the system but there will still be conversions anyway so just getting the calculations as functions is a great start!Anonymous
May 05, 2011
The main point is that your implementation should allow third party EF-providers for other databases to use arbitrary end .NET types for working with spatial types. Otherwise, classes like DbGeometry and DbGeography should not reside in SQL Server-specific assemblies and namespaces - they should be available in base .NET/ADO.NET or EF assemblies.