我使用EF與MSSQL數據庫,我有空間查詢掙扎的距離計算的: 我使用用戶位置搜索通過這裏距離排序的餐館是代碼:失算dbgeography
DbGeography userLocation = DbGeography.FromText(userLocationWKT, 4326);
return (from branch in DbContext.Branches
let distance = userLocation.Distance(branch.Location)
orderby distance ascending
where branch.Name.ToLower().Contains(searchString.ToLower()) && branch.Location != null
select new BranchAndDistance { Branch = branch, Distance = distance }).ToList();
用戶位置WKT是POINT (32.78786115814 35.0162102747709)
。在我的測試案例中,我發送一個查詢,返回一個餐廳Lat=32.1300848 & Long=34.7919443
但我得到的距離是370237米,這是離開。
下圖顯示了餐廳位置的詳細信息快速監視窗口: 注意的是,在ProviderValue文本它顯示
POINT (34.7919443 32.1300848)
,如果它取代了緯度和長,但實際值似乎OK 所以我進行了一些測試, ,因爲我在不同的變量保持lat和長值我可以測試以下內容:
double? distance = Branch.Location.Distance(userLocation);
DbGeography branchLocation = DbGeography.FromText(string.Format("POINT ({0} {1})",
Branch.Latitude,.Branch.Longitude), 4326);
double? distance2 = branchLocation.Distance(userLocation);
的distance
變量具有370237.85926851362 同樣不正確的距離值,但distance2
variabel過的C正確的距離值65061.945208184392 這怎麼可能? 我還檢查在SQL Azure數據庫同治,並根據該Location
特性(它產生不正確的距離結果)是
我錯過了什麼地方?我究竟做錯了什麼???
所以你說的話是,我得到了cooridinates混合,然後將第一個值實際上是在經度,而另外一個是北緯?其實我讀過WKT可能錯過了一些東西。 –
是的。嘗試切換它們,看看結果是否更像你期望的結果。 –