[@OKau] Standard format for publishing CSV spatial data on data.gov.au - feedback, comments?

Tue May 5 09:02:32 UTC 2015

Lots of great feedback, so I'll respond to a couple in one hit.

On Tue, May 5, 2015 at 4:38 PM, Paul Walsh <paulywalsh at gmail.com> wrote:

> * What is not working with GeoCSV (http://giswiki.hsr.ch/GeoCSV) for
> you? (I haven’t used GeoCSV, so, its a genuine question, but I was thinking
> of adding support for GeoCSV to some libraries I’m working on)
>

Seems to be protected by a Google-proof shield. Honest! But the scope is a
bit different ("how to generally encode spatial data in CSV" rather than
"how should Australian government bodies express point and region-mapped
data in CSV").

> * Are you familiar with all the spec work at Data Protocols (
> http://dataprotocols.org)? Of interest to some of your questions:
> http://dataprotocols.org/csv-dialect/
> http://dataprotocols.org/tabular-data-package/
>

Paul and I just had a great Skype chat where he gave me an overview of all
the work OK is doing for the UK government, and under the "frictionless
data" banner more generally. I'll definitely be diving into these further.

But these are obviously essentially ways of *expressing* a standard and
working with data that is known to conform to that standard, so it doesn't
solve the problem of what the standard should be - but is likely to be part
of the solution.

> In general, if you wanted to propose this spec as a Data Package Profile (
> http://dataprotocols.org/data-packages/) then I’m pretty sure there would
> be some interest from the wider network of orgs and people working on Data
> Protocols.
>

Excellent.

Craig Molyneux wrote:
>I’m assuming from the structure you’ve indicated here that you’re
considering the major continental Australian regions. I think rather than
indicating ‘state’ it should probably be something like adm1, as these are
first order administrative regions, and include all Australia’s continental
and offshore territories, such as Coco Keeling Island, Christmas Island,
Norfolk Island, etc. Likewise with lga. This would be better represented
 as adm2, i.e. second order administrative regions. This is more consistent
with other international datasets.

Thanks, that's very helpful. I'm torn between what is the most intuitive to
data producers and consumers ("lga") and what makes the data as broadly
useful as possible (international standards like "adm2"). It's possible
that something like OK's JSON Table Schema
<http://dataprotocols.org/json-table-schema/> could serve as the bridge
(crosswalk?) between the local terms and international standards. Hmm.

> The ‘Other admin regions’ you refer to are not really ‘administrative
regions’, in the same sense as states, territories and lga’s, rather
regions defined for statistical or other purposes and as a result are prone
to change on a regular cycle.

Good point, that was a term I picked up from CartoDB. "Statistical areas" I
guess.

>Also, if you’re going to truncate the full name of lga’s then there should
be an adm2type column to delineate whether it’s a City, Shire, Regional
Council, etc.

Ok, but why would that matter? It's not needed for joining to a set of
polygons?

> See the Global Administrative Areas Database here
http://data.fao.org/map?entryId=48a5cab8-1f15-41ff-b530-673580735373&tab=about
for more info.

Excellent, didn't know that existed.

Paul Walsh again:
>For representing “regions”, of all types, consider Open Civic Data’s
Division Identifiers specification. This will help increase the
applicability of this spec for general use:
>https://github.com/opencivicdata/ocd-division-ids
>http://docs.opencivicdata.org/en/latest/proposals/0002.html

Looks useful, but I guess those are good linking identifiers to include in
a schema, rather than to serve as actual cell values?

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/okfn-au/attachments/20150505/beb51d03/attachment-0004.html>