Comments (15)
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).
from ecs.
+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.
from ecs.
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.
from ecs.
i like it!
from ecs.
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]
?
from ecs.
What about location.geo.lat / .lon
? Longitude and latitude are geo information I would say. We definitively need to rename it. Suggestions welcome.
from ecs.
location.geo.lat
+1 for geo
from ecs.
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?
from ecs.
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.
from ecs.
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.
from ecs.
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.
from ecs.
+1 for geo.*
, for same reasons as @nickpeihl
from ecs.
from ecs.
I opened #58 based on the discussion about with geo.location
.
from ecs.
Closing as #58 was merged.
from ecs.
Related Issues (20)
- Typo in changelog for 8.8.0 HOT 1
- Tune container.image.* fields to follow OCI spec HOT 3
- log.offset not ECS compliant? HOT 16
- Multiple nested fields are missing from generated yml HOT 1
- Generator does not add "ignore_above" property for field type: flattened
- [Discuss] `ignore_above` on `flattened` fields
- [ci] Pipeline should fail if schema contains invalid field types
- field collisions with organization.id & elastic maintained integrations
- [RFC] Support id in threat.indicator for STIX 2.1 HOT 6
- Create equivalent of ecs-dotnet and ecs-typescript for java
- new field set: for log documents themselves
- Clarify the type of container disk and network metrics HOT 1
- ECS Vulnerability Published field
- Add threat.indicator.tags field
- [Proposal] Make event.kind a list HOT 3
- Incorrect generated/beats/fields.ecs.yml, not accounting on top_level: false HOT 1
- [ECS] Addition - http.request.header.bytes & http.response.header.bytes HOT 2
- Add lowercase normaliser to ECS fields which support security incident response process
- Mark experimental fields as `beta` in generated files
- Elastic-Agent Integrations Use of Legacy Mapping Types Impacts .fleet_globals & prevents agents from being upgraded
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ecs.