Detached garages, UPRNs and house numbers

Communities United Kingdom
1

Hi all

I’m new here. I’m looking for advice on best practice for tagging. I recently did a drone survey of a street by using ~80 overhead photos to build a 3D model (at aerialmodel.com) then generating an overhead TIF, and using a good scatter of photo control points with RTK GNSS coordinates to accurately georeference the TIF. I then used JOSM to draw the polygons of all the houses in the street, all of which are detached, and a few of which have detached garages. For tagging I used:

  • addr:housenumber
  • addr:street
  • addr:city
  • addr:postcode
  • building=house

For the detached garages I used the same tags, but omitted addr:housenumber, and set building=garage.

So firstly I want to check whether that was correct. The garages clearly belong to specific house numbers, but I took the view that it’s the house that should be addressable, not the garage. There was already one house in the street, contributed by Philip Cullen. He had almost the same tag set, but used building=detached for the house. Should I have used that instead of building=house? He had also tagged that house with a UPRN, and at the time I didn’t know where to source the UPRNs.

Secondly, after reading the forum for a while I discovered Robert Whittaker’s excellent tools, in particular the tool for highlighting UPRNs within a postcode. So I now have an easy way to assign UPRNs to the houses I’ve mapped. The tool shows that the UPRNs lie nicely within the house polygons, but that the detached garages don’t have separate UPRNs. Does this suggest that the garages are considered part of the same property as the house, and should I therefore give them the same UPRN? And should I therefore give them the same house number? Or should I just omit the detached garages from my UPRN and house number tagging?

If anyone is interested the street I mapped has the postcode NG8 1GJ.

2

I can’t take full credit, I added the UPRN and postcode to an existing building.

Single dethatched garages typically don’t have UPRNs. Some areas do have UPRNs for blocks of garages (for the block, the individual garages, or both). Where a garage has been turned into something else, it may get a UPRN for this new use too.

I have only been adding the UPRN to the main building itself, such as the house, unless there was a separate one to add to a garage. That seems to be the most common approach taken.

2 Likes
3

There probably shouldn’t be any addr tags on the garage.

1 Like
4

building=detached provides more detail than building=house. We also have building=semidetached_house and building=house + house=terraced. It’s ok to tag building=house, building=residential or even building=yes if you’re not confident identifying a building.

Also nice work on the buildings, they look very detailed!

1 Like
5

Great - thanks everyone. So I’ll switch to building=detached, and I’ll add the UPRNs to only the main house. Regarding CjMalone’s point about the addr tags on garages - if I remove them then they’d be left with only one tag: building=garage. Is that the intention?

6

Thanks Gary. From 50m up my little DJI Mini 4 Pro takes surprisingly good photos, and even when some resolution is lost in the ‘overhead TIF’ generation it’s still easy to see plenty of detail.

7

I checked a nearby development, and can confirm the garages in that development do have just the one tag: building=garage. I’ll follow suit.

8

Impressed by your expertise and by how well-equipped you are. It’s ideal for when there’s no up-to-date aerial imagery.

Your tracing looks accurately aligned to ETRS. (Or WGS84 epoch 1989.0 if you prefer.) I’m curious how you achieved this, because RTK base stations may have an offset of position.

  • Did you have a source of correction signals which was broadcasting a position accurately referenced to ETRS? And if so, what was it?
  • Did you align your TIF image to the Cadastral Parcels overlay?
  • Or something else?
9

Hi Adrian

Without wanting to go into the details of the equipment I used or the source of corrections (nothing sinister, just a personal preference at this stage), I can say that I’m confident that my ground control point coordinates were determined in ETRS89. I did not apply any transformations. To be honest, I wasn’t certain what reference frame I should use for OSM in the UK, but once I saw that the existing features (road centrelines) lined up well with my georeferenced TIF I simply added my building polygons directly. I did not look at the Cadastral Parcels overlay. I should perhaps revisit that, in case I need to account for the drift between ETRS89 and WGS84. Happy to be advised on these points.

For georeferencing I picked up the coordinates of all the black plastic centre caps in the ‘Diamond Cable’ inspection covers in the pavements. These are easy to pick out in the TIF, and it gave me plenty of registration points, such that if one or two seemed off I could just ignore them. I used QGIS to do the georeferencing.

I’m new to drone flying. My DJI Mini 4 Pro is by no means an expensive drone, and as a Class 0 drone (249g) I can fly it more or less where I like. It has a surprisingly good 48 MP camera though - from 50m up the size of a pixel on the ground is less than 1cm. I have no idea how much lens distortion there is, but the point cloud generation at aerialmodel.com seems to do a good job, given enough photos.

Being a novice I’m a lot happier letting it fly pre-programmed missions than I am stick flying, so after sampling waypointmap.com I’ve spent a bit of time developing my own mission planning app that produces waypoint files that the drone can use for automated flying. This local street capture was actually a test of the ‘Area Survey’ mission type in my app. So it was primarily for personal objectives, but it seemed like the end result was worth incorporating into OSM.

EDIT: I have now checked my TIF alignment against the Cadastral Parcels overlay. It seems to be very good. I don’t see a systematic offset in any direction. I see some approximations in the parcels data, but in general the agreement along fence lines, pavement edges etc seems to be better than 10cm. It’s difficult to know for sure, due to the aforementioned approximations - some paths and driveways are markedly different from what’s actually on the ground.

1 Like
10

I tried a few of the available aerial images. Each set of imagery seems to differ from my georeferenced TIF by different amounts. Mapbox appears to be more or less vertically down, and differs from my drone image by a few decimetres. Bing imagery seems to be slightly oblique, and my building outlines seem to align better with the ground footprints than with he rooftops.

What sort of accuracy can we expect from these satellite images? And when Bing georeference theirs, are they working on the base of the walls (i.e. ground level) or the rooftops? I would expect then to georeference at ground level, but how good is their DEM? My feeling is that there’s nothing that reliably shows my georeferencing to be in error by more than I’d expect from the RTK GNSS, i.e. 2-3cm (the cadastral parcels agree very nicely in many parts of my image, but as noted above there are obvious problems with the cadastral data), but I’d be interested to know how accurate we expect the satellite imagery to be. I guess my main concern is whether I’ve used the right reference system for my georeferencing - a small systematic difference between mapbox and my image could either be an inaccuracy in mapbox’s ability to georeference their images, or it could be due to me using the wrong reference system. Or a bit of both. I’m fairly confident that my image is accurately georeferenced to ETRS89, but is that the right reference system?

11

Things have certainly moved on in OSM - a decade and a half ago some things were getting added to the wrong county(!).

If I alight the Bing imagery to the OSMUK cadastral parcels (in iD “Imagery Offset”) I get an offset of “-1.47, -1.7”. That’s not much, but it suggests that either the garage is a bit far north or OSMUK’s cadastral parcels are out in the other direction. Similarly with ESRI I get “-0.48, -0.48”, and Mapbox “-0.89, -1.91”, but in the great scheme of things I wouldn’t worry about it - I’d worry far more about all the things not mapped elsewhere!

12

Nice, thank you. That garage appearing to be too far north is actually the eaves of the roof overhanging the boundary/fence line by 30-40cm. Same with the garages at No 1 and No 17. Taking those into account your map makes it look really good. But the footpath between No 21 and No22, for instance, shows that the cadastral parcel map, which shows a significant kink in the footpath, is quite different from the ground truth. The dotted line on your map is the alignment that I drew from my overhead TIF, and it shows that the entrance to the footpath is somewhat different from the cadastral map. Some of the driveway entrances around there are different too, e.g. between No 24 and No 25. But on the whole it matches quite well.

I do take your point about it being more important to fill in other areas than to fret about a few decimetres, so I’m not going to worry any more. As I said, this was something of an academic exercise for me, and I’m happy that it got the job done with relatively little effort. But OSM has drawn me in - discovering the historic map overlays today has been very interesting for local history :-)

13

Thank you for the detailed answer. No question, your tracing is spot-on aligned with ETRS. I know that doesn’t happen by accident.

The aerial imagery available to OSM (Bing, Esri, Mapbox, etc.) is generally misaligned, offset by up to a few metres. In Great Britain it is recommended always to align the aerial imagery to the Cadastral Parcels. One advantage of this is that it helps different users’ contributions to match up. The parcels are accurately aligned to ETRS because they go back ultimately to Ordnance Survey data. (This answers your question/confirms your conclusion.) The parcels are mentioned in the wiki but not in an obvious place where a newcomer would discover it.

Positions in OSM should be aligned to WGS84, see this page in the wiki Converting to WGS84 - OpenStreetMap Wiki Hence my comment that positions in OSM in GB could be regarded as WGS84 epoch 1989.0. (Epoch is professionals’ jargon for the date on which the position was measured. Epoch also describes positions which have been adjusted to what they would have been on the given date.)

Positions in WGS84 are constantly changing because of the motion of tectonic plates. ETRS is a plate-fixed datum, fixed to the eurasian plate. So positions in ETRS essentially don’t change, within the area of the plate. As I understand it, there is little appetite in OSM at the moment, for handling positions more rigorously. When the choice of WGS84 was made in OSM, I don’t think anyone expected RTK measurements to reach the world of amateur GPS users. RTK receivers were very expensive and there were no low-cost sources of correction signals. Without precise positioning you’d have a job to distinguish between WGS84 and ETRS.

There’s an obvious anomaly in the parcels data where a parcel boundary does not quite follow the line of a fence. A possible explanation for this is that the Land Registry took the boundary from the developer’s site plan, or from a conveyancing plan supplied to the Land Registry when the new property was first registered. And for some reason the fence was not constructed exactly according to the plans.

You can see the same anomaly if you overlay the parcels on the Ordnance Survey map. Visit https://uprn.uk/usrn-map , zoom in to zoom 19, click the icon at top right and enable the relevant layers. (Don’t copy from the Ordnance Survey map, it is subject to copyright!)

The quality of orthorectification in the images available to OSM, is not particularly good. I’m sure the Ordnance Survey have much better imagery, but they keep it private. (Orthorectification is the process of adjusting a photo so that it overlays a map correctly.) Having established an offset as Andy describes, if you go 100m down the road you may find that the offset has changed. You may also find that the offset is different between the two sides of a road, if a join between photos has been “hidden” by placing the join in the roadway.

Orthorectification is done for ground level. So when the view is oblique, it is the footprint of the building on the ground which is correctly positioned. The footprint is what we want to trace and it is not easy when the view is oblique. The Mapbox imagery of your area is ace because it has high resolution and an almost vertical view.

The garage wall is on the property boundary. The roof overhangs the boundary. So there’s nothing wrong here. We are just using the roof outline as an approximation for the building footprint. The fact that we can see the overhang, is testimony to the fine level of detail at which we can now work.

3 Likes
14

If you haven’t already found it, there are many more historical maps on the National Library of Scotland website https://maps.nls.uk/

15

Not all of those NLS maps are available for use in OSM. (Because NLS entered into a commercial arrangement with the scanning contractor and gave them some rights for a limited period).

So do be careful if you want to use them for any exercise that might end up contributing to OSM.

The NLS maps available for use on OSM activities are listed here.

1 Like
16

Thank you, that’s all useful information, and some more useful links for me to bookmark.

The historical maps are great, and purely for my own local interest. There is a canal that used to run through the area. Disused now and built over in many places along it’s route. I see part of its route is in OSM, but it has been edited quite a few times including to remove some sections. Until I saw it in OSM recently I hadn’t associated the various segments that still have water as being part of the same route. The historical maps show it more completely, and I find it interesting to browse and learn. I’ll look at the maps we’re allowed to use and possibly see if there’s any more of the route that I can legitimately add, although I’m curious why previous edits removed parts - is it because OSM should only show current features? Isn’t there a ‘historic’ tag or similar that could be used?

17

Generally speaking, OSM is about what’s here now rather than what was there 50 years ago. However, what is here now might be a physical remnant of a former feature - for example this which has been tagged as a waterway=derelict_canal and just to the north there is a bit with water in that has been tagged as waterway=canal; disused=yes.

Those two only really make sense when there’s something left - this bit of the former Derby Canal has long disappeared beneath both the current bus station and the one before it, and arguably belongs more in OpenHistoricalMap.

See also what the wiki has to say about lifecycle tags