You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Quoting #822 (comment):
The text was updated successfully, but these errors were encountered: