A proposal to add geographic specifications in TableSchema

[datagistips]

Hello

🌐 On OpenData portals, we observe a significative proportion of spatial data.

TableSchema tends to become the standard of standards. I personally like it a lot 👍

It is used on the French schema.data.gouv.fr

🙁 But TableSchema misses some specifications for spatial data that could really be useful

That's why I made a proposal of geo enhancement in both TableSchema (spatial-schema) and the validator :
➡ https://github.com/datagistips/geo4TableSchema/

Here's how geodata, for me, could be specified

{
  "name": "_geom",
  "title": "Polygon geometry",
  "description": "Polygon geometry",
  "type": "wkt",
  "geomtype": "polygon",
  "crs": "EPSG:4326",
  "horizontalAccuracy": 5,
  "constraints": {
    "required": true,
    "unique": true,
    "overlaps": false,
    "minArea": 100000000,
    "bounds": [4.9283, 43.0756, 7.6412, 45.0923]
  }
}

Also, on the repo, you'll see a prototype that controls these specifications with geopandas under the hood

❓ Is it planned to improve spatial aspect and add spatial tags in TableSchema ? Is this proposal relevant to you ?

---

Related issues :

• Geo "profile" for Data Package #86
• Develop Geo data specification protocol #545
• Spatial Data Package specification proposal #499

[roll]

Hi @datagistips,

Sorry, this issue somehow hadn't been answered =(

It's very interesting I think it will be great to start from a pattern - https://datapackage.org/standard/patterns/

[mradamcox]

That link doesn't seem to work anymore, is there an update place to learn about patterns?

[mradamcox]

I'm thinking this is the analogous page now: https://specs.frictionlessdata.io/patterns

[roll]

Thanks! And for v2 - https://datapackage.org/recipes/caching-of-resources/

[mradamcox]

Just to add to the discussion, I'm also interested in this, as we have been using Data Resource with shapefiles. In our use case we are creating a Data Package for distribution that has many CSVs as Tabular Data Resources, and each CSV has a foreign key to a spatial Data Resource, an example of which follows:

{
    "name": "counties-2010",
    "title": "County Boundaries, 2010",
    "description": "Shapefile of county boundaries from the US Census Bureau, 2010.",
    "format": "shp",
    "mediatype": "application/vnd.shp",
    "path": [
        "https://bucket.s3.us-east-2.amazonaws.com/county-2010.shp",
        "https://bucket.s3.us-east-2.amazonaws.com/county-2010.shx",
        "https://bucket.s3.us-east-2.amazonaws.com/county-2010.dbf",
        "https://bucket.s3.us-east-2.amazonaws.com/county-2010.prj",
        "https://bucket.s3.us-east-2.amazonaws.com/county-2010.cpg"
    ], 
    "schema": {
        "primaryKey": "HEROP_ID",
        "fields": [
            {
                "name": "HEROP_ID",
                "title": "HEROP_ID",
                "type": "string",
            },
            {
                "name": "name",
                "title": "Name",
                "type": "string",
            },
            {
                "name": "geom",
                "title": "Geom",
                "type": "string",
            }
        ]
    }
}

This works for now for our needs, but raises a couple questions:

1. Would it make more sense to have a zipped file here, instead of a list of all its component pieces?
2. As a sort of token I've added a field to the list called "geom" to represent the shapes themselves, even though this isn't a field in the attribute table. Useful??

With regard to the original post above, all of those extra properties seem reasonable to me, assuming there was a "type":"shapefile" or something along those lines.

EDIT: I realize now I completely missed the mark here on the topic of the discussion! I was confusing "Table Schema" with "Data Resource", and I see that the original idea here is to improve on a Field Descriptor that holds geometry data, not on the Data Resources as a whole that would be holding that field.

So, I guess my question is mostly just about point 2 above, when shapefiles are source of the data. Is there a need to indicate the implied "geometry" field when using a file format that doesn't explicitly expose that column in its tabular component?

[roll]

@peterdesmet WDYT?

Would it make more sense to have a zipped file here, instead of a list of all its component pieces?

The "Multiple Files" section might need a clarification for non tabular usage then https://datapackage.org/standard/data-resource/#multiple-files

As a sort of token I've added a field to the list called "geom" to represent the shapes themselves, even though this isn't a field in the attribute table. Useful??

I think currently it's use case specific as there is no spatial Data Resource type standardized. Actually, I think it would be great to have it

[roll]

I think both spatial support on the Data Resource and Table Schema levels would be very welcome to the specs