[Talk-GB] Automated Code-Point Open postcode editing (simple cases only)

Robert Whittaker (OSM lists) robert.whittaker+osm at gmail.com
Fri Jul 19 08:58:52 UTC 2019

On Tue, 16 Jul 2019 at 22:20, ndrw6 <ndrw6 at redhazel.co.uk> wrote:
> Over past several months I've been adding postcodes from Code-Point
> Open. I've streamlined the procedure a bit, so I can now add the tags
> without spelling out every single one of them, but it is still a manual
> and labour intensive process:
> https://github.com/ndrw6/import_postcodes/
> While working on that, I've noticed there are a lot of simple cases
> where automatic collation would have produced very similar results. For
> example, in case of existing OSM buildings without an addr:postcode tag
> located at or very near to a Code-Point Open centroid.
> Therefore I'm requesting permission to use the following automated edit
> procedure:

I'm afraid I think this new suggestion will be too prone to errors to
outweigh the benefits, so I have to oppose it, unless there's
significant manual curation. In which case though, you might as well
not bother with the 15m limit and instead look to find the true
extents of the postcode unit. I'm also not convinced that the previous
work on adding postcodes to single buildings in isolation is that
beneficial. In particular, the new proposal has the following issues:

* Not all buildings are addressable properties, and so some (e.g.
garages, outbuildings) shouldn't have a postcode. How would you avoid
accidentally adding postcodes to these?

* Large-user postcodes only belong to a single building, and shouldn't
be added to any nearby buildings, however close. It's not clear how
you would avoid these with the proposed method. (For example it's
common for a bank to have its own postcode, but the buildings either
side along the high street will all share a different postcode.)

* Often the two sides of a street will have different postcodes. So in
the case of terraced houses, you may have an opposite property within
15m belonging to a different postcode unit.

There are also some problems with the existing method:

* Sometimes OSM building polygons encompass several joined properties
(e.g. a terrace or a row of shops). Adding a single postcode to such a
building polygon might be incorrect, as the properties may not all
share the same postcode.

* Adding postcodes in this way removes a convenient way for other
mappers to work on adding more detail, by looking for postcodes that
are not yet in OSM.

I would argue that the benefits of adding just a postcode to a
building corresponding to the centroid are pretty small -- any users
can already use code-point open to obtain this information. The real
value in adding postcodes to OSM is when they combined with other
address information (e.g. street names and house numbers to give a
full address) and when human extrapolation is used to infer the full
set of properties that have the same postcode.

I thus have to object not just to the new proposal but also any
continuation of the previous work to add single postcodes to buildings
under the centroid. Instead I would suggest it would be better to
proceed more slowly and take the time to add addr:street (and other
addr tags) tags when adding postcodes, and also try to add the
postcode to the full set of properties for each unit where this can be
deduced. See the discussion at
. For instance at http://overpass-turbo.eu/s/KRf only the highlighted
buildings have postcodes and none have streets. It should be possible
to infer the postcodes of most of the houses from the centroid
locations, and also add the addr:street tags in that area. A tool that
finds postcode units whose centroid lies on top of an existing OSM
building would still be a good way of finding instances to apply this
procedure to though. Better still if it could prioritise areas with a
high density of small buildings (i.e. a systematic import/ tracing of
buildings) that also lack postcodes.

Best wishes,


> 1. Open an osm file containing missing postcodes (from the above
> website) in jOSM
> 1a. Select all points from the above dataset
> 2. Download OSM data in the area of interest
> 2a. Select all ways with a "building" tag of typical residential house
> size and without an "addr:postcode" tag (search phrase: 'building
> -"addr:postcode" type:way areasize:50-1000')
> 3. Use a collation plugin to collate both datasets with "centroid
> distance" set to "< 15m". The condition is there to apply postcodes only
> to small buildings in direct vicinity of the codepoint centroid.
> There are some caveats I've noticed, often not different from manual
> editing:
> a) Some buildings have addresses added as separate points rather than
> tags (automated edit will add addr:postcode tags directly to the
> building, this is what I chose to do manually as well)
> b) Collation plugin doesn't support relations (these postcodes will get
> ignored and can be added later manually)
> c) Often OSM buildings contain multiple addresses or postcodes and
> should be split into several buildings or building parts. This affects
> both manual and automated procedure, to minimize the impact I am setting
> relatively small "centroid distance" and building area limits.

Robert Whittaker

More information about the Talk-GB mailing list