Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Geo: Support geo_point type #278

Closed
kimchy opened this issue Jul 28, 2010 · 6 comments
Closed

Geo: Support geo_point type #278

kimchy opened this issue Jul 28, 2010 · 6 comments

Comments

@kimchy
Copy link
Member

kimchy commented Jul 28, 2010

Mapper type called geo_point to support geo based points. The declaration looks as follows:

{
    "pin" : {
        "properties" : {
            "location" : {
                "type" : "geo_point"
            }
        }
    }
}

Input Structure

The above mapping defines a geo_point, which accepts different formats. The following formats are supported:

Lat Lon As Properties

{
    "pin" : {
        "location" : {
            "lat" : 40.12,
            "lon" : -71.34
        }
    }
}

Lat Lon As Array

{
    "pin" : {
        "location" : [40.12, -71.34]
    }
}

Lat Lon As String

{
    "pin" : {
        "location" : "41.12,-71.34"
    }
}

Geohash

{
    "pin" : {
        "location" : "drm3btev3e86"
    }
}

Index Fields

The geo_point type creates two floating point fields, called lat and lon. In our example above, two fields will be create, the first location.lat and the second is location.lon. Though probably not needed, there is an option also to create a third field called geohash with the geohash value (represented as location.geohash). In most cases, those specific fields are not needed when using geo capabilities, and only location will be needed (for example, with geo_distance filter).

Mapping Options

  • resolution: controls the floating point resolution of the stored fields. Defaults to 64, but can also be 32.
  • geohash: set to true to store also the geohash in the index. defaults to false.
  • geohash_precision: sets the geohash precision, defaults to 12.
@kimchy
Copy link
Member Author

kimchy commented Jul 28, 2010

Geo support: geo_point type and geo_distance filter, closed by 194e6cb, #279

@decitre
Copy link

decitre commented Jan 29, 2011

I have a GeoCouch feeding an es index through _changes.
Documents are compatible with geojson spec.
Is there a way to extend geo_point as a Lon Lat As Array ?

@kimchy
Copy link
Member Author

kimchy commented Jan 30, 2011

Can you post a sample format?

@decitre
Copy link

decitre commented Jan 30, 2011

In the following example, the geo coordinates are provided for both ES ("location" member) and GeoJSON ("coordinates" member):

{
  "_id": "p996602367",
  "_rev": "1-2b5e6ba6707a19c9bf0a00a9da67cda8",
  "type": "Feature",
  "geometry": {
      "type": "Point",
      "coordinates": [
          7.637420177459717,
          47.80836868286133
      ]
  },
  "children": {},
  "feature_code": 7312,
  "parents": {
      "1016": [
          "a20174512"
      ],
      "1022": [
          "l67331525"
      ]
  },
  "location": {
      "lat": 47.80836868286133,
      "lon": 7.637420177459717
  },
  "properties": {
      "attributes": {
          "11": {
              "value": "WERDERSTRASSE",
              "language": "GER"
          },
          "10": "77",
          "ON": {
              "value": "BUDGET",
              "language": "GER"
          },
          "BN": {
              "value": "BUDGET",
              "language": "GER"
          },
          "%C": "443",
          "TL": {
              "value": "+(49)-(7631)-foobar",
              "language": "GER"
          }
      }
  }
}

@kimchy
Copy link
Member Author

kimchy commented Jan 30, 2011

I have just mailed the mailing list to ask if its ok to make this change in ES (breaks backward comp.). If nobody objects too greatly, I can change everywhere to use the array format defined in GeoJSON (that includes queries and facets as well).

@decitre
Copy link

decitre commented Jan 31, 2011

That's very "agile" !

mindw pushed a commit to mindw/elasticsearch that referenced this issue Sep 5, 2022
)

Add prod OS users

jj, igor, fabien


Approved-by: fabien
costin pushed a commit that referenced this issue Dec 6, 2022
Adds support for pragmas (similar to compiler directives) in the _esql REST endpoint. This functionality, which is only available in developer snapshot builds, allows to influence plan generation and runtime (compute engine) properties for which we want to find good defaults. It allows us to benchmark different variants of the planner and selectively enable new capabilities as we see fit.
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Oct 2, 2023
elastic/rally-tracks#127 adds
`force-merge/refresh/wait-until-merges-finish` tasks for ad-hoc
investigations related to the cost of force-merge.

In this commit we explicitly skip the first two tasks to ensure nightlies keep
running the same tasks as they used to. Not running `wait-until-merges-finish`
was a bug and we want it executed on nightlies.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants