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

Steve Bennett stevage at gmail.com
Tue May 5 15:17:28 UTC 2015


On Tue, May 5, 2015 at 11:50 PM, Simon Cropper <
simoncropper at fossworkflowguides.com> wrote:
>
> You could but not all people have the ability to convert old data. The
> more you expect the custodian to massage the transform and convert the data
> the less likely the data will be released.
>
> In all the years I have been involved in munging and wrangling data on
> flora and fauna in Victoria and Australia; I know without doubt I would
> have never managed to get access to any data unless I took it in the format
> it was provided and value added by conducting the transformation, cleansing
> and standardization required.


Yep, I hear you. My work on opentrees.org is a pragmatic balance between
standardising (
https://github.com/okfnau/open-council-data/blob/master/trees.md) and
munging (https://github.com/OKFNau/TreesMap/blob/master/mergetrees.sql) and
cleansing (https://github.com/OKFNau/TreesMap/blob/master/cleantrees.sql).
More about that here
<http://stevebennett.me/2015/04/07/opentrees-org-how-to-aggregate-373000-trees-from-9-open-data-sources/>
.

Standards like these are of course optional. The proposition is: "If you
choose to follow this standard, you will get some additional benefits, such
as your data being visible on
openbinmap.org/opentrees.org/nationalmap.gov.au". It's a carrot, not a
stick.

Steve, we are in Australia! If you fall back to anything then it should be
> the Australia Standard --- GDA94 (EPSG 4283). I would expect GeoSciences
> Australia would absolutely mandate this!
>

Told you geodesy wasn't my strong suit :)

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


More information about the okfn-au mailing list