"GeoJSON" format type in Table Schema

[stevage]

geojson
The field contains a JSON object according to GeoJSON or TopoJSON spec.
format:
default: A geojson object as per the GeoJSON spec.
topojson: A topojson object as per the TopoJSON spec

There are a couple of weird things about this.

1. Embedding GeoJSON or TopoJSON in a single column of a CSV file seems like a pretty terrible idea. It's a very inefficient way to store geodata such as a single point. (Around 97 characters just to store a lon/lat combo, depending on precision). Is there anyone actually doing this?
2. TopoJSON is not some sub-species of GeoJSON, it's a completely different format.

I would suggest either:

1. Remove it entirely.
2. Rename it "json", and make both "geojson" and "topojson" (and potentially others) the format specifiers. Possibly with a warning that this isn't a good idea. :)

[akuckartz]

WKT (Well-Known Text) probably is better for several reasons. See https://en.wikipedia.org/wiki/Well-known_text

(One reason is better compatibility with linked data standards, GeoJSON is problematic in that regard.)

[rufuspollock]

@stevage i'd be very happy to deprecate this to a pattern and only reintroduce into the spec if there was clear demand #ZenSimplicity 😄

[stevage]

@akuckartz Yeah, my view is the strongest patterns are:

1. "longitude" and "latitude" columns in a CSV file for point data.
2. GeoJSON file for line or polygon data.
3. If you absolutely have to have line/vector data in a CSV, use WKT.

[rufuspollock]

@stevage how are we doing on a draft spec here - i'd be keen to trial this 😄

[Stephen-Gates]

how are we doing on a draft spec

@rufuspollock is there a plan to:

update Table Schema specification:

• add new latitude and longitude types
• remove geopoint to a pattern
• split up geojson and topojson or remove to a pattern
• add well-known text
• update tableschema.xx implementations to match?

and more broadly, based on Spatial Data Package Investigation recommendations, to:

• add locations to Data Resource
• implement a specification for boundary codelist schemes and identifiers
• implement a service for resolving identifiers to geometries?

I plan to make made example data packages to reflect the recommendations (with some tweaks noted in the readme):

• point data
• simple vector
• boundary-linked data via code list
• boundary-linked data via geojson

[rufuspollock]

@Stephen-Gates these are good questions and represent an overall "epic" of work re geo types in the specs that go beyond this specific issue.

I'm not yet sure about adopting the recommendations of the investigation wholesale esp the locations concept. I would like to hear more still about how people are using the current stuff and potential future stuff in the wild (and I'd like to do some more geo data packaging ourselves ...)