Add Latitude and Longitude to Location Dimension

[joshuacpowell]

Currently, the location Dimension includes only names and IDs/codes (which is an excellent start). Adding latitude/longitude fields (preferably with the source of those fields being tied directly to a known gazetteer, which should also supply the location code) would allow potential data users to more easily take the data to visualize/map/perform geospatial analysis. This should also be accompanied by specification of the geographic projection (or possibly denoting that all lat/long should be in WGS84) used for the coordinates.

[danfowler]

Thanks for raising this issue! :+1:

[stevage]

Does spending map well to single points? My main work these days is geospatial, but this makes me a little uneasy. Are you mapping the capital city of a region? At what precision?

I kind of think that if you're deriving the lat/lon from the data (rather than it being an independent fact published with the data - I guess some spending has a very localised impact) then it makes more sense to make that part of the analytics platform, rather than the underlying data format.

Finally - yes, definitely insist on WGS84 lat/lons, as per the GeoJSON spec.

[joshuacpowell]

Very good points, Steve. In other standards, typically the lat/long used is for the centroid point of an administrative division (unless a more specific location reference is available). I would suggest including a few descriptive fields, for example the Location Class field used in IATI (http://iatistandard.org/201/codelists/GeographicLocationClass/) and perhaps the exactness code from IATI as well (http://iatistandard.org/201/codelists/GeographicExactness/). For standardization, you could also insist on referencing which gazetteer is used (http://iatistandard.org/201/codelists/GeographicVocabulary/).

In a perfect world, the geography used would likely be polygons that represent the proper administrative boundaries, but there is remarkable overhead to doing this across many countries/data providers, which is why other standards have settled for point-based geographies.

[stevage]

but there is remarkable overhead to doing this across many countries/data providers

There sure is. (FYI, I developed this standard for statistical geographies in Australia: csv-geo-au )

I'm still pretty iffy on encouraging providers to include fields which can be derived automatically from other fields though.

[timgdavies]

For the Open Contracting Data Standard we're looking at a location extension that incorporates options including a GeoJSON description of a feature where items are to be 'delivered' (either physically - as in goods, or build assets, or conceptually - as in the delivery area of a public service), as well as a gazetteer option for pointing to a range of kinds of locations, from admin geography to Open Street Map ways.

I suspect the structures here don't fit easily into the Fiscal Data Package, but one of the guiding ideas was that asking people to geocode from address to point can generate misleading results.

All the points in the map end up in the centre of cities when more detailed address data is not available, and the central points of an area are not always where the population are etc.

Decisions about whether this kind of biased mapping of points is justified or not should be left to consuming applications, rather than publishers - but publishers should be given space to state as much as they do concretely know about locations.

One of the questions when using gazetteers is around how to identify them. In OCDS we've tentatively been looking at a codelist of gazetteers, but ideally would manage this kind of list as as shared resource.

[stevage]

Ok, good points. I'm probably being too narrow in thinking only of use cases most familiar to me.

FYI I came across this local example today of a budget published with location data: http://myinfrastructure.planning.nsw.gov.au/#project/UID278

[pwalsh]

Moving to https://github.com/frictionlessdata/datapackage-fiscal/issues/3