OpenStreetMap

I’m undertaking a bit of a project in Burnie, a city in the state of Tasmania in Australia, and thought that I should leave a more public note about what I’m doing and the reasoning behind it. Don’t expect anything particularly entertaining from this entry. The short version: a recent import of official suburb boundary data can be used to accurately offset aerial imagery, which can in turn be used to consistently align existing mapped items across the city.


While there are other mappers in the area, and I was most active in OSM mapping several years back, I’m responsible for a decent amount of data in the Burnie area. My process was pretty straightforward: drive to a new area, survey on foot, record GPS traces as I went. Back home I would upload the address data and anything else that needed updating and trace buildings from imagery. The best-quality imagery at the time was Bing, which was fairly average resolution and not always well-aligned, so I’d align the map to my GPS traces or publicly uploaded ones, depending on subjective recording quality. While this was in good faith, it meant that each little area I’d surveyed tended to have slightly different offsets, with no way for me to tell if any were correct. It’s minor, but many of the buildings I traced are also poorly outlined, though the older imagery probably limited how well I could do at the time.

Having resumed OSM mapping recently (after moving house - what better motivation than having a new neighbourhood to explore?) nobody had done much to improve this issue. Not surprising; it’s not the most populated area, things were good enough for routing purposes, and there was plenty that still wasn’t mapped at all. But it bothered me, and I noticed a new feature that made it much easier to resolve.

Burnie suburbs often split along fencelines and other structures visible from imagery, and Bing has improved their aerial imagery which now seems very well georectified. (Maxar imagery is slightly newer, but the local offset varies noticeably over small distances, especially if there are changes in elevation.) That means it’s easy to align the imagery to suburb boundaries, check that it matches well across the entire suburb/city (it does), and then align items to that imagery offset. Bing almost doesn’t need to be offset, to be honest.

I’ve thus been spending my time aligning roads and buildings to this offset across the city, rather than the hodge-podge of inconsistent alignments that existed thanks to my past efforts. I’m also doing the same with landuses, and unglueing and splitting them where necessary (which is “often”, again thanks to my past efforts). Because the city is now too detailed to download in a single request, I’m now attempting to get public roads consistent first and hope to go back and adjust all the other buildings & landuses and other data as necessary in a more piecemeal effort, probably with more reliance on the newer Maxar imagery. However, I’m not adjusting anything in the CBD as I mapped this to a relatively high level of detail in the recent past - it’s probably not perfectly aligned, but it is at least consistent within itself, and is much better than most of Burnie.

There is one obvious question - whether the suburb boundary data itself is trustworthy. In this case they were added as part of an Australia-wide import from official data, with documentation on the wiki at https://wiki.openstreetmap.org/wiki/Import/Catalogue/PSMA_Admin_Boundaries - some may have existed previously but were presumably checked for accuracy during the import. I don’t think there’s any need to doubt the original data, produced by a government with access to much better surveying equipment than I have. For safety I downloaded a copy of the imported data from https://github.com/FrakGart/psma-admin-bdy-2020-08 and compared in JOSM to the current boundaries, and couldn’t see any significant changes around Burnie. So the suburb boundaries (or at least identifiable shapes along them) can be considered a high-quality data source, reducing the need for GPS traces to align items visible on aerial imagery. And if I’m wrong, at least it will be easier to offset everything correctly in future.

Location: Montello, Burnie, City of Burnie, Tasmania, Australia

Comment from tastrax on 28 November 2021 at 22:39

Great work - such a pity that Burnie didn’t get a recent update of BING imagery like Hobart and Launceston as that would have made your work a lot easier!

Comment from Warin61 on 29 November 2021 at 00:24

Administrative boundaries don’t necessarily align with present features. Be cautious in aligning things. Good luck, it is a lot of work looking at realignments.

Comment from Ds5rUy on 29 November 2021 at 05:39

“Because the city is now too detailed to download in a single request”

If you are using JOSM, there is a plugin that allows continuous downloads as you scroll across the map. This is working well for me if I just start mapping at one point and then just keep scrolling and following features.

Comment from bdhurkett on 30 November 2021 at 08:44

Thanks Warin61, that’s potentially true and there were definitely areas with the related issue where the boundary had no physical representation, but most of Burnie is built-up enough that I could find enough spots to compare. A curved corner between public footpath and private property, or swerving at angles between a few fenced properties. It would then line up reliably with properties at the segments in between, often straight lines that I couldn’t reliably offset directly. There were houses with things outside their supposed boundary, and a few properties did cross suburb edges, but there were enough good matches agreeing with each other that I was happy with the data quality.

Neat plugin Ds5rUy (hard name to type!) - I’ll have to have a look, though usually I aim to keep my changesets a little smaller so I don’t usually encounter that problem. It almost sounds dangerous, there’d always be something more to touch up!

Comment from Ds5rUy on 30 November 2021 at 09:45

Sorry about the name, it’s simply a randomly generated character sequence.

Comment from Warin61 on 30 November 2021 at 10:51

I chose my name from an Aboriginal language. The number is ISD code for Australia. For UK things I use 44 and some other name.

Comment from Verdy_p on 5 December 2021 at 06:09

Isn’t Tasmania quite sensitive to the continental drift ? I mean, as compared to the worldwide WGS84 which does not account for local drifts, whereas official geodesic data and survey is aligned to physical positions on the ground and trinagulation, using its own local coordinate system, whose offset with GPS will constantly vary over time. This drift can be several centimeters each year on average over large areas (more than about 100km-wide), but may be larger in some local areas, especially on “fluid” soils, or because of major geological events (sometimes dramatically after landslides). To have our OSM data taking account of this, we wouldneed to qualify all coordinates with the refernece geodesic system with which it was mapped, and with a reference date. In OSM these coordinates should “normally” be converted to WGS84 coordinates at the time of mapping, because we cannot use multiple coordinate ssytems, but according to the current offset of the reference geodesic system with the GPS/WGS84 system; however the sources used for this mapping often do not indicate the reference date used, even if they indicate their reference geodesic system; this makes automatic correction impossible, and over time data imported in OSM from different sources with different geodesic systems and different dates will become disaligned in a very dispersed way. I do not see how to solve this solution easily, especially when after the fact, some people start doing their own “manual cleanup” of disalignments, by choosing arbitrarily one of the available imageries (which also have used different MNT data for their orthocorrection, computed at diferent dates, these being also not tracked correctly in existing photographic sources). That’s why we cannot easily get metric precision (over a significant period valid for several yearts), even if the orthophotographic or other imported data sources show details up to several centimeters. It’s then up to OSM mappers to find local compromizes, knowing that everything will drift over time, but at least they should make the data coherent locally, so that distances, proportions and angles are locally correct and match the reality observed on the ground and in all sources and surveys.


Login to leave a comment