Windermere in the English Lake District, one of my test cases.

My earliest experiment using Ordnance Survey Open Data for the River Trent Voronoi triangles based on modes of polygon, clipped back to polygon

• Waterway flowlines. Replacing rivers mapped as areas by the central flowline where such a flowline has not already been mapped. Such data can then be used for navigation on river systems or for determining river basins (and ultimately watersheds/hydrographic basins). (It is this data which much of the rest of the post is concerned with).



Earlier experiments with OpenStreetMap glacier data for the Annapurna region Height (contours) & slope(shading) data via Viewfinderpanorams.com Voronoi triangulation clipped to glacier used to try & find flowlines for the main Annapurna Glacier. Some ideas originated from conversations with Gravitystorm. Map data (c) OpenStreetMap contributors 2014.

• Glaciers. Similarly for rivers although height also needs to be factored in. The idea is not just to identify flows on a glacier, but also simulate likely regions of higher speed flow with a view to creating an apparently more realistic cartographic depiction of the glacier. (Only apparent because in reality one needs lots of good aerial photography to correctly map ice-falls, major bergschrunds, crevasses, crevasse fields etc.).
  
• Creating Address Interpolation lines.  A small subset of residential highways have quite complex structures and therefore it is non-trivial to add parallel lines for address interpolation. Buffering the multilinestring of the highway centre lines & then resolving that to a single line would help. (More on this soon).
  
• Dual Carriageways. Pretty much the same issue as above except there is the additional problem of pairing up the two carriageways. Resolving them to a single way would make high-level routing and small scale cartography better (i.e., it's a cartographic generalisation technique).



The straight skeleton of Old Market Square Nottingham which allows routing across and close to most of the square The skeleton does not take account of some barriers on the square, but the hole at the left (a fountain shows the principle). Data source: (c) OpenStreetMap contributors 2015.



• Routing across areas for pedestrians. Pedestrian squares, parks car parks etc. Skeletonisation of such areas may offer a quick & dirty approach to this problem.

Identification of watersheds in Great Britain by contiguous sections of waterway in OpenStreetMap

Watersheds in Ireland derived from linear watercourses on OpenStreetMap. Waterways are generally less well-mapped in Ireland, but also several major waterways pass through large lakes (e.g., the Bann (Lough Neagh), Shannon (Lough Ree, Lough Derg), and the Erne (Upper & Lower Lough Erne)) and no centre line is available.

• Lakes, rivers mapped as areas etc also needed to be included in creating the elements of the watershed
• Actual watersheds can be created by creating Concave shells around their constituent line geometries. Unfortunately I get a PostGIS non-noded intersection error when trying this, so wont discuss it further (although if someone can walk me through how to avoid such problems I'm all ears). As later versions of PostGIS seem more robust I return to this later.

Six versions of Windermere showing area, media axis (red), straight skeleton (thinner lines) for different degrees of simplification (parameters of 0,5,25,125..). Original shape is shown as a blue outline.` All created as a single query using st_translate.

Straight Skeletons for Windermere calculated for different simplification parameters. The grey lines represent a parameter where details of islands are kept but the number of edges in the skeleton is greatly reduced.

Windermere showing inflow & outflow waterways

Detail of the centre of Windermere showing a reduced straight skeleton linked to inflowing streams (blue). The equivalent without reassembly and preserving stream topology is in red

• Do I get a valid geometry
• Number of interior rings
• A measure of surface area

Arts-and-Craft style semi-detacheed houses, Edwards Lane Estate, Nottingham

Another Addison Road, this one in Derby. Built, I would guess, under his great 1919 Housing Act. pic.twitter.com/CwAaroDUcF

— Municipal Dreams (@MunicipalDreams) July 22, 2017

Distribution of this particular building style across the city of Nottingham.

One of the earliest examples of the design. Perry Road, Sherwood Estate. Later examples (see below and above) either have hanging tiles covering  first floor at the front, or are not rendered at all.

Houses on Charnock Avenue, Wollaton Park Estate Only 4 pairs of houses of this type were built on this estate.

Side view of Charnock Avenue Houses.

Screengrab from F4 map. The S3DB rules for the two houses are slightly different.

Bulwell Hall Estate photographed from the South-west 1930. The semi-detached houses discussed in this post can be seen at the far end of the road in the foreground. Source: Britain from Above.

Aspley Estate from the S in 1931. Again the houses are most prominent in the corners of street intersections. Source: Britain from Above.

Sherwood Estates from the SW in 1928. The rendered houses shown above are in front of the school centre left. Source: Britain from Above.

Station Road, Awsworth. Note minor differences (absence of bay window, single window at side etc)

• building=semi-detached,
• building:architecture=arts_and_crafts,
• decade_built=1920,
• architect=* (if known),
• developer=* (or building:developer);

Clumber Street, a pedestrian shopping street in Nottingham

New York Subway line map from 1960s

An excerpt from the Tabula Peutingeriana

Bus stop showing typical public transport use of 1D maps

A 18th century road itinerary for Northumberland Jeffrey's Fleuron (perhaps also a strip map)

Why Now?

Outline of the technique.

• Merge all ways belonging to a particular road (identified by a common name and/or ref).
• Create a single centre line for the road (to eliminate spurs, dual carriageways, roundabouts, service roads etc).
• Identify all POIs belonging to a given street: this might be because they have the appropriate street name or are within a given distance of the street centre line (corner buildings, for instance may belong to another street, but be equally prominent on the intersecting one). 
• Locate the POI along the centre line, and, importantly, which side of the line it is located.
• Calculate distances along the centre line.

Step by Step guide

The Road Network & POIs

SELECT nextval('street_seq') street_id
     , name
     , st_multi(st_union(geom))  geom
  FROM hwy_upload
 GROUP BY name

Generating a Centre Line 1 : creating an approximate medial axis

• In many cases it cant be resolved to a line. 
• It's a multilinestring (I think even if the linear segments can be merged into a linestring).
• It appears that it is constructed of many 2-point lines.
• Some of the piecewise linear segments are minute (nanometres in length IIRC)
• There can be many short or very short stubs.

Generating a Centre Line 2: using pgrouting 

WITH st_pt_distance AS (
      SELECT street_id,
             a.pt_id source_pt_id, b.pt_id target_pt_id,
             a.pt_geom source_pt_geom, b.geom target_pt_geom,
             st_distance(a.pt_geom, b.pt_geom) distance
        FROM hwy_pts a, hwy_pts b
        WHERE a.street_id  = b.street_id
          AND a.pt_id <b.pt_id
           )
SELECT street_id,
FROM st_pt_distance
WHERE distance = (SELECT street_id, max(distance)
                    FROM st_pt_distance
                GROUP BY street_id)

Examples of buffered roads with rejected geometries (mostly in 2 or more parts). Some are correct others needed fixing

• Create the temporary routing table:
  CREATE temp_table AS
  SELECT a.street_id, (st_dump(aml_geom)).path street_seg_id,
         (st_dump(aml_geom)).geom as geom,
         st_length(st_dump(aml_geom)).geom) as cost,
         st_length(st_dump(aml_geom)).geom) as reverse_cost
    FROM hwy_upload
   WHERE a.street_id = <value>
• Prepare the table for pgrouting:
  SELECT pgr_createtopology('temp_table', 0.0000001,'geom');
  
  This routine creates another table temp_table_vertices which contains the nodes (vertices) of the routing network). Useful to remember when cleaning up the temporary tables. (I'm not sure why I used such a small value for the second parameter. I think I was worried about the very short segments which I later eliminated).
• Create a route. I used the standard pgr_dijkstra call which returns a list of all vertices and edges making up the route:
  
  SELECT *
  FROM pgr_dijkstra('select street_seg_id,
                     source,
                     target,
                     cost,
                     reverse_cost from temp_table',
                    (SELECT id FROM temp_table_vertices_pgr
                      WHERE geom = (SELECT start_pt from hwy_upload
                                     WHERE street_id =<value>)),
                    (SELECT id FROM temp_table_vertices_pgr
                      WHERE geom = (SELECT end_pt FROM hwy_upload
                                     WHERE street_id =<value>))
• In principle I should have been able to just use st_linemerge to assemble the parts of the route, but I found some small gaps which prevented the function from working. Instead I used the ordered set of nodes and made the line from them with st_makeline. This approach rather relies on the medial axis segments only having 2 points. (This may have been related to the short segments, but I haven't tried the original technique since then):
  
  SELECT st_makeline(pts) geom from (
      SELECT c.*
      FROM
          ((SELECT b.street_seg_id,seq,node,edge,agg_cost, geom,
                   st_pointn(b.geom,1) pts 
              FROM pgr_dijkstra(<see above>) a
              JOIN hwy_aml_dump b on edge=street_seg_id)
              ...

Adding the POIs

SELECT street_id, poi_id,
       st_linelocatepoint(
         st_pointn(
           st_shortestline(poi.geom,street.centreline_geom),
         2),
         centreline_geom)
       * st_length(centreline_geom) distance_along_street
  FROM streets street, pois poi
 WHERE street.street_id = poi.street_id

SELECT st_makeline( /* line from POI to 5 m across centre line) */
         geom,      /* POI location */
         st_translate(geom, /* xsect_geom is intersection point */
           sin(st_azimuth(geom, xsect_geom ) *
           (st_length(st_shortestline(geom,xsect_geom ))+5),

           cos(st_azimuth(geom, xsect_geom ) *          
           (st_length(st_shortestline(geom,xsect_geom ))+5))
  FROM pois

Pulling it together

Maid Marian Way in central Nottingham showing the calculated central line (orange) and short lines (red) from POIs. This is a topologically complex road.

Growth of shops mapped on OSM for selected Local Authorities (See Analysis section below for commentary)

Zurich, centre and Aussersihl districts, showing Areas of Interest. Work of Geometalab, derived from OpenStreetMap data.

Species Accumulation Curves

• Surveyors' skills. Not every surveyor has the same skill set, training, or even just visual acuity. One of the best naturalists I know is a care worker, who can trump national and international scientific authorities by finding more species than they can in the field.
• Seasonality. Plants flower at different times, birds migrate, some insects are on the wing for a short time.
• Weather. The hot dry weather in Britain has greatly reduced the number of flowers I have seen in the past few weeks, and consequently their insect visitors. On Sunday I was heartened to lead a field meeting where we found 44 species in our target group; but 10 years ago in the same location & at the same time of year we found nigh on 30 more.
• Predator Prey relationships. Many species numbers go in cycles (for instance Lemming years), but at least for some insects population density has been estimated to be an order of 10^12 between the troughs and the peaks. Ideally one surveys through 2-3 full cycles: problematic if they are 17-year cicadas, or bamboos which flower and die on a 70-year cycle.
• Increasing knowledge. Sharing of techniques for searching or recognising different plants and animals can have an amazing influence on total numbers of species found. This is true even in Britain for as well studied a group as the higher plants. The BSBI's Atlas 2020 project which will be completed in 3 years time, will not only show changes in plant distribution brought about by agricultural intensification, increased urbanisation and climate change, but also changes from looking more closely for a wider range of plants (notably urban weeds and garden escapes).
• Sheer cussedness. Fungi are particularly awkward customers. Most spend their time invisibly underground, only showing fleetingly as fruiting bodies (mushrooms) when they feel the time and weather is right. Even with the most capable surveyors in the world the full extent of species complexity can only be appreciated by continual regular surveying of the same place. There are two locations in England which demonstrate this point. Esher Commons have been regularly surveyed for fungi by scientists, including global authorities on some fungal groups,  from Kew Gardens for many years. No other place in the world is know to have as many fungi, and around 20% of all fungi known in the British Isles have been found at Esher. Slapton Ley in Devon has also received decades of regular surveying effort for fungi, and has over 2000 known fungi species. It may be come second to Esher for known fungal diversity!
• Recorder effects. Even for professional scientists it is often difficult to maintain a constant recording effort. Most biological data is gathered by citizen scientists who can only devote what leisure time they can spare for the activity. Recorders tend to be located in larger cities, rather than in potentially highly species diverse remote areas. For many species groups only a few people are seriously dedicated (as in my own interest in Plant Galls).

Differences between OpenStreetMap & Biological Record Data

• of individual shops;
• of shop tags.

Null Hypothesis

Typical small shops which get mapped piecemeal on OSM: near Conde de Casal Metro station Av. Mediterraneo, Madrid, Nov. 2016

Extracting OSM History data

Wrangling the Data

Analysis

Shops by Local Authority

Progress in shop mapping for all Local Authorities in Britain (the top lines with over 2000 shops are : Birmingham, Bristol, Edinburgh, Leeds, Nottingham and London Borough of Westminster)

Percentage of shops mapped at June 2017 in prior months, all Local Authorities Great Britain.

Local Authorities with more than 2000 shops mapped mid-2017

• Birmingham, 2015: Mattijs Melissen (Math1985) was a very active shop mapper at this time. The tailing off subsequently may merely because he returned to The Netherlands on completing his post doc.
• Edinburgh, 2014. The Edinburgh MESH (social history) project were actively mapping the inner city during this period.
• Nottingham, 2013. My own deliberate attempt to map most shops from around March to June 2013.

Shops by Tag

• What do the graphs of numbers of unique shop tags look like with heavier filtering of relatively poorly used tags.
• E-cigarette shops are a recent phenomenon, and should represent a genuinely novel tag rather than the mix of typos, synonyms etc which characterise much of the long tail of shop tags.

Unique shop tags over time on OpenStreetMap for Great Britain, filtered to remove tags with a restricted number of uses as at June 2017.

Growth of mapped e-cigarette shops in GB on OSM

• Often the real-world situation we try and capture on OpenStreetMap is inherently complex.
• Depiction of the rules in a more formal model, such as a class diagram, helps in codifing that complexity. In turn it also introduces additional complexities in the form of abstruse terminology, and the requirement of very specific skills and knowledge for the information to be useful.
• Codifying everything held in OSM is a huge task. This is one tiny corner (access restrictions) of one area (highways)  in one country (Japan), that gets added to OSM.

Serlby Close, Usworth. The houses on the left are part of Coach Road Estate Source: © Alex McGregor at GeographCC-BY-SA-2.0

• Food Hygiene: a single convenience store is present.
• Naptan: bus stops on the estate all use the name, and conveniently often include the nearest house number.
• National Register of Social Housing. Although this stopped being maintained in 2011 it is still invaluable not just for addresses, but also to identify planned estates of social housing (council estates, colliery villages etc).  There are hundreds of addresses ranging from 1 to 589 in this dataset (there are 648 records in total, but this includes a lot of garages). As they have postcodes they can also be geolocated.
• Companies House: five companies are registered at four addresses on the estate.

Screenshot from Will Philips OSM-Nottingham website showing geolocated OpenData with "Coach Road Estate" in the address, name or other field. Unfortunately, I failed to screenshot this before mapping the area in detail. (Although the site is focused on the Nottingham area it now allows searches on most UK open data useful to OSM).

Prefabs in Sulvgrave Village (presumably those at Usworth Green). The terrace behind is probably Pensher View Photo from Tyne & Wear Archives and Museums  via Flickr. Crown Copyright. More details on their Flickr page.

Masterplan of Washington New Town from JR James Archive on Flickr (CC-BY-NA-2.0). Coach Road Estate is in the northernmost block of residential landuse zoning.

Coach & Horses, Usworth in 2010 (now closed) Source: © Alex McGregor at GeographCC-BY-SA-2.0

• Elements can start their existence with a deleted status. Node #1 is the best example of which I'm aware. Here is the OSM Change XML (.osc) from that deletion:

<osmChange version="0.6" generator="CGImap 0.6.1 (1966 thorn-01.openstreetmap.org)" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/">
<create>
<node id="1" visible="false" version="1" changeset="9257" timestamp="2006-05-10T18:27:47Z" user="τ12" uid="1298"/>
</create></osmChange>

No idea how this came about.

• Ways can have nodes which come into existence later than the way itself. Way #180 was created by Deanna Early in June 2006:
  
  

  <way id="180" visible="true" version="1" changeset="34555" timestamp="2006-06-04T00:35:25Z" user="Deanna Earley" uid="2231">
  <nd ref="635109"/>
  <nd ref="15433291"/>
  <nd ref="635110"/>
  <nd ref="15433288"/>
  <nd ref="15433290"/>
  <nd ref="635111"/>
  <tag k="highway" v="residential"/><tag k="name" v="Green Lane"/></way> But some of the nodes only appear to have been created rather later, like this one in September 2006:
  

  <node id="635109" visible="true" version="1" changeset="109674" timestamp="2006-09-13T00:37:15Z" user="Deanna Earley" uid="2231" lat="50.8889009" lon="-1.3269173"/>
  <node id="635109" visible="true" version="2" changeset="6669766" timestamp="2010-12-15T17:48:55Z" user="0123456789" uid="55782" lat="50.8888938" lon="-1.3270150"/>

  Again I don't know why.

• The opposite is true, nodes can be deleted whilst they still remain in the list of way nodes. Here'a a road in Thurso, way #4839614

  <way id="4839614" visible="true" version="1" changeset="122653" timestamp="2007-07-02T11:09:11Z" user="rjmunro" uid="729">
  <nd ref="31140984"/>
  <nd ref="31140986"/>
  <nd ref="31140987"/>
  <nd ref="31140988"/>
  <nd ref="31140991"/>
  <nd ref="31140992"/>
  <nd ref="31140994"/>
  <nd ref="31140996"/>
  <nd ref="31140997"/>
  <nd ref="31140999"/>
  <tag k="created_by" v="Tways 0.2"/>
  <tag k="highway" v="unclassified"/>
  </way>
  <way id="4839614" visible="true" version="14" changeset="52740714" timestamp="2017-10-08T19:56:51Z" user="woodpeck_repair" uid="145231">
  <nd ref="31140984"/>
  <nd ref="31140986"/>
  <nd ref="31140987"/>
  <nd ref="31140988"/>
  <nd ref="766071173"/>
  <nd ref="31140991"/>
  <nd ref="2344890723"/>
  <nd ref="2347341994"/>
  <nd ref="31140992"/>
  <nd ref="766073124"/>
  <nd ref="31140994"/>
  <nd ref="766071341"/>
  <nd ref="31140996"/>
  <nd ref="538050262"/>
  <nd ref="538049944"/>
  <nd ref="2409031255"/>
  <nd ref="31140997"/>
  <nd ref="538049236"/>
  <tag k="highway" v="unclassified"/>
  <tag k="ref" v="U4135"/>
  <tag k="source:ref" v="official"/>
  <tag k="source_ref:ref" v="http://www.highland.gov.uk/download/downloads/id/11641/list_of_adopted_roads_-_u_class"/>
  </way>

  Node #31140999 was deleted by user Ollie in 2010:
  
  <node id="31140999" visible="true" version="1" changeset="121208" timestamp="2007-07-01T18:51:46Z" user="rjmunro" uid="729" lat="58.5975437" lon="-3.5137181"><tag k="created_by" v="JOSM"/></node><node id="31140999" visible="false" version="2" changeset="4923978" timestamp="2010-06-06T23:45:04Z" user="Ollie" uid="10785"><tag k="created_by" v="JOSM"/></node>
  
  In this case it's clear what has happened. All versions of the way from 2 to 13 needed to be redacted, and redaction cannot hope to restore all changes completely.
  

• A logical corollary of redactions is that version numbers are not guaranteed to be sequential, whilst they do always increase monotonically, . This is particularly important if you use SQL window functions. I've found it useful to have an element sequence number which is sequential.
  
• Element versions can share the same time stamp. OSM XML only stores timestamps on objects to the nearest second. Whereas it must be possible to adjust the position of a node several times in one second, it's harder to see how these can be saved to the API so quickly. One case where this might work is where work is saved, and whilst the data is being uploaded some fault is noted, corrected and immediately saved. Another possibility, which I haven't investigated is in the mechanisms by which editors & the API generate timestamps. Effectively I havent worried about this and have 'thrown away' the earlier elements sharing the timestamp, but it does mean that you can't rely on date order alone to correctly sequence element history.
  
  Simon Poole asked me for an example, so here is one, node #107298, versions 2 through 4 all have the same timestamp:
  
  

  <node id="107298" visible="true" version="1" changeset="66" timestamp="2005-06-05T18:31:25Z" user="zool" uid="131" lat="51.5496368" lon="0.0051554"/><node id="107298" visible="false" version="2" changeset="415456" timestamp="2007-11-05T22:02:42Z" user="Paul Todd" uid="12503"/><node id="107298" visible="false" version="3" changeset="415456" timestamp="2007-11-05T22:02:42Z" user="Paul Todd" uid="12503"/><node id="107298" visible="true" version="4" changeset="415456" timestamp="2007-11-05T22:02:42Z" user="Paul Todd" uid="12503" lat="51.5496390" lon="0.0051490"><tag k="created_by" v="Potlatch 0.4c"/></node>
  

  This was back in the early days of Potlatch when edit changes went live immediately on the API database. This 'live mode' of Potlatch prior to Potlatch 1.0 may explain the existence of most of these very transient versions.

• History files for an area may contain data outside that area. I've used Geofabrik's history files (now requiring an OSM logon) for Great Britain, but they contain all versions of node #1. It spent some of it's existence in Argentina. I suspect the same is true if one creates files using Osmium. Mainly this is because one needs the history including when a node is deleted which lacks any geographical information. As far as I know it adds little overhead.

• Element history in OSM full planets is not complete (at least for early stages of the project).
• There can be gaps in the sequence of OSM element version numbers (usually caused by redactions).
• Redactions may affect the integrity of the relationships of geometries.
• Time granularity is not enough to separate all object versions.
• History files do not cleanly contain only data from the relevant area.

Revisions:

H34 West Donegal: Vice County raster map suitable for MapMate Source data: (c) OpenStreetMap contributors; hill shading NASA SRTM via viewfinderpanoramas.com

First MapMate test picture map for County Down Data: (c) OpenStreetMap contributors

Hillshading

Collins Progressive Atlas page 12 : my introduction to hill-shading, contours & hypsometric tints. I was about 6 years & 4 months of age.

MapMate's Co-ordinate system

Using QGIS I created raster images with both Irish (grey-brown) and British (blue) grids.

100 km sq. British Grid (from NW05 to NR49)

100km Irish Grid sqaure C. British Gird in blue.

Coda

Roof mounted solar PV panels on a semi-detached house. There are 18 panel modules (in 2 rows of 7 and one of 4). Each module consists of a 12 by 6 array of solar cells (see below for further discussion). Photo by Phil Sangwell on Flickr via Wikimedia Commons. CC-BY-SA

How crazy would it be for national electricity grids to use @OpenStreetMap as *the* authoritative database of all solar photovoltaic systems?@mclduk@alex_rogers_cs@dekstop@EnergySRE

— jack_kelly (@jack_kelly) March 6, 2019

Housing in the Aspley Estate: note the solar PV panel on house in background (this one on OSM).

Solar Panels on new-build replacement housing at Rutland Close, The Meadows. A recent example of housing I've surveyed without paying particular attention to solar.

Solar PV panels mapped in Nottingham, via Overpass Turbo

• All available imagery layers need to be searched. New installations are occurring all the time and it's unlikely that the better quality imagery layers will be recent enough to enable adequate coverage.
• Newer imagery, such as the Digital Globe layers can be quite grainy & hard to interpret. However once panels have been spotted it is usually possible to then find many more.
• The huge variability in available imagery is likely to make any attempt to use machine learning to identify targets is likely to be fraught. I would also expect things like glass roofed extensions would generate many false positives.
• Knowing where panels are likely to be installed helps a great deal: both at the neighbourhood and building level. Christian Quest's OpenSolarMap used some crowd-sourced information from aerial photos to train  system to identify buildings in France with potential for installation of photovoltaic panels. Such information for the UK could reduce the total number of buildings needing to be inspected.
• Larger detached houses with solar panels are very difficult (impossible?) to pick out from aerial imagery. Shadows from chimneys, and changing roof lines obscure the presence of the panels.
• Mapping panels as nodes is the best approach initially. I used ID which has a suitable preset (and checked what others had already done, for instance brianboru around Birmingham). Thereafter I just copied the original node.
• Adding a tag to show that they are roof-mounted is useful (particularly if the building has not been mapped yet). I've used generator:location=roof. Indicating domestic use might also be helpful. The basic tags I used are also used for complete solar farm installations & clearly it is important to distinguish them. (I've subsequently learnt that generator:place=roof is the established tag).
• Many installations are sufficiently clear on aerial imagery to allow estimation of the number of panel modules involved. Virtually all the ones at Aspley are 2 rows of 5 modules. Unfortunately I don't know the exact module size, but they are probably 10 or 12 by 6 cells. Tagging the module array explicitly is probably better than guesstimating the area (as I have done).
• If module size is known (see top photo) the array area can be calculated directly. Each solar cell is likely to be 156 mm square, so a 10 by 6 array will be 1.56 x 0.96 m (1.46 sq m).
• Cell size, module size and number of modules allow optimal power rating to be estimated. I think these arrays of roughly 15 sq m are around 3500-3700 W.
• Adding compass orientation of the array in degrees, and angle from the horizontal would also be helpful for using the data for estimating likely power output. (Both could be derived from simple 3D building tags, but adding these is much more complex).
• The last few items (no. of modules, module size, area, power rating, orientation & angle) represent data which can be added iteratively.
• It's worthwhile surveying at least some of those added from aerial imagery to capture other information.
• Even if the panel is mapped as an area, most of these tags are still useful as it is unlikely that enough information will be present on the underlying buildings to derive them.
• Surprisingly few public buildings, education establishments or industrial buildings have solar panel installations. I've only noticed a few on buildings of Derby Hall, a hall of residence at the University of Nottingham, and a couple of warehouses in Bulwell.

• solar panel distribution is likely to be very patchy; 
• aerial imagery may not be good enough to pick out panels, or recent enough (many of the Nottingham panels have been installed since 2014). 

Aspley Estate (Bing Imagery), roughly here.

Aspley Estate (Bing Imagery) roughly here.

Aspley Estate (Digital Globe Standard Imagery) location as above

Aspley Estate (Digital Globe Premium and ESRI World Imagery) location as above

Broxtowe Lane (Bing Imagery), about here.

Broxtowe Lane (Digital Globe Premium Imagery), same location as above. Obviously newer as a solar panel can be made out on the terrace in the centre. Note on the next terrace down a dark area on the roof. This does not appear to have the same visual appearance as other solar panels, so may be a solar hot water system.

Broxtowe Lane, as above (Digital Globe Standard imagery)

Deptford Crescent area, Highbury Vale (Bing imagery). Area bottom right is Highbury Hospital. No solar panels visible

Deptford Crescent (ESRI World Imagery)

Deptford Crescent (Digital Globe Standard Imagery)

Astrid Gardens, Bestwood Estate (ESRI Imagery). Just occasionally panels have very strong reflections as here.

Astrid Gardens, Bestwood Estate (Digital Globe Standard Imagery).

Astrid Gardens, Bestwood Estate (Bing Imagery).

Bilborough Estate (Digital Globe Standard Imagery) Note the panel lower right which is pretty hard to pick out.

Britten Road, Basingstoke (Hampshire false-colour Infra-red imagery) This estate has quite a few solar hot water installations but only a few solar PV. The hot water ones are smaller and less obviously modular.

Britten Road, Basingstoke (Hampshire visible spectrum RGB imagery)

A likely Addison Street candidate, Cefn Fforest, Blackwood cc-by-sa/2.0 - © Jaggery - geograph.org.uk/p/2

Merseyside, NW Cheshire & SW Lancs, showing areas of social housing. These are concave hull polygons derived from clusters of NROSH postcodes.

Clustering NROSH Data

SELECT row_number() over () AS id,
  ST_NumGeometries(gc),
  gc AS geom_collection,
  ST_Centroid(gc) AS centroid,
  ST_MinimumBoundingCircle(gc) AS circle,
  sqrt(ST_Area(ST_MinimumBoundingCircle(gc)) / pi()) AS radius
FROM (
  SELECT unnest(ST_ClusterWithin(geom, 100)) gc
  FROM nrosh_pc_geo
) f

Odd-shaped polygons for Irby on the Wirral. Individual postcodes only have a few NROSH entries. Presumably both roads around the school were built as council housing, but most have now become privately owned.

One of the more uunusal social housing forms, Stoford cc-by-sa/2.0 - © Nigel Mykura - geograph.org.uk/p/4314325

Overview of the Resultant Data

Hampton, Hanworth & Teddington area of SW London. In general this is a pretty prosperous part of London. It does pick out some areas of social housing (e.g., near Apex Corner (A312/A junction), but the notion that most of Teddington is social housing is absurd. The 2015 Index of Multiple Deprivation gives a better picture of this area. See additional notes at the foot of the blog.

NW1 postcode. 150 m clusters with 100 m clusters overlaid. Reducing the cluster distance to 100 m greatly improves the elimination of false positives. Places like the Ossulston Estate between Euston & the British Library show clearly. I'm less convinced that this does not result in many false negatives

• Sheffield & Redditch seem to be data deficient.
• Areas in London are far too large to be usable, and even reducing the clustering distance does not make a massive difference (see images & commentary in the captions above).

Further Notes on Hanworth, Hampton & Teddington

Two terraces of housing off the Holyhead Road (former A5) in Llanfair PG. Penucheldre and (to the right Britannia) Terrrace. A typical type of housing throughout Wales, they provoke some addressing conundrums.

 Terraces in Llanfair PG

Looking towards the main road (Ffordd Caergybi or Holyhead Road). Two terraces are visible: one on the L angled at around 60 degrees to the street, and the one on the right, Williams Terrace (I think) facing onto the street. There is another terrace behind Williams Terrace, and two more off the main road on the right.

Modern day Llanfair PG shown on Bing Imagery. buildings identified as terraces are from OpenStreetMap and are shown in orange with a halo (to aid visibility).

Memorial to villagers of Llanfair PG who lost their lives in the First World War. There is much of historical interest here, and personal one for me as my Grandmother's cousin is one of those listed, but it is the addresses which are germane to this post.

• Crossing Terrace. next to the railway line and a named residential road today.
• Williams Terrace : off Ffordd Penymynnydd and behind Britannia Terrace.
• Bryn Goleu. Somewhere in Pentre-Uchaf, perhaps this building.
• Britannia Terrace. Fronting on to the Holyhead Road.
• Penucheldre Terrace. At right-angles to Holyhead Road and immediately to the W of Britannia Terrace.
• Min-y-ffrwd. Behind the Calvinist Methodist Chapel (and marked on the 6 inch map

E end of Stryd Fawr (High Street) in Brynsiencyn. Two terraces can be seen in the middle distance on the right-hand side. Almost all the houses on this street date from late-1800s.

Terraces elsewhere in North Wales

Highways with "Terrace" in their name within Wales on OpenStreetMap We can be confident that many have been missed as much of the detail mapping of Wales has used Ordnance Survey resources (either Out-of-copyright or Open Data)

Terraces Further Afield

A small terrace at Foxt, Staffordshire. Unusual in that one house was a pub. Ian Calderwood on Geograph via Wikimedia Commons, CC-BY-SA.

The Addressing Problem

1. Those where the terrace name has been transferred to a standard residential road.
2. Those where some distinct vehicle access is provided, for instance by an unsigned service road.
3. Those accessed solely by a footway
4. Those fronting onto a street which has a different name from the terrace, and house numbering is only continuous in the terrace.

• Store the name of the terrace in addr:housename and the name of the road in addr:street. (This is actually what Royal Mail do in their address file). 
• Add the name of the terrace as addr:street and make the houses members of an associatedStreet relation for the road.

The Mapping Problem

After a hiatus of a year I held an on-line meeting for East Midland mappers back in March, with another in April. March was an important anniversary as we held our first meeting in March 2011, so it was the group's 10th anniversary. This is a little bit about recent meetings, but mainly a chance to share what works for us in the hope it may help others contemplating trying to get a local group together.

2021 Meetings

Somewhat daringly we agreed to meet in person in May, albeit with a number of changes designed to mitigate risk from covid: a quiet location, an afternoon meeting time, location reachable quickly by public transport by participants, possibility of being outdoors. Fortunately the venue we use in Derby, The Brunswick, meets all these criteria. 

I was a little shocked on viewing OSMCal that we were in the vanguard of OSM local meetings returning to in-person gatherings. My appetite for risk is perhaps higher than I thought, given that I have spend much of the past 15 months shielding as a CEV (clinically-extremely vulnerable) person. Even by May I had only made 1 shopping trip into the city centre, and had not been on public transport or visited a supermarket since March 2020. This was also my first meeting with friends rather than family or neighbours.

It all felt remarkably normal. The pub was quiet, service discrete and speedy. Despite my initial misgivings I felt comfortable indoors (it was pretty cold at the end of May & I was wearing winter-levels of clothing). I think it helps that all of us have been vaccinated, most with 2 doses, and, as discussed below, as a group most of us have a low number of day-to-day contacts. In fact I felt able to take my father there a week later for his birthday.

I can't remember exactly which subject we touched on in May, but topics we have talked about this year:

• Locked gates. This was a particular desire of John Stanworth who has been mapping them fairly systematically around Sheffield. SomeoneElse now shows them on his hiking map style for the UK & Ireland (see changelog entry for March 29).
  

• Static railway carriages mapped as building=railway_carriage

• Trackless walking & hiking routes. These are very common in Scotland where very well known ways up mountains have very few traces on the ground, and even when they exist they are often hard to tell from paths made by deer or sheep. Although walkers will not follow exactly the same route, they are relatively easy to verify from experience and knowledge. Often a path does appear high-up the hill as route options coalesce. This is an example from my own surveying in North Wales. Similar issues occur for backcountry skiing, alpine and ski mountaineering routes and bushwhacking in the Adirondacks. I've never found a tagging combination which meets this need, other than using a highway tag seems wrong, and potentially dangerous. (An side aspect are parts of regular trails which are for practical purposes invisible, and therefore should probably not be mapped as highway=path or highway=footway).
  
  
• Simple 3D buildings and F4map. Paul the Archivist has explained his approach in a diary entry.
  
  
• Gate types. I learnt something reading the wiki, in that wicket gates originally referred to small gates in larger doors or gates. Despite having passed through one many times a day for 3 years I never heard it referred to by that term, and in general my image is much more related to a gate which looks like part of a wicket fence (presumably influenced by cricket wickets). There are numerous tags which are duplicated across barrier and gate[_:]type: bump gate, kissing gate, lych gate etc. From a walker's perspective often the most important thing is whether the gate is meant for pedestrians or vehicles.
  
  
• Electric Vehicle chargers. Rovastar gave a detailed breakdown of the complexity of mapping electric vehicle chargers, and how it will also be problematic to show the data once they become ubiquitous. I'm hoping he might write this up as a diary entry: he's thought about the issues in depth.
  

Whether we meet next month really depends on the state of the Covid pandemic. Current doubling times make me pessimistic.

East Midlands Local Group 

After 10 years it's worth taking stock of where we are, mainly because there may be things of value for other local group organisers. Some of these notes were written originally for Kyle Pullicino, who asked for information on the talk mailing list, although they were always written with this purpose in mind.

I co-organised the original Nottingham OSM get-together nearly 10 years ago, and I have more-or-less organised, or, perhaps better, facilitated, these activities ever since.

This is a long post as I'm taking the opportunity to provide some detailed thoughts on these 10 years. First, I describe our group, what we do & things I've thought of doing. Second, I try & make some concrete recommendations. 

We meet regularly (or did until Covid-19) once a month. We get anywhere from 3-8 people on a regular basis with a regular core of 5-6. We have a number of very active mappers (at one stage 3-4 in top 100 worldwide), and people active in the wider OSM community (OSM-Carto, weeklyOSM, DWG, SotM volunteers, etc.). A couple of members run or are major contributors to OSM-related websites or resources (OSM-Nottingham, Evesham Mapped and switch2osm.org). We have a steady, but small, number of people who pop-in to ask specific questions or just to meet people, these might be mappers, developers or academics.

Location

Our meetings are held in a pub, partly because OSM in the UK features a lot of folk who like pubs, but also for mundane practical reasons. People who work can't meet in the day time, relatively few coffee places are open later in the evening, it's free (except for drinks & in a larger group one can join without having to buy a drink & most pubs do a good range of non-alcoholic drinks these days), relatively easy to find a central location. From my point of view, if no-one turns up I can still sit quietly with a drink for a while, and I'm not risking a not insignificant part of my monthly income on venue hire. I also try & choose one which has some food options (some people may come straight from work) & caters for a range of dietary choices (gluten free & vegetarian I always check). In London suitable adjacent fast-food options are more common, but this breaks up the meeting as people leave to buy food.

For location we chose somewhere central convenient for public transport (within 10 minutes walk of different options). This has been very useful as we now get people coming from further afield. For the past few years we've used other towns as well & this brings in different people.

Time & Date

For personal reasons weekend meetings were not possible for me: I do other things at weekends, caring responsibilities etc.. I suspect the same is true of most of our other attendees too. I do organise an Saturday meeting once or twice a year with the objective of mapping footpaths, where we share lunch together. The Norwich group have been successful with a Saturday morning meeting, followed by coffee or lunch.

I think it's generally true that people who map in OpenStreetMap may have a lot of other shared interests. Many of our group are keen walkers, cyclists, followers of folk music, owners of allotments, real ale enthusiasts, interested in historic buildings and so on. These shared interests do help a group to gel, but perhaps make it harder for newcomers to feel included. 

Who we are

We are, for the most part, men with an IT/STEM background over 40 with perhaps more over 60 than under. The age range is not untypical of the OSM mappers in the UK, but in other countries typical contributors may be younger (France, Germany, Spain, much of Latin America to my knowledge). Our youngest member, turned 30 last year. She is a professional geographer, coming to our first meeting when she was a student, but pretty much shares the interests I list above. Our oldest members are in their late '60s or early '70s. 

Also, fairly typically for OSM, the vast majority of us have degrees with perhaps half having a masters or doctorate. A very high proportion either run their own business or work for small companies, and quite a few of us are retired. Many worked from home long before the Covid pandemic. This may reflect the STEM-bias found across the board in OSM contributors, but may also represent a pattern of working which is more compatible with contributing to OSM.

From a personal viewpoint this has all been very rewarding, these people are good friends (in fact the monthly OSM meeting has become my most regular social gathering, because other ones fell by the wayside when people's caring responsibilities, including my own, grew too much. I think this also sustains the group. 

I should add that a perhaps under-appreciated aspect of the group is how many have had some caring responsibilities: largely for elderly parents, but also grandchildren and one diabetic cat. Another related factor is that in the 10-year time-frame about half of us have lost one parent; and shockingly we lost a member, David Evans, when he was in his early 40s. This means some useful conversations have been about night-sitting care-workers or getting probate. The downside is, as I say, it may be harder for newcomers to feel able to join or contribute to: a) an existing group with its own dynamic; or b) a group which is different from oneself. I have no good answers to these issues, but perhaps having different forms of meeting may attract different groups.

Mapping Activities

During the Summer months (April-October) we provide for an hour of mapping activity before meeting (largely determined by how long I can make available beforehand). At the outset we did this together as it was a vehicle for explaining OSM to people. More recently we meet & go off & do our own thing, although I am always available to show someone the ropes if a newcomer turns up. Our pub locations are deliberately chosen to maximise the range of different urban landscapes within a short distance. For the past few years we have concentrated on updating shops in the city centre (which is not just good for explaining OSM to people, but also fits with a constrained mapping time, and for exploring what continuous maintenance of data entails). This is a good opportunity to show different editors (GoMap, Vespucci, Street Complete etc).

What we talk about

Once in the pub we probably focus the first 45-60 minutes to discussing mapping problems: particularly as we have someone who comes with a long list of such questions (see above for this month's issues). General gossip about events in the broader OSM community may also happen. After that our discussions become much more social. The format works well for someone wanting some specific answers as they can leave after the first hour. 

Alternative types of Events

Things I haven't done, which might be worth considering:

• Formal talks (like Geomob in London), this could work well, but requires a suitable space, speakers & much more preparation. Other tech groups such as Linux User Groups use this approach.
• Half or one day workshops. Again more work (& possibly more than one person). Topics from mapping through to configuring a render server or using QGIS
• Missing Maps sessions or similar humanitarian mapping. These sessions appear to be very popular and can be held in small or large settings. They attract a different group of people (in London, more young people, more women & more GIS professionals). On the other hand I think there is a poor transference from mapping for humanitarian purposes to mapping locally (not so true the other way), so it might not build a local mapping community
• Interacting with local student groups. I've done a bit, but have meant to do more.
• Linking up with other like-minded orgs: Wikimedia, tech user groups etc.

One thing I would caution is that creating a group may not actually increase the number of mappers you have. We are pretty much the same set of active mappers as 10 years ago, although we have acquired one new active mapper in the past 3 years.

Starting out: recommendations for a local group

This is very much based on what I did. No doubt there are other ways of doing it.

• Decide on an initial meeting format, location & time well in advance. In the current circumstances that may well be a Zoom online meeting or similar. You need to use your judgement (& personal circumstances) to choose these. You may want to consider if these are suitable for a repeating event, as it's much easier to schedule follow-ups on that basis.

• Contact as many active mappers as you can (via OSM messaging, email). Contact local interest groups: walkers, cyclists, tech, wikimedia etc). You can canvas people for themes at this point which can set a structure for the meeting.

• Once you have basic interest & a time & place for a meeting, advertise it more widely (OSM mail, twitter, facebook .....). It's difficult to underestimate just how many different communication methods are used by those interested in OSM. Add it to OSMCal and then it will be included in weeklyOSM. Write an OSM Diary entry (& then we can write a news item about it in weeklyOSM).
• Have the meeting! Importantly, check at the end if people want to do it again, what frequency they feel is suitable (monthly, every 6 weeks & quarterly are good choices) & what things they would like to do (social/mapping etc).
• Write up what you did. I did this for the first few meetings, but it can me more of a burden later on.
• If all goes well, schedule meetings for the rest of the calendar year. It makes organising easier & helps diary management; and also helps attendees.

Personal Motivation

Lastly, think a bit about your own goals of trying to organise the community. I know we have woefully failed at my original one to get 10 highly active mappers in the city of Nottingham, on the other hand we do provide a continuous point-of-contact for local people to find out about OSM. Getting to know each other, what we are interested in, what & how we map have been immensely beneficial in terms of creating a more communal approach to mapping. It's often much easier to discuss how to map something face-to-face than by email & even better if you stand in front of it.

Whatever you do, only take on that which you feel comfortable with. It's quite a lot of work (at least initially) and there are lots of things it would be nice to do if one had the time, skills etc. OSM is built on 'good enough' not being perfect. Ideally, you might find people with complementary skills who might be interested in doing some of the other things.

People do run out of steam doing these things, and its worth recognising it. The one thing I did find extremely demotivating was the "Craftmappers" post by Michal Migurski back in 2016. For a few days I felt like throwing in the towel, and leaving the group to its own devices. I think for many of us it is important to avoid much of the mud-slinging which purports to be discussion in many OSM channels (for this reason I do not subscribe to many mailing lists), and focus on what works for us at a local level. 

Local groups are not so common that they do not need a little bit of nurturing. I'd like the OSM Foundation and local chapters to consider this more seriously.

The reporting and discussion of a mountain rescue on the the minor Lakeland peak of Barf continues to generate a mass of things to investigate and follow-up. I've already written two OSM diary entries on assigning slope angle to paths because of it: here and here.

To recap, recently the Keswick Mountain Rescue were called out to help 3 people who were stuck ("cragfast") on steep ground on Barf. They didn't feel confident to retrace their steps back down very steep (30 degrees or over) scree and had reached a small crag with no obvious visible route through it. They had been using one of the mobile phone outdoor hiking apps which uses OpenStreetMap data for suggesting walks.

The event was reported in the national press (The Guardian) and, of most relevance, by a specialist magazine, The Great Outdoors. The latter did a great job of thoroughly researching a news article, getting comments from the OpenStreetMap Foundation. Their specialist advisor Alex Roddie decided to publish the content of his initial response to Carey Davies, the author of the article. Both articles are well worth reading for an in-depth initial response to the situation and the issues arising. There have also been lively exchanges both on Twitter and Mastodon, again containing useful comments from people with a lot of experience of the outdoor scene in the UK.

I won't comment here on the whys and wherefores of what kinds of paths and hiking routes should get mapped on OSM. The subject is complicated enough in Great Britain as all this discussion shows. One of the side distractions this did prompt for me was looking at how we could show contour data for OSM in the British Isles (and specifically on Andy Townsend's rural hiking map).

A toot by Nigel Parish did highlight that typically maps based on OpenStreetMap have contours which are greatly smoothed compared with the actual terrain. His example was from Andy Allan's Thunderforest Outdoor style which is incorporated into a number of hiking apps. Like most regular OSM contributors, I'm used to OSM-based maps using SRTM data to create contours: both because it's free and because it has more-or-less worldwide coverage. However, we are also aware of the deficiencies of this data: it has a relatively low resolution of around 1 second of arc (so roughly 30 metres resolution) which smooths contour lines and hillshade overlays.

I had recently downloaded the Ordnance Survey's own open data elevation model Terrain50, which I used for the first of my diary entries. This has a grid interval of 50 m, so although undoubtedly more accurate than SRTM, it is of somewhat lower resolution. I therefore expected contours generated from the DTM to be comparable with those of SRTM.

I'd forgotten that I'd used the vector dataset, so my first step was to generate contours from the raster tiles provided by Terrain50.

Barf with contours derived from the raster DTM of Terrain50.

After I'd done this, I remembered that the Geopackage was easy to use, so I added that. To my surprise the contours had rather more detail than those derived from ostensibly the same dataset.

With contours from Terrain50 vector data

Lastly, I created 10 m contours from the 1m Lidar data available from the Environment Agency for NW22NW. This, as expected shown both high resolution and accuracy.

With 10m contours derived from Environment Agency 1m Lidar.

To compare the three types of 10 m contours I changed colours and their background. Here are all three at a scale of 1:1000 on the steep SW slope of Barf between the Bishop of Barf and the crag which balks some walkers. In the image below it can be seen that the vector Terrain50 data is of much higher resolution than the raster data from the same source. In most places vector Terrain50 data is much closer in alignment with the contours derived from 1m Lidar data. As Nigel pointed out the more detailed contours give a significantly different impression of the shape of the hillside.

All three types of contours shown together. Red derived from OS Terrain50 raster; Orange: OS Terrain50 vector; and Green derived from Environment Agency 1m Lidar DTM. Scale 1:1000.

Nigel also pointed out that lots of relevant terrain features, shown on printed maps (Harvey & OS), and available as online tiles, were missing. This type of detail is often difficult to generate automatically using software, and even then is unlikely to match the output of skilled draughtsman working to detailed composition rules. I tried adding a hillshade layer from EA data, but it didn't really pick out this detail. Then I remembered that Luke Smith of Grough had used a layer provided with OS VectorMap District called "Ornament" when he prototyped maps based on open data. I therefore added this layer. It works quite well at low zooms, but is rather ugly at anything higher than 1:5000.

Added hillshade from Environment Agency data and Ornament from OS VectorMap District open data. Hillshade is less effective than I expected at high zooms, and the ornaments only really work in a range 1:5k (as here) to 1;25k or thereabouts.

Lastly, and more for fun than anything else, I regenerated contours at 15 m intervals and clipped these by scree layers mapped on OpenStreetMap and changed the colour of the contours to a shade of grey to replicate how this information is shown on the Harvey Map. The end result is a good illustration of these differences: the Harvey Map generalises features such as cliffs and places them to enhance the map users' impression of the terrain, whereas the OS ornament looks nice, but is nothing like as good a guide for the walker.

With 15 m contours (from EA 1m DTM) and with contours on scree coloured grey rather than brown (as done by Harvey Maps), plus OS VMD ornament.

The bottom line from this is quite simple: don't bother with Environment Agency Lidar data if you just want contours: Terrain50 vector data is much easier to get up and running. The data is also packaged as mbtiles, but I couldn't find a way to style this in QGIS.

Lastly a big thank you to Nigel Parrish who caused to to look at the data, and thus discover the difference between the vector & raster versions.