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
Currently, each shape dataset returns a collection of GeoJSON Features, each with the Properties property populated by with a hash of the item's database fields. Unfortunately the names of these fields are completely non-standard and depend greatly on the dataset. This makes it essentially impossible to provide a standardized visualization of that data except by dumping the entire properties list to display.
I'm proposing adding, both in existing shape datasets (which I'm happy to assist with) and as part of the submission process, a property defining which dataset-specific column name(s) contains the principal representation of the constituent shapes. For example, a neighborhood boundary dataset might expose the properties
for a certain shape. To a human this clearly represents a neighborhood called "Sheffeild & DePaul", and that is probably how the human would refer to that particular Feature, but it is essentially impossible to infer without a semantic understanding of the dataset's content and the entry's property names.
My proposal would add something like display_name: "pri_neigh", either to the individual shapes or to the dataset itself, simply describing which column represents the common name of the elements. This allows the dataset's structure to be maintained while allowing some amount of standardized display.
The text was updated successfully, but these errors were encountered:
Currently, each shape dataset returns a collection of GeoJSON
Feature
s, each with theProperties
property populated by with a hash of the item's database fields. Unfortunately the names of these fields are completely non-standard and depend greatly on the dataset. This makes it essentially impossible to provide a standardized visualization of that data except by dumping the entire properties list to display.I'm proposing adding, both in existing shape datasets (which I'm happy to assist with) and as part of the submission process, a property defining which dataset-specific column name(s) contains the principal representation of the constituent shapes. For example, a neighborhood boundary dataset might expose the properties
for a certain shape. To a human this clearly represents a neighborhood called "Sheffeild & DePaul", and that is probably how the human would refer to that particular
Feature
, but it is essentially impossible to infer without a semantic understanding of the dataset's content and the entry's property names.My proposal would add something like
display_name: "pri_neigh"
, either to the individual shapes or to the dataset itself, simply describing which column represents the common name of the elements. This allows the dataset's structure to be maintained while allowing some amount of standardized display.The text was updated successfully, but these errors were encountered: