Hello from Christchurch, New Zealand. I have just come across OSM and would like to gain a better fundamental understanding of it. Can someone point me to a good resource to check up and learn (video, pdf, etc.).
Also I work as a Natural History Collection Technician and handle lots of specimen collection data. With this data, especially older/historic data the collector would not put location co-ordinates and enter a vague area of collection.
Unless the specimen is aquatic it is likely collected from the a terrestrial environment i.e. riverbed or surrounding forested valley. I think it would be neat to use OSM to create closed ways that can be linked as a reference a collection event approximately within the bounds of said way (as we don’t know the specific collection point).
If anyone has ideas on the best way to do this, it would be greatly appreciated.
are in general the best resources for general beginners (please ignore the introduction section on learnosm). But simply having a look at the intro built in to “iD” the in-browser editor and going out and mapping a few simple things is likely a better starting point than trying to read up everything in advance.
I suspect that the collection area data is not a good fit for direct inclusion in OSM, but you could maintain such data easily on a umap instance (the most popular one is umap.openstreetmap.fr).
A very interesting problem. Yesterday I was reviewing some GBIF data in S. America and it is obvious that a historical specimen was geocoded to the capital of a province (Rawson, Chubut), whereas in all likelihood it was collected 4-500 km away in the Andes. At one of our London pub meetings we actually chatted about this because someone had done some work at the Natural History Museum London. Apparently marine historical biological records are much more likely to be accurately geolocated than terrestrial ones.
Clearly what you want is a collection of geolocations either as points, lines or polygons which reflect the actual precision of the information available to you. For instance the Waimakariri River data can be collected from OSM via a query using the Overpass-turbo tool: http://overpass-turbo.eu/s/wON. For your purposes this might then need to be buffered by a distance that in your opinion reflects the likely usage of the term by the original collector(s).
Currently, and, I think, for the foreseeable future, this type of data does not belong directly in OSM. The reasons are:
OSM is a collective work, so all data entered can be seen (and perhaps more relevantly) edited by anyone else.
Unlike many other GIS systems/data OSM does not internally have a concept of layers. Everything is all in one pot. Layered data can be created for consumption, but it is not stored that way. This approach has advantages (explicit interconnectivity for highways, instant feedback which stops people adding buildings across roads or roads which go right through buildings, a simpler model for editors and other tools) and disadvantages (complexity for people adding data in well-mapped places; harder to do thematic work).
OSM has no explicit programme or plan. It is very much driven by what people want to contribute to it, and to some extent where they live. That being said, there is a clear hierarchy of what gets mapped, with road and path networks being foremost (not necessarily in that order, because cyclists were early adopters), then core POIs (supermarkets, hospitals, banks, atms, pubs etc), big obvious landuse & natural areas (parks, woods, water bodies). Thereafter people may map thematically across large areas (perhaps as in NZ with LINZ, importing data), or adding increasing amounts of detail in their local area (micromapping). Although this is not organised/directed it works pretty well: popular areas (big cities, holiday destinations) tend to get done first, which means that stuff which gets used most is already there. (As an aside I think cycle paths were added in Christchurch by the local authority)
So how can OSM help you in your work:
First, because data can be added to OSM it is possible to create richer and more detailed maps, which in turn can greatly assist in better location data for specimens. Mainly this applies in the here and now: it’s actually the reason I started with OSM in the first place.
Second, similar to the first, there is much more scope for capturing additional places compared with traditional maps, and local names etc. This may again may assist in better coding of specimens
Third, as an initial source for geometries to relate to the fuzzier geographies in the collection.
Fourth, straight geocoding. You can do this for Waimakariri River but as the river is split into many sections, the actual delivered lat/lon may be misleading for your purposes.
I think the third is probably what would be most helpful, and I would agree with Simon, that umap is a reasonable place to start with.
In the longer term probably many museum folk really need a shared repository of suitable geographies (i.e., not arbitrary points) for coding historical collections. It would be interesting to just see how many distinct descriptions of collection locations you actually have in the extant digital collections. I undestand that location in Darwin Core (the underlying standards for GBIF) allows the general use of WKT (Well-known text) which in turn allows use of a wide range of geometries, including polygons etc. However, most people still use points: I was told “people like points”. So depending on how data is stored in your institution you may be able to add WKT location data to your database. OSM may well be a reasonable way to collect such data, although I’m not sure if there is any direct way of getting WKT from OSM geometries. Overpass will allow data to be saved as geojson and you can probably convert to WKT with ogr2ogr.
If there are lots of identical location descriptions it may be easier to keep a side dataset with the geometries and an identifier and assign identifiers to those descriptions,. You could use shapefiles or a spatial db for this purpose (e.g., PostGIS). All of this will very much depend on your precise institutional set-up, and this is me thinking outl oud.
Thank you kindly for your replies, they help a lot. I will try and learn by doing (referring to resources when I am at a loss for what to do). As I tramp a fair bit, hopefully I can add some useful edits and data to certain areas!
Regarding my question that makes sense. I think my purpose at this stage is to have a stable link that can be referenced to our DB records, so umap should be sufficient for that. Do you think it will make sense for OSM to accommodate this sort of data in the future? I fully agree from a museum perspective a shared repository of this type of data would be ideal, especially as Open linked data becomes more widely used. Haha people do like points, but polygons and data like this are really beneficial supplementary information.
A quick question on umap, can you import basemap layers, or only use the base ones provided. It would be good if I could use NZ Topo Maps as the basemap layer when drawing polygons. If not I can manage otherwise I think.
Stable identifiers are another issue: OSM does not technically offer them, although many OSM identifiers are long-lived. There definitely seems to be scope for a shared repositories; I’m doing a bit more sleuthing as I have a dataset I am working on which would benefit from the same sort of treatment. GitHub may be a suitable place in the first instance; but again one needs the tech for stable identifiers (& versioning).
As for backgrounds in umap; I think they are configurable (choose settings & then custom background) but expect an XYZ tile format (TMS). It looks like the NZ Topo Map from LINZ is available in WMS & WFS formats (see the OSM Wiki: https://wiki.openstreetmap.org/wiki/New_Zealand/Imagery)), but these are not currently supported in umap. There is a tool available to translate WMS to TMS called Whoots by OSMer Tim Waters: http://whoots.mapwarper.net/. It’s a long time since I used it and I don’t know how well it behaves if there is an API Key or logon for the WMS service., so this is a long shot.