For data that are at the block group level, we would like to have the database deliver both the blockgroup ID and the centroid at latitude and longitude. For data at the point level (like USGS), can just deliver lat and long. For data at other levels, we need a verbatim field. Latitude and longitude will need to be broken into separate fields.
In order to make all of these data compatible with Darwin Core (which we will need for ontology mapping), I suggest including the fields below in the database. Not every dataset will have every field.
locationID (http://rs.tdwg.org/dwc/terms/locationID): An identifier for the set of location information (data associated with dcterms:Location). May be a global unique identifier or an identifier specific to the data set.
We would use this field for blockgroup ID
county (http://rs.tdwg.org/dwc/terms/county): The full, unabbreviated name of the next smaller administrative region than stateProvince (county, shire, department, etc.) in which the Location occurs.
decimalLatitude (http://rs.tdwg.org/dwc/terms/decimalLatitude): The geographic latitude (in decimal degrees, using the spatial reference system given in geodeticDatum) of the geographic center of a Location. Positive values are north of the Equator, negative values are south of it. Legal values lie between -90 and 90, inclusive.
decimalLongitude (http://rs.tdwg.org/dwc/terms/decimalLongitude): The geographic longitude (in decimal degrees, using the spatial reference system given in geodeticDatum) of the geographic center of a Location. Positive values are east of the Greenwich Meridian, negative values are west of it. Legal values lie between -180 and 180, inclusive.
We will be discussing this on tomorrow's call, and I will determine if any other fields are needed. If there are other location types, we could include:
For data that are at the block group level, we would like to have the database deliver both the blockgroup ID and the centroid at latitude and longitude. For data at the point level (like USGS), can just deliver lat and long. For data at other levels, we need a verbatim field. Latitude and longitude will need to be broken into separate fields.
In order to make all of these data compatible with Darwin Core (which we will need for ontology mapping), I suggest including the fields below in the database. Not every dataset will have every field.
locationID (http://rs.tdwg.org/dwc/terms/locationID): An identifier for the set of location information (data associated with dcterms:Location). May be a global unique identifier or an identifier specific to the data set.
county (http://rs.tdwg.org/dwc/terms/county): The full, unabbreviated name of the next smaller administrative region than stateProvince (county, shire, department, etc.) in which the Location occurs.
decimalLatitude (http://rs.tdwg.org/dwc/terms/decimalLatitude): The geographic latitude (in decimal degrees, using the spatial reference system given in geodeticDatum) of the geographic center of a Location. Positive values are north of the Equator, negative values are south of it. Legal values lie between -90 and 90, inclusive.
decimalLongitude (http://rs.tdwg.org/dwc/terms/decimalLongitude): The geographic longitude (in decimal degrees, using the spatial reference system given in geodeticDatum) of the geographic center of a Location. Positive values are east of the Greenwich Meridian, negative values are west of it. Legal values lie between -180 and 180, inclusive.
We will be discussing this on tomorrow's call, and I will determine if any other fields are needed. If there are other location types, we could include:
verbatimLocality (http://rs.tdwg.org/dwc/terms/verbatimLocality): The original textual description of the place.