TO BE OR NOT TO BE SPATIAL ; it’s a MUST HAVE
If you make a spatial query today using entity framework 6.1 , it ALWAYS makes a full table-scan , which takes forever for large tables. IT DOESN’T MAKE USE OF THE SPATIAL INDEX especially defined for that spatial column.
Well, T-SQL DOES USE a spatial index , like this:
SELECT TOP 1 *
FROM myTable WITH(index([SpatialIndex-mySpatialIndex_1]))
WHERE ogr_geom2.STIntersects(@Point) = 1
ORDER BY ogr_geom2.STDistance(@Point) ASC
But today , entityFramework 6.1 is not able to make use of the same , SUPER_FAST spatial index. It only does something like this:
System.Linq.IQueryable<SharpMapForm.soluri> d33 = null;
d33 = db.soluris.Where(x => x.ogr_geom2.Intersects(dbM) && x.ogr_geom2.InteriorRingCount >= 1);
And it does it painfuly slow, unbearably slow, so you HAVE TO write a t-sql userStoredProcedure , like the one above, update the model from the database, by importing the storedProcedure, then edit the model-function-imports ... Just think how beneficial for you and me, would be, for entityframework to be able to directly make use of spatial-indexes.
SO, THIS IS AN EMERGENCY.
this isn’t some kind of joke , it isn’t even an option ...
Closing this as it is specific to EF6 and we are now only tracking EF Core ideas here. Please create an issue at http://github.com/aspnet/entityframework6/issues/new, but keep in mind that moving forward, our team will only fix bugs, implement small improvements and accept community contributions in the EF6 codebase.
EF' support for spatial was actually designed to translate LINQ queries containing spatial operations to SQL with spatial operations. If this isn't working for you please file bug in our CodePlex.com site including the code necessary to reproduce the issue.