is this inconvenience , just for me ? Am i alone in this?
Posted: Mon 25 Sep 2017 06:12
Hi,
Thanks for your product, with its incredible value for developers.
Devart's product is THE ONLY ONE standing up to Microsoft as far as providing spatial capabilities to EntityFramework, and is leaving MS in the dust when things are coming to synchronization.
I'v hit a nasty inconvenience: when using
and having a postgresql table with a geography column , with srid=4326 (wgs84), the Devart DbGeography column returned from an spatial EntityFramework query , has the Length property returning degrees , not meters.
I can get around this , by getting the st_length from a native postgis query , but it's cumbersome and it's slowing down things: it's NOT EntityFramework...
Why do i say this? because the Length of a MicrosoftSqlServer wgs84 DbGeography column, returns meters not degrees like NetTopologySuite does. Well, i guess i'm asking too much , i knew it , but it's worth a try ...
Thanks for your product, with its incredible value for developers.
Devart's product is THE ONLY ONE standing up to Microsoft as far as providing spatial capabilities to EntityFramework, and is leaving MS in the dust when things are coming to synchronization.
I'v hit a nasty inconvenience: when using
Code: Select all
PgSqlEntityProviderConfig.SpatialOptions.SpatialServiceType = SpatialServiceType.NetTopologySuite;
I can get around this , by getting the st_length from a native postgis query , but it's cumbersome and it's slowing down things: it's NOT EntityFramework...
Why do i say this? because the Length of a MicrosoftSqlServer wgs84 DbGeography column, returns meters not degrees like NetTopologySuite does. Well, i guess i'm asking too much , i knew it , but it's worth a try ...