Java GeoToolsは、WGS84入力と "EPSG：3857"の形状の範囲内のフィーチャを検索します

Question

"EPSG：3857"に再投影されたシェイプファイルがあります。私は緯度/経度（WGS84）で取得するポイント。

dwithinを使用すると、実際の距離よりも高い範囲を渡す必要があります。そのため、「EPSG：3857」とdwithinの問題が原因でこの問題が発生するため、バッファリングされたジオメトリに切り替わり、ポイント。これは私のコードです：

CoordinateReferenceSystem WGS84 = CRS.decode("EPSG:4326",true); //org.geotools.referencing.crs.DefaultGeographicCRS.WGS84 Google Earth; 
CoordinateReferenceSystem EPSG3857 = CRS.decode("EPSG:3857",true); //WGS84 Pseudo-Mercator: shape reprojected CRS------------- String code = "AUTO:42001," + x + "," + y; 
MathTransform transformToEPSG3857 = CRS.findMathTransform(WGS84, EPSG3857, false); 

GeometryFactory geometryFactory2 = new GeometryFactory(); 
Geometry pointSource = geometryFactory.createPoint(coordinateSource); // coordinateSource is lat=41.942667 lon=12.462218 
Geometry targetGeometry = JTS.transform(pointSource, transformToEPSG3857); 

Geometry buffer = targetGeometry.buffer(distance); 
buffer.setSRID(3857); 
Filter pointInPolygon = filterFactory.contains(filterFactory.property("the_geom"), filterFactory.literal(buffer)); 
SimpleFeatureCollection features = shapeFileNamedCache.getFeatureSource().getFeatures(pointInPolygon); 
System.out.println("Features: " + features.size() + " at distance in meters: " + distance); 

なぜこのコードは、私はそこに知っている間に、任意の機能をフィルタリングしない理由が得られていません。

アドバイスは私に役立ちます。

ステファノ。私は170を通過するが、特性が近いメートルで

POLYGON ((1387457.7619147683 5152395.103885399, 1387454.4954124368 5152361.9385306565, 1387444.8214352953 5152330.047701897, 1387429.1117488598 5152300.6569457855, 1387407.97006757 5152274.895732597, 1387382.2088543817 5152253.754051308, 1387352.8180982703 5152238.044364872, 1387320.927269511 5152228.37038773, 1387287.7619147683 5152225.103885399, 1387254.5965600256 5152228.37038773, 1387222.7057312662 5152238.044364872, 1387193.3149751548 5152253.754051308, 1387167.5537619665 5152274.895732597, 1387146.4120806768 5152300.6569457855, 1387130.7023942412 5152330.047701897, 1387121.0284170997 5152361.9385306565, 1387117.7619147683 5152395.103885399, 1387121.0284170997 5152428.269240142, 1387130.7023942412 5152460.160068901, 1387146.4120806768 5152489.550825013, 1387167.5537619665 5152515.312038201, 1387193.3149751548 5152536.45371949, 1387222.7057312662 5152552.163405926, 1387254.5965600256 5152561.837383068, 1387287.7619147683 5152565.103885399, 1387320.927269511 5152561.837383068, 1387352.8180982703 5152552.163405926, 1387382.2088543817 5152536.45371949, 1387407.97006757 5152515.312038201, 1387429.1117488598 5152489.550825013, 1387444.8214352953 5152460.160068901, 1387454.4954124368 5152428.269240142, 1387457.7619147683 5152395.103885399)) 

：

バッファはこれを含んでいます。シェイプファイルは、QGIS経由でWGS84疑似メルケータに再投影されます。奇妙なのは、CRSがED_1950_UTM_Zone_33Nであるオリジナルファイルを使用すると、距離が正確で機能が予想通り近くにあることです（167ではなく123mで検出されます）。

Answer 1

同じ形状ファイルに移動しかし結果が異なるためCRSの

sourceCRS = CRS.decode("EPSG:23033", true); 

として使用して、再投影されないの後、物事がchaged。距離今

を計算する際に完全な地図上の点の位置を50メートル差：前

点の位置との距離が約3メートルの誤差で全てです。

なぜこれが起こっているのかはまだわかりませんが、少なくともエラーは減少しています。

注：テストを行うには、Google EarthをGIS経由の輸出用のKLMファイルで使用しています。