Closed skscharr closed 6 months ago
thanks @skscharr for reporting. There's indeed a geometry that Elasticearch is not accepting, even locally the tools we usually work with (mapshaper
, QGIS) do not complain about it.
Pretty sure the problem is on this vertex where the geometry contacts with a previous vertex:
The main use for EMS File Service is to serve as data layer in Kibana Maps. For that this is not an issue since the geospatial data from this repo is processed on the browser and never ingested in Elasticsearch.
To check this is not a problem you can do the following steps:
# Create the index
PUT ems_error_300
{
"mappings": {
"properties": {
"id": { "type": "keyword"},
"value": { "type": "integer"}
}
}
}
# Insert a document
POST ems_error_300/_doc
{
"id": "85713",
"value": 1
}
# Create the data view
POST kbn:/api/data_views/data_view
{
"data_view": {
"title": "ems_error_300"
}
}
ems_error_300
data view.Still, it is not OK to have a geometry that Elasticsearch does not correctly digest, so I'll see if we can patch that single geometry to behave and look for updating this dataset since there's a newer version from 2020.
cc. @nickpeihl
@skscharr you may want to give this alternate version a try, from the fix in progress at #302
New release of the data has been published to production and https://maps.elastic.co/#file/usa_zip_codes even rendering the same dataset (in TopoJSON format), it points in the GeoJSON
button to the new dataset with the fixed geometry available here and at EMS File Service bucket.
Thank you @jsanz !
85713