Closed kgeographer closed 9 years ago
I very much agree. My use case remains Roman Amphitheaters. These can have different phases, with different chronological ranges and properties (such as capacity if amphitheater is expanded). One question: how about a default Geometry (at least)? For my work, I actually don't currently have different geometries for different phases, but hope to. Until that time, it isn't useful to repeat Geometry. I'm not sure if default for Properties and When are also useful?
I think you're on to something! What if the original elements geometry and properties are left alone, when is added (and ignored by existing GeoJSON interpreters), and all three are considered to be either default or summative by future Topotime interpreters. Then add a settings array, understood as an elaboration, a sequence of states (also ignored by existing GeoJSON interpreters).
Future tools could guide users to create the "default," or ask them to identify one of the settings to have that role.
Is it this simple? (leaving aside fancy Topotime operators like ~, >, <, and constructs like duration and during): [sample data file to follow soon]
{
"@context": "http://settingpattern.org/setting.jsonld",
"type": "FeatureCollection",
"id": @id,
"crs": {"type": "___", "name": "___"},
"projection": { "wgs84" },
"features": [
{ "type": "Feature",
"id": @id,
"properties": {"name": "Massachusetts", "description": "modern extent", "src": "___"},
"geometry": {"type": "MultiPolygon", "coordinates": [[...],[ ]]},
"when": [ {"type":"Interval", "s": "1630" } ],
"settings": [
{ "geometry": {"type": "MultiPolygon", "coordinates": [[...],[ ]]},
"when": [ {"type":"Interval", "s": "1630", "e": "1691" } ],
"properties": {"name": "Massachusetts Bay Colony", "prop2": "___"}
}, {
"geometry": {"type": "MultiPolygon", "coordinates": [[...],[ ]]},
"when": [ {"type":"Interval", "s": "1691", "e": "1776" } ],
"properties": {"name": "Province of Massachusetts Bay", "prop2": "___"}
}, {
"geometry": {"type": "MultiPolygon", "coordinates": [[...],[ ]]},
"when": [ {"type":"Interval", "s": "1776" } ],
"properties": {"name": "Commonwealth of Massachusetts", "prop2": "___"}
}
]
}, {
"type": "Feature",
"id": @id,
"properties": {"name": "Colonial America", "description": "maximal extent", src": "___"},
"geometry": {"type": "MultiPolygon", "coordinates": [[...],[...]]},
"when": [ {"type":"Interval", "s": "1607-05-14", "e": "1776-07-03"} ],
"settings": [
{ "geometry": {"type": "MultiPolygon", "coordinates": [[...][...]]},
"when": [ {"type":"Interval", "s":"1607-05-14", "e":"1625" } ],
"properties": {"description": "original extent of Virginia"}
},{
"geometry": {"type": "MultiPolygon", "coordinates": [[...][...]]},
"when": [ {"type":"Interval", "s":"1607-05-14", "e":"1626" } ],
"properties": {"description": "added New York"}
}
]
}
Topotime v0.2 will join place and period in a form similar to GeoJSON and GeoJSON-LD. A key issue is whether that form should also be compatible with GeoJSON.
Simply adding a "when" object to a GeoJSON feature does not prevent GeoJSON-compatible applications from parsing a FeatureCollection. @ekansa demonstrates this in a GeoJSON-LD implementation for Open Context (http://opencontext.dainst.org/about/services). However this approach does not account for sequences -- cases of feature extents changing over time; a distinct Feature must be defined for each spatial extent. This creates a redundancy problem, particularly if a Feature has numerous properties.
The alternative is for each Feature to have a set of one or more Contexts. Each context includes one or more Geometry, zero or more When objects, and zero or more Properties. This obviously breaks the GeoJSON model, making Topotime data incompatible with all existing GeoJSON-parsing applications...a big price.
Is this unavoidable? That is, should a new path be charted, an alternative to GeoJSON that accounts for place and time being co-equal attributes of geographic features? My view is yes.