Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Geometry Datatype part of the core CSVW standard #828

Open
iherman opened this issue Feb 18, 2016 · 0 comments
Open

Geometry Datatype part of the core CSVW standard #828

iherman opened this issue Feb 18, 2016 · 0 comments

Comments

@iherman
Copy link
Member

iherman commented Feb 18, 2016

Quoting #822 (comment):

Thinking more about the approach of using custom datatypes, would it not be better for users and software implementers to consider making the geometry datatype part of the core CSVW standard? The approach of using custom datatypes is too ambiguous and open to too much interpretation, which will make widespread use hard. Also having a core datatype means the ability to add annotations such as the geometry "type" (i.e. point, linestring, polygon, multipoint, multilinestring, multipolygon, geometrycolumn) and the geometry's coordinates reference system "crs" (e.g http://www.opengis.net/def/crs/EPSG/0/4326). Also IMHO using WKT for the definition is the best fit for the CSV data because it is the most commonly used serialised text format for export and import out of database systems. e.g Oracle spatial, Informix, DB2, PostgreSQL etc. Maybe the main use case of x,y or lat/long point positions could be left to using number/double datatype. JSON and KML is mostly used in full XML or JSON documents, rather than being used as a fragment within plain text files such as CSV.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant