martindholmes
commented
2 years ago As a follow-up, there's a bit of a wrinkle in this bit:
Multiple <location> elements will be allowed inside <place>, and each will have a single
The GeoJSON spec does not allow distinct geometries for a single feature EXCEPT through the use of a GeometryCollection (https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.8). The possible wrinkle is that there may be places which require a GeometryCollection to describe a single instance of their location (imagine for example a location that consists of a building [Polygon], a road [LineString] and a small tower [Point]). This case would need to be distinguished from cases where a GeometryCollection is being used to represent multiple feature locations for different time periods. We would have to make the assumption that:
- If there is only one time-period in a GeometryCollection feature, then the GeometryCollection represents that feature throughout the time period.
- If there are multiple time-periods and the same number of geometries in a GeometryCollection, then each geometry in the collection aligns with the respective time-period.
- If there is a mismatch between the number of geometries and the number of time-periods, then we have an ambiguous situation and we must raise an error. It is quite conceivable that we might have genuine cases which ought to be represented in this way, but because of the inherent ambiguity, we can't handle them, and we must set them aside.
JanelleJenstad
This ticket proposes three specific changes:
The
<state>element must be added to the content model of the<place>element, but must not be allowed anywhere else. This will mean changing the class membership of the<state>element and altering the content models of any macros which contain it to eliminate it from all other locations, then creating a custom content model for the<place>element which includes<state>.<state>will require all its dating attributes.The following encoding practices will be adopted and tested within MoEML: i. Multiple
<location>elements will be allowed inside<place>, and each will have a single<geo>element for a specific location for the place at a specific time[-range].@from-customand@to-customattributes will be supplied whenever a location has a limited temporal range within the MoEML project's bounds. Where such attributes are not provided, there will be a global assumption that MoEML claims this location is valid for the period 1536 to 1666, but makes no claims outside that range. Where one or other bounding attribute is missing, the standard MoEML range boundary will be assumed. ii. Multiple<state>elements will be allowed withing<place>, with the same assumptions as to date ranges as apply to<location>elements. Each<state>element should also carry an@anaattribute pointing to a MoEML category, using the same private URI scheme as MoEML uses for<catRef>/@target. A corresponding<catRef>should also be present for the purposes of normal MoEML processing (we can check this with Schematron). Each<state>element represents the function a place had during a specific time range. iii. Multiple<placeName>elements are allowed in<place>, with the same dating attributes having the same purpose as discussed above.All dating attributes will be in our normal MoEML mol:julian format.
<placeName>elements, each with a date-range as appropriate. iii. Ditto for place function, as represented by<state>elements.In the GeoJSON, all date ranges will be converted to proleptic Gregorian, before their month and day information will be stripped, providing a less granular date range, but one which is less likely to cause confusion for those not used to proleptic Gregorian.
The precise names and datatypes for the GeoJSON custom properties should be agreed ahead of time with the LINCS team, so that we use a standard vocabulary and their ingestion code can be more standardized.