Understanding point data - ODIQueensland/ocd-standards GitHub Wiki
Understanding point data 0.1
What is point data?
Point Data is information which can be represented by a single pin on a map. Often point data is more consumable than other types and a consistent understanding of its nature is possible.
Point Data is often physical facilities such as:
- Toilets
- Pools
- Skate parks
- Bicycle racks
- Drinking fountains
- Parks
- Playgrounds
Sometimes it may represent a process or capability which is provided from a facility such as:
- Services which offer discounts to seniors or carers
- Sporting clubs who are based at a sporting field
Point data is not:
- Walking trails (although heads of trails can be point data)
- Flood plans
- Park outlines
- Electoral boundaries
Such data sets are considered “Shape Data”.
There are a two significant ways in which point data can be used by consumers:
- Discovery: become informed about a location, often done in conjunction with a mapping tool
- Filter: Locate a facility or service which meets a specific need, often done in conjunction with a nominated geographic boundary
General recommendations:
Consistent treatment of point data greatly improves its usefulness. It is common that consumers of open data mash together multiple data sets, often from multiple providers, to produce something greater than the base sets themselves. The following field definition is provided as a standard for the structure and field names for data which are common to all point data sets. These fields are most useful for the Discovery of services.
Required fields
| Field | Example | Description |
|---|---|---|
lat |
-27.37345953 | The latitude of the point (EPSG:4326) |
lon |
153.02822570 | The longitude of the point (EPSG:4326) |
name |
Marchant Park | A short descriptive title of the item, commonly a short single sentence. It would ideally be unique within the data set. |
Recommended fields
| Field | Example | Description |
|---|---|---|
comment |
Open daylight hours | A more detailed description of the item. This may include multiple paragraphs of text and include information contained in other fields but written in a descriptive manner. |
address |
Ellison Road, Aspley, QLD, 4034 | The formatted street address of the item. |
type |
Unisex | The primary category of the item which is consistently applied across the data set. If additional similar data sets are published the category should be consistently applied across all of them. It is recommended the possible categories are included in the metadata associated with the data set. |
icon |
https://toiletmap.gov.au/images/icons/mfa.png  |
The web URL to a map icon which best represents the item. Recommended image sizes are 24x24px or 32x32px. |
link |
https://toiletmap.gov.au/Toilet/16151 | he web URL to directly access additional information about the item. This should not be a link to a generic web page. |
image |
https://toiletmap.gov.au/Toilet/ToiletPicture/028d760a-b2a7-47a3-a5f7-5b889d96a9dc |
The primary image of the item. |
Extending your data set:
In addition to the standard fields, many data sets can contain additional rich data which would greatly improve the usefulness of the information, in particular for Filtering the data set.
The inclusion of physical and/or audited aspects relating to the data set is usually possible with minimal effort. For example:
- Number of Dog Bowls (for a drinking fountain)
- Number of Racks (for a bike rack)
- Common Sports (played on the sporting field)
- Safe for Small Children (for a playground)
- Days and hours of operation
Ideally key elements of this information should be encapsulated within the description but separating out distinctive fields will better support detailed analysis and processes.
Almost all custom fields will require metadata to describe the purpose of the field and to define its use. As an example, a common attribute of point data is how accessible it is. Unfortunately, accessibility can be described in many ways:
- Is it wheelchair accessible?
- Is there a wheelchair accessible lift?
- What is the bus stop pad size and is it big enough for a wheelchair to turn around on?
- Is there assistance available to get into or out of the service?
- Are there facilities for the vision impaired?
If a custom field is included in a data set then the associated metadata should describe the possible values of the field and provide guidance in their interpretation. For example:
- 0: There are access issues which means a wheelchair may not be able to get onto the pad
- 1: The bus pad is small and not suitable for wheelchairs
- 2: The bus pad is medium sized and rated for manual wheelchairs
- 3: The bus pad is large enough for standard electric wheelchairs to navigate and turn 360 degrees
Wherever an open standard exists for the data point this should be used instead of custom values. If the open standard can be clearly inferred from the title of the field, then the reference to the standard is not strictly required within the metadata but it is highly recommended. Use of an open standard also mitigates risk when publishing the data as it is much less likely to be misinterpreted.