Right now metadata is this ill-defined dumping ground for arbitrary properties in an item.
The problem is we already have a field to put arbitrary GeoJSON, enforced as FeatureCollections. Anything that is geospatial data should ALWAYS be represented as a FeatureCollection. If existing incoming formats do not neatly fit into the GeoJSON spec, we should make sure we document and have strong conventions in properties of features that are interpreted in a particular way. Allowing for linked-lists, for example by allowing features to be part of a "group", would allow for additional metadata to be attached to points that should be part of a line string.
Right now, we don't have a clear use-case for metadata and the problem with having it there, is it's going to land up being used as a dumping ground, and a way to "take the easy way out" by just dumping JSON in there. If there are use-cases for specific additional fields on Item, we should discuss and add them as additional fields in the database. But we should not use metadata as a cop-out for things that don't neatly fit into the definition of a FeatureCollection - we should make sure we have agreed, well documented conventions and always represent geospatial data as FeatureCollections.
If there really is a use-case for metadata on the Item level, am happy to hear. I definitely do still see some use-cases for metadata on the Project level, but that is probably a separate conversation.
This is probably a bit contentious :-) - of course happy to hear counter opinions.
Right now
metadatais this ill-defined dumping ground for arbitrary properties in an item.The problem is we already have a field to put arbitrary GeoJSON, enforced as FeatureCollections. Anything that is geospatial data should ALWAYS be represented as a FeatureCollection. If existing incoming formats do not neatly fit into the GeoJSON spec, we should make sure we document and have strong conventions in
propertiesof features that are interpreted in a particular way. Allowing for linked-lists, for example by allowing features to be part of a "group", would allow for additional metadata to be attached to points that should be part of a line string.Right now, we don't have a clear use-case for
metadataand the problem with having it there, is it's going to land up being used as a dumping ground, and a way to "take the easy way out" by just dumping JSON in there. If there are use-cases for specific additional fields onItem, we should discuss and add them as additional fields in the database. But we should not usemetadataas a cop-out for things that don't neatly fit into the definition of a FeatureCollection - we should make sure we have agreed, well documented conventions and always represent geospatial data as FeatureCollections.If there really is a use-case for
metadataon the Item level, am happy to hear. I definitely do still see some use-cases formetadataon theProjectlevel, but that is probably a separate conversation.This is probably a bit contentious :-) - of course happy to hear counter opinions.
cc @samanpwbb @mcwhittemore @emilymdubois