This post details four fundamental aspects to consider when you need to work with or request geographical data.
The post is written in the same tone as the previous one (7 things to consider when you need a map), namely as a check list for experts in fields other than GIS/remote sensing who need to work with geographical data or request it from third parties.
As in the case of the previous list, I share it here so it can be used by a broader audience.
Do you think there is something important missing or wrong? Feel free to remind me in the comments!
What to consider when you need geographical data?
Start at the end. What is the ultimate need that we are satisfying by producing or requesting these data? Thinking about these questions will save time and money in the long and short run.
- Why are we requesting these data?
- Who will use these data?
- Do we have formal templates for our case at hand?
- What are the most important attributes for this end?
- Does some part of the information need special management?
- Do we have a suitable temporary or permanent repository for dataset?
Inconsistencies with coordinates are by far the most common cause of problems with geographical data. It is important to be clear about what we need so we avoid problems for future users.
- Do we wish to use one or more preferential coordinate system? Then, specify clearly which ones. Using EPSG codes is always useful and eliminates ambiguity.
- If data will be delivered as table, require double checks in the order of coordinates. See figure below.
The choice of format is important because it affects usability and long term preservation. Therefore, preferably use or ask for formats that are well defined according to open standards.
- For vector data, request preferentially GeoPackage. Avoid ShapeFile as much as possible.
- For raster data, request either GeoPackage or GeoTIFF
- For table data, request preferentially CSV (comma separated value)
- For styles, create or request preferably Styled Layer Descriptor (SLD) files.
- When date and time are included in either attributes or table data, request that these are preferentially expressed as ISO 8601 strings
- If coordinates do need to be expressed in tables, use preferentially decimal format over sexagesimal, for example 59.75 and not 59° 45′ (except in applications where the latter is preferred, of course).
Whenever you request or produce a dataset that will acquire some sort of official status, remember to document enough metadata (data about the data) so that others coming after you will be able to understand what these data are about and how to use them. Pay attention if you need to follow some official metadata profile for this. In any case:
- Always request or write a short (100 – 200 word) general description
- Always request or write a short (100 – 200 word) technical description
- Information context for the data set, if it is part of something else
- What do the attributes mean and in which units are data expressed?
- Which license and legal details of relevance for future use are required?
Think of everything you can think of importance for your map. Specify too much detail rather than too little!