Linq query with a NetTopologySuite.Geometries.Geometry parameter always fail

[Kerdanite]

We want from our application do spatial query from an in memory Geometry. For example, find each Entity in Distance of that Geometry received. But each time doing so we get an exception because the geometry parameter is not parse as binary. We use both MS Sql and PosGis.

I've wrote a Test in the ConformanceItemFixture to represent that :

        [Test]
        public virtual void TestWithAnExternalGeometryParameter()
        {
            Geometry geometry = Wkt.Read("POLYGON( ( 67 13, 67 18, 59 18, 59 13, 67 13) )");
            var buffer = geometry.Buffer(10);

            var query2 = session.Query<NamedPlace>()
                .Where(w => w.Boundary.Within(buffer))
                .ToList();

            Assert.IsTrue(query2.Any());
            Assert.IsTrue(query2.Count == 1);
        }

[peetw]

Sorry for the delay in replying! This is a common problem (see #61 and #103 for example). In your case, I would suggest using QueryOver with WhereSpatialRestrictionOn instead. Your example would then be:

    [Test]
    public void TestWithAnExternalGeometryParameter()
    {
        Geometry geometry = Wkt.Read("POLYGON( ( 67 13, 67 18, 59 18, 59 13, 67 13) )");
        var buffer = geometry.Buffer(10);

        var query2 = session.QueryOver<NamedPlace>()
            .WhereSpatialRestrictionOn(x => x.Boundary)
            .CoveredBy(buffer)
            .List();

        Assert.IsTrue(query2.Any());
        Assert.IsTrue(query2.Count == 1);
    }

[Kerdanite]

The problem is when using Linq the Geometry parameter is not correctly parsed and sent to the database. Why it's not possible to fix that ?

We'd really prefer to use only Linq in our solution and avoid QueryOver

[peetw]

It's on the list, but I don't currently have time to look into it in greater detail, especially since the current workaround works fine. Any pull requests are gladly welcomed though 😃

PS Sometimes the use of QueryOver is unavoidable, even in "vanilla" NHibernate, since the LINQ implementation for NH is not 100% complete.