[@OKau] Standard format for publishing CSV spatial data on data.gov.au - feedback, comments?
craig.thomler at gmail.com
Wed May 6 04:33:48 UTC 2015
My questions and concerns are not about the specific fields you include,
but around the need for another standard.
While it might be entirely valid, even critical, to create this standard, I
think there's a process necessary to establish the need for it. You may
have already done this, but it wasn't detailed in your email.
Here's some questions to consider:
Can you explain what problems this standard will solve and why no existing
standards are not able to solve them?
Did you consider extending an existing standard to solve these problems
before reinventing the wheel by creating another new standard (ANS)?
Does your standard make it harder or impossible for a data provider to meet
another standard? Particularly one that they are required to meet on a
mandatory basis for legal or contractual reasons?
What futureproofing is being built into this standard to stop the next
person working at National Maps, or elsewhere in government, from throwing
it out and creating another new standard?
Have you calculated the cost for data providers to meet your standard? What
benefits will they get to offset these costs?
What incentives are there for data providers to follow your standard? Will
you compensate them for the cost of meeting it?
Who will endorse this standard as an actual standard? Will be be an
industry or government-backed standard, or just a one-man/agency
Remember: "The nice thing about standards is that you have so many to
choose from." - Andrew S. Tanenbaum
*Mobile:* 0411 780 194 (*International:* +61 411 780 194)
*Phone:* 02 6161 4508 (*International: *+61 2 6161 4508)
On 5 May 2015 at 16:09, Steve Bennett <stevage at gmail.com> wrote:
> Hi all,
> By day, I work on National Map <http://nationalmap.gov.au>, which
> scours data.gov.au and other portals for open spatial data from state and
> federal open data portals (including local government data). It lets you
> choose which of these datasets to view on the map, primarily supporting
> quick assessment of value in a dataset or to answer basic questions.
> Now, we'd like to get a bit more systematic about harvesting CSV data.
> There are two main types:
> 1) Point data described by latitude and longitude
> 2) Administrative region described by reference to a known region such as
> a suburb, postcode, local government area (LGA), ABS statistical area etc.
> (Arbitrary line and polygon features are out of scope for now - they're
> better published as GeoJSON in any case).
> We'd really like to have an agreed standard that data providers can
> publish to, that is both supported by National Map (and other instances of
> Terria), but is a generally good, reusable format for data that will be
> used for other applications as well (including Excel, leaflet, CartoDB,
> ["We" in this case is NICTA, but I have a strong personal interest in
> this, as an Open Knowledge volunteer...]
> I'm tentatively calling it "Aus-Geo-CSV". I've started writing it up here:
> It's probably best to comment here.
> Things I'd particularly like to know:
> - feedback on which fields are widely in use (particularly any history
> around why that's the case)
> - feedback on any likely difficulties in following the standard
> - what else should be in there? Should we be encouraging .vrt files to be
> provided? Do we need to mention character encodings, line endings, quoting,
> - has someone else already done this, and better?
> - are there other administrative regions that are important to support?
> (I'm obviously focusing the spec on what National Map can and will support,
> but it can certainly be broader than that.)
> To make commenting easier, I'll quote the important bits here, but please
> do read the whole thing. (It will probably have changed since I write
> In data.gov.au, datasets that conform to this standard SHOULD be tagged
> "aus-geo-csv". The dataset MUST NOT contain CSV files that do not conform
> (but may contain other non-CSV files).
> - Preferred field names: lat, lon [the only format currently supported]
> - Accepted field names: latitude, longitude; lat, lng
> - Discouraged: x, y;
> - Avoid: WKT (single column with data in POINT(-37.8 144.9) format);
> Each MUST be a number in decimal degrees (EPSG:4326). Numbers SHOULD NOT
> be enclosed in double quotes.
> A four digit postcode.
> - Preferred field name: au:postcode
> - Acceptable field names: postcode
> - Discouraged: poa
> For greater precision, additional fields suburb and state MAY be
> provided. For example: postcode 3068, suburb Clifton Hill, state VIC.
> Local Government Area
> - Preferred field name: au:lga
> - Acceptable field names: lga
> The contents MUST be the short form of the LGA name, with no "City of",
> "Council" etc. For example: "Melbourne", "Greater Geelong". It SHOULD be
> capitalised like this.
> A separate state column MUST be provided, as LGA names are not unique
> across states. A separate au:lga_code column SHOULD be provided.
> - Preferred field name: au:lga_code
> - Acceptable field name: lga_code
> This MUST be the 5 digit code described by the ABS
> For example, Brisbane is 31000. Complete lists are available here
> - Preferred field name: au:state
> - Acceptable field names: state
> - Discouraged: ste
> The contents MUST be the two or three-letter form of the state or
> territory ("VIC", "NT").
> *KM: Case-sensitive?*
> administrative regions
> These region types are also supported:
> - sa4: "Statistical area level 4
> - sa3: "Statistical area level 3
> - sa2: "Statistical area level 2
> - sa1: "Statistical area level 1
> (ABS) [not currently supported by Terria]
> - ced: "Commonwealth electoral division
> - sed: "State electoral division
> - ssc: "State suburbs
> - cnt2: "Two letter country codes" (ISO 3166-1 Alpha 2
> - cnt3: "Three letter country codes" (ISO 3166-1 Alpha 3
> okfn-au mailing list
> okfn-au at lists.okfn.org
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-au
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the okfn-au