0

私は現在、次のようなオブジェクトを取得するNESTを介したelasticsearchクエリを持っています

    public class ElasticSearchObject
    {
        [PropertyName("code")]
        public string Code { get; set; }

        [PropertyName("geometria")]
        public MultiPolygonGeoShape Geometria { get; set; }
    }

現在、クエリは機能していますが、「Geometria」プロパティのタイプを変更する必要があります (これは、elasticseach に保存されたドキュメントの geo_shape フィールドにマップされます)。ここで、GeoJSON 文字列を保持する文字列にする必要があります。MultiPolygonGeoShape プロパティを後処理して、そのコンテンツから GeoJSON 文字列を作成することもできますが、もっと直接的な方法はありますか?

私が知る限り、geo_shape フィールドはすでに Elasticsearch JSON ドキュメントに GeoJSON 文字列として格納されているため、JSON ドキュメントから geo_shape を読み取り、MultiPolygonGeoShape にデシリアライズしてから GeoJSON に後処理するというリソースの浪費のように見えます。 GeoJSON が最初から存在していた場合。

4

1 に答える 1

1

私が知る限り、geo_shape フィールドはすでに Elasticsearch JSON ドキュメントに GeoJSON 文字列として格納されているため、JSON ドキュメントから geo_shape を読み取り、MultiPolygonGeoShape にデシリアライズしてから GeoJSON に後処理するというリソースの浪費のように見えます。 GeoJSON が最初から存在していた場合。

_sourceGeoJSON 文字列として格納されていません。"type"、"coordinates"などのプロパティを持つ GeoJSON オブジェクトです。

型に逆シリアル化することがリソースの無駄であるかどうかについては、データをどうしたいかによって異なります。GeoJSON に再びシリアライズするだけの場合は、デシリアライゼーション/シリアライゼーションのラウンドトリップを通過することがオーバーヘッドになる可能性があります。この場合、プロパティを介して NEST で公開されている低レベルのクライアントを使用して完全な応答をまたは配列client.LowLevelとして返し、関心のあるプロパティのみを逆シリアル化/解析することをお勧めします。stringbyte

于 2019-07-22T12:46:13.357 に答える