Rename geoip to location

[ruflin]

The current geoip fields (https://github.com/elastic/ecs#geoip) are inspired by the geoip ingest processor form Elasticsearch (https://www.elastic.co/guide/en/elasticsearch/plugins/6.2/using-ingest-geoip.html). In recent discussion around geo fields it became clear not all geo information is coming necessarly from an ip address and there is also geo / location information which does not necessarly can be extracted from an ip.

I would like to suggest to rename geoip fields to location. I was also thinking of renaming it to geo but I think location is more specific.

[jordansissel]

+1 to renaming geoip to location. This would allow folks to place any where-style data in this set, such as: region, cloud platform, datacenter, rack, building number, address, zip code, etc.

Not all where have "geo" or "ip" concepts, so I think location matches much more nicely.

[ave19]

i like it!

[ave19]

Wait a minute... how bad is it that the name location is also mentioned by the geo point type? It seems that the name location is not required by geo point, but it's in the docs that way. Would we end up with source.location.location[.lat,.lon]?

[ruflin]

What about location.geo.lat / .lon? Longitude and latitude are geo information I would say. We definitively need to rename it. Suggestions welcome.

[jordansissel]

location.geo.lat

+1 for geo

[ruflin]

An other interesting twist I just found out is that in Elasticsearch the geo information can be either passed as lat and lon in two fields, as a string or as an array: https://www.elastic.co/guide/en/elasticsearch/reference/current/geo-point.html

Not sure how we should deal with it but we could have also geo.hash for the geohash, geo.point for the point array. geohas could also be used for the string option.

[willemdh]

Personally I'm a fan of short fieldnames. Longer fieldnames tend to mess up datatables etc. So my preference goes to geo above location.

About https://www.elastic.co/guide/en/elasticsearch/reference/current/geo-point.html

I'm not a gis expert, but the mapping in the example says:

PUT my_index
{
  "mappings": {
    "_doc": {
      "properties": {
        "location": {
          "type": "geo_point"
        }
      }
    }
  }
}

So couldn't we just do something like:

"geo": {
  "properties": {
    "city_name": {
      "ignore_above": 1024,
      "type": "keyword"
    },
    "continent_name": {
      "ignore_above": 1024,
      "type": "keyword"
    },
    "country_iso_code": {
      "ignore_above": 1024,
      "type": "keyword"
    },
    "location": {
      "type": "geo_point"
    },
    "region_name": {
      "ignore_above": 1024,
      "type": "keyword"
    }
  }
}

which could cover all 5 geo point expressions?

[ruflin]

So you are basically proposing geo.location instead of location.geo.

Good point about the location field that we can just set it to geo_point and have ES worry about what it will contain.

[willemdh]

So you are basically proposing geo.location instead of location.geo

Something like that yes. Another possibility could be:

"geo": {
  "properties": {
    "city_name": {
      "ignore_above": 1024,
      "type": "keyword"
    },
    "continent_name": {
      "ignore_above": 1024,
      "type": "keyword"
    },
    "country_iso_code": {
      "ignore_above": 1024,
      "type": "keyword"
    },
    "point": {
      "type": "geo_point"
    },
    "region_name": {
      "ignore_above": 1024,
      "type": "keyword"
    }
  }
}

@ruflin These are all very high level discussions with multiple possible solutions. There should be a vote of some kind with an uneven number of people for decisions which could have a breaking impact. I'm quite sure I'm not seeing all possible implications of choosing location vs geo as root object. I just have a personal feeling towards keeping field names asap (as short as possible ;) ).

Someone with real GIS experience should jump in on this one and share his (or her) opinion.

[ruflin]

I think more important then keeping file names short is to keep them descriptive and self explanatory. Shortening names can still be a UI feature for example.

Good idea about pinging people with more GIS experience. I just did that internally.

[nickpeihl]

My preference is geo and geo.location. "Geo" is a common designation in the GIS industry (Geospatial, GeoJSON, Geographic Information Systems). And, imo, it's a better specifier as a top level element than location since "location" may also be used in non-spatial contexts (URLs, files on disk).

[thomasneirynck]

+1 for geo.*, for same reasons as @nickpeihl

[ave19]

+1 for geo, good argument

On Fri, Jul 27, 2018, 9:28 AM Thomas Neirynck ***@***.***> wrote: +1 for geo.*, same reasons as @nickpeihl <https://github.com/nickpeihl> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#50 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AICmGg2yQq2XjHqGxnzT7bITKKpduiuvks5uKzGRgaJpZM4VSgIl> .

--

…

-ave

[ruflin]

I opened #58 based on the discussion about with geo.location.

[ruflin]

Closing as #58 was merged.