[gdal-dev] [OSGeo-Standards] CSV spatial data on the web

[Stefan Keller]

Hi Jeremy

> However looking at the GeoCSV specification it would be a step
> backwards for our users due to the field delimiter being semicolon.

Semicolon is well supported in software.
Tab is poorly supported in some text editors.
Comma is heavy used in number values in european countries.
What delimiter do you prefer and why?

> We also advertise the geometry datatype (useful for software quickly
> reading the data field metadata), field lengths/widths in the VRT,

That's covered by CSVT, isn't it?

> and have datasets with legitimate carriage returns within fields.

Allowing non-printable control-characters in strings makes it very
complicated and disables mainly all existing CSV software.
carriage returns is one of the few undisputed end-of-line things in
CSV (besides CR, LF, CR/LF differences).
Markup to the rescue.
What do you prefer?

:Stefan

[1] http://tools.ietf.org/html/rfc4180



2016-02-17 11:16 GMT+01:00 Jeremy Palmer <JPalmer at linz.govt.nz>:
> Hi Stefan,
>
> Yes I’m aware of the GeoCSV specific and the implementation within OGR. We actually support CSV+VRT from the NZ land data service: https://data.linz.govt.nz/. When we did the implementation about 4 years ago I don’t think your specification was around. I do like the simple approach of the CSVT.
>
> However looking at the GeoCSV specification it would be a step backwards for our users due to the field delimiter being semicolon. We also advertise the geometry datatype (useful for software quickly reading the data field metadata), field lengths/widths in the VRT, and have datasets with legitimate carriage returns within fields. What are the reasons for these design decisions or restrictions?
>
> Cheers,
> Jeremy
>
>> On 17/02/2016, at 7:57 AM, Stefan Keller <sfkeller at gmail.com> wrote:
>>
>> Hi Jeremy
>>
>> Thanks for the info.
>> I assume you are aware of GeoCSV and related software like the
>> well-known OGR (and the #TheShapefileChallenge ):
>> http://giswiki.hsr.ch/GeoCSV
>>
>> :Stefan
>>
>>
>> 2016-02-16 19:40 GMT+01:00 Jeremy Palmer <JPalmer at linz.govt.nz>:
>>> For forks that are interested W3C has setup a CSV on the Web Working Group https://www.w3.org/2013/csvw/wiki/Main_Page to provide recommendations for better interoperability when working with CSV datasets.
>>>
>>> I raised an issue a few months ago on the working documents, with my main issue being that spatial datatypes are not really accounted for:
>>>
>>> https://github.com/w3c/csvw/issues/795
>>>
>>> I believe this is an important thing to solve as publishing large open datasets is something that is not well addressed and keeps getting reinvented by multiple groups or vendors.
>>>
>>> They have now responded to my issue with this response:
>>>
>>> https://github.com/w3c/csvw/pull/822
>>>
>>> But I think this response needs a wider community view.
>>>
>>> Cheers,
>>> Jeremy
>>>
>>> This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info at linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.
>>> _______________________________________________
>>> Standards mailing list
>>> Standards at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/standards
>