Spain provinces and autonomous communities #146
Conversation
💚 Build Succeeded |
|
@nickpeihl please take a look when you have some time and let me know what you think |
💚 Build Succeeded |
There was a problem hiding this comment.
The Wikidata ids in the provinces layer have been demoted to feature properties.id rather than the feature.id. We do have an open issue for adding wikidata ids to the properties. But I think that should be done all at once in a separate PR.
Is it possible the fixgeometries.py script caused the demotion? As I recall, QGIS does not respect the feature.id property in GeoJSON files.
Also, we need to update the versions property in sources/es/provinces.hjson to be something like 1 - 7 (see node-semver docs).
sources/es/provinces_v8.hjson
Outdated
| query: { | ||
| sparql: | ||
| ''' | ||
| #defaultView:MapRegions |
There was a problem hiding this comment.
perhaps fix the indentation here? not a big deal, but just looks nicer.
Co-Authored-By: Nick Peihl <nickpeihl@gmail.com>
💚 Build Succeeded |
💔 Build Failed |
|
@nickpeihl thanks for your comments 🙌 I've moved the id's to the feature level using the script below. Should I put it in the scripts folder? Also, should this check be included somehow in the test suite? I don't know exactly how we check geometries on the test process, but it would be great if we could ensure the ids are correctly placed. Script to move id's/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
* or more contributor license agreements. Licensed under the Elastic License;
* you may not use this file except in compliance with the Elastic License.
*/
const fs = require('fs');
try {
const filePath = process.argv[2];
if (!filePath) {
throw new Error(`Add the GeoJSON file path to process. e.g. node scripts/move-ids.js data/usa_states_v1.geo.json`);
}
const file = fs.readFileSync(filePath, 'utf8');
const geojson = JSON.parse(file);
if (geojson.features[0].id) {
throw new Error('File already has ID\'s at feature level, nothing to do');
}
// overwrite the features moving the ID field at the feature level
geojson.features = geojson.features.map(({ type, geometry, properties }) => {
const { id, ...propsWithoutId } = properties;
return { id, type, geometry, properties: propsWithoutId };
})
process.stdout.write(JSON.stringify(geojson))
} catch (error) {
console.log(error.message)
process.exit(1);
} |
💚 Build Succeeded |
I looked at our existing data and having a top-level So I am going to backtrack a bit here. Sorry, but now I do not think we need to require every feature have a top-level This PR lgtm! Let's merge this and consider the other questions separately. |
Shall we open a new issue to track this? This should be placed in the testing logic right? |
|
Yes, this is would be in the testing logic. I have created an issue to track this. Thanks. |
fixes #142
This PR splits Spanish provinces and autonomous communities (something similar to USA counties and states) into two separated layers.
As described in #142, a few wikidata entries had two different ISO codes, one for the province and another for the autonomous community.
To retrieve the data for the provinces, since relations in OSM were properly modeled (after adding a few Wikidata tags), the SPARQL query is quite different from the typical ones we've been using.