Adds doc pages for the new elements and enums introduced with geospatial modeling for VIP6.
I ended up having to make more decisions than I anticipated around CSV modeling of geospatial data. This can be viewed as a proposed solution to the CSV specification, so please feel free to comment and suggest alternatives.
A few noteworthy aspects of the decisions made for CSV modeling:
The two fields are an ID reference in the CSV specification, but are simply nested elements in the XML specification. These work best as nested elements in the XML, but it's easier and more flexible to normalize them for CSV.
ExternalFile.Checksum
SpatialBoundary.ExternalGeospatialFeature
ExternalGeospatialFeature.SpatialIndex is a repeated field in the XML, but scalar in CSV. We could have done multiple CSV columns (spatial_index_1, spatial_index_2, etc.), but we don't know how many discrete shapes may be needed to model every precinct. So to maintain more flexibility, I modeled this is a single scalar field in the CSV specification which allows for multiple values by pipe delimiting. I didn't see this approach used elsewhere in the CSV spec, but seems like a reasonable solution to me.
Adds doc pages for the new elements and enums introduced with geospatial modeling for VIP6.
I ended up having to make more decisions than I anticipated around CSV modeling of geospatial data. This can be viewed as a proposed solution to the CSV specification, so please feel free to comment and suggest alternatives.
A few noteworthy aspects of the decisions made for CSV modeling: