+1 on the import overall!
A couple comments:
-
I realize it may not be a stable reference number, but have you at least considered whether to encode the OBJECTID (or if any other unique ref exists) as a stable reference to that specific tree, to aid updating and cross-reference against the campus tree database?
-
There appears to be a field PlantTypeText as part of the species data; have you considered deriving leaf_cycle and/or leaf_type from this instead of (or additional to) relying on a lookup table?
-
There are a bunch of typos/errors in the value example for the inscription=* tag:
European Beech Fagus sylvatica Scott Danforth Sandbloom '82 1960-1995 One of his greatest joys was building sand castles, wiith scores of giggling kids climbing on his back,helping, hampering,reveling in his attention.
Are these present in the source? Or how were they introduced?
Indeed; given it is already present in the dataset, seems like it would have considerable value to include at trivial cost, especially considering many trees seem to have multiple visits over the years. And in case anyone was suitably motivated to survey the trees themselves, this could help avoid overwriting their changes when resyncing the dataset unless the latest arborist visit was more recent.
Given these data are unlikely to be touched by regular users and will be kept updated from this data source, I don’t see any meaningful harm here in including both, given it is effectively zero actual cost.
For the record, this is not true; SI is widely used in the sciences, is the official standard in many areas of military and defense, sees considerable use alongside US customary units in various engineering, R&D and similar disciplines (including GIS), and sees use in other sectors, as well as is preferred for daily life by a small but not-insubstantial fraction of the native population (including myself), particularly among those most likely to be OSM contributors, alongside the large number of immigrants from the rest of the world that grew up with it.
That being said, though, I fully agree with the rationale:
that measurements should be recorded as specified in the source rather than mandating a lossy and inexact conversion (against what is recommended on the relevant wiki page), instead allowing the data consumer to whichever units they need. This follows from the fundamental principle of OSM, map what’s on the ground–i.e. as signposted, measured or mandated. Therefore, US height limits and speed limits are mapped in USC units (aside from the handful of very rare corner cases where they are actually specified as metric), whereas for measured quantities it matches what was actually measured/recorded.
For example, in one particular area I map, building heights from a local LIDAR data collection project are mapped in meters, as was recorded by such, as are most distances measured by mappers on the ground or from aerial imagery (unless the actual on the ground object is clearly and unambiguously built to an exact number of USC units in size); whereas measurements originally performed and recorded in USC are recorded as such, as are speed and height limits as these are the actual signposted and mandated limits (with a few rare exceptions).
I’ll keep them.