OpenStreetMap

The official and accurate boundary for the Brecon Beacons National Park. The polygon has been split into many parts limited to 2,000 nodes/vertices each.

Is https://www.openstreetmap.org/relation/6191974 replacing http://www.openstreetmap.org/relation/357283 ? Looking at the two now, there seems to be some issues - I'd expect https://www.openstreetmap.org/relation/6191974 not to have ways joining across the middle of the park.

Hello. I'm an amateur at this and could do with some help. This was the only way I could upload the file (GPX traces upload kept failing). My goal is to replace the existing national park boundary (which has been digitised inaccurately) with this boundary. The problem with this boundary is that I've had to split it into multiple polygons to get around the 2,000 node limit.

This is what the boundary should be:
https://data.gov.uk/dataset/brecon-beacons-national-park-boundary

Thanks

And yes, it should be replacing http://www.openstreetmap.org/relation/357283.

I can upload and a polyline instead? But I'm unsure how OSM handles the national park 'fill colour' if it's a polyline.

The normal approach for large areas two big to handle via one large way is to have lots of ways as type "outer" (see http://www.openstreetmap.org/relation/2176657 for example). Re the "fill colour" that's a decision for individual renderers, of which the 5 different map styles on the osm.org site are only examples.
Maybe it's worth asking about what else to think about either on an OSM mailing list such as "talk-gb" https://lists.openstreetmap.org/listinfo/talk-gb or on the #osm-gb channel on IRC (see http://wiki.openstreetmap.org/wiki/IRC). There I'm sure you'll find people who've added similar national parks in the past (which I haven't).

Thank you! I now need to remove this change set and my other accidental changeset: http://www.openstreetmap.org/changeset/39120226

Do you know how these can be removed?

Thanks again!

Shaun

I'll have a go at reverting them...

OK, done. It took 3 goes (to 39152803) but eventually got there OK.

When you're ready to think about trying again, there are a few things you'll want to think about:
o should the relation be defined in terms of entirely new ways, or existing ones (like 357283 at least partially was)
o Try not to make the creation changeset so huge that it has 38k nodes in one changeset. Maybe split over 2 or 3?
o Don't tag every way and every node with "Brecon Beacons National Park". just the relation.
o Think about what tags should be on the relation (see 357283 as an example)

Oops - looks like you've already created the new relation https://www.openstreetmap.org/relation/6194617 in https://www.openstreetmap.org/changeset/39148379 . I'd still suggest to go back and discuss and correct the things that I mentioned above.
Note that when importing stuff into OSM there are some rules that really should be followed - see http://wiki.openstreetmap.org/wiki/Import/Guidelines for details. There are several reasons for this, set out in that page - to which I'd add "avoiding the need for someone else to spend a few hours undoing failed import attempts" :)

Is this fixed now? It looks like the night shift got in first and reverted the new boundary, so we are back to the old boundary now.

@The Maarssen Mapper Not quite - We still have http://www.openstreetmap.org/relation/357283 (old boundary, all the tags) and https://www.openstreetmap.org/relation/6194617 (new boundary, many fewer tags, possibly too many nodes).

OK, still some work to do then.. What's the background to your comment about "possibly too many nodes"?

The simplest approach appears to me to be to move the current members of the old relation to a new (backup) relation and then move the members of the new relation to the old relation. The temp relation can then be inspected for ways which can be deleted entirely (their only function was the NP boundary). Optionally the old and new boundaries can be visually compared with other features to see if there are reasonable opportunities for combining the boundary with other features such as waterways, highways and paths. (Note that my personal preference is for a conservative sharing of nodes with other features, NOT sharing of ways.) Then the temp relation can also be removed.
Any comments on this proposal?

Thank you both, lesson learnt and apologies for the inconvenience. My initial aim was to upload it as a trace and amend the existing boundary - but I had issues with the web interface and then I thought this was what I was doing with JOSM.

Each Way in https://www.openstreetmap.org/relation/6194617 is tagged as' Brecon Beacons National Park' because I didn't follow existing Ways and I weren't sure of what to tag my 'new' Ways as. Each of these Ways is 2,000 nodes or less each so hopefully it will work.

The boundary does follow waterways and roads in some places, so Maaseen you are correct in maybe I should have taken the slower approach and use existing Ways in some places (I would have done this if I successfully managed to upload the boundary as a trace).

But on the other hand, where the National park boundary follows roads and rivers, it is more accurate than the existing Ways. So maybe another approach would be to amend some roads and rivers to follow the boundary Way?

I am an amateur at OSM so I'm all ears to what you think would be the best approach.

Thanks again!

As a separate note, all Welsh National Park boundaries have been granted Open Data, and I believe England and Scotland has followed. So learning from what I have done here and coming up with a suitable method, there may be an opportunity for me to work with the other 14 National Parks so that they can upload the correct versions of their boundaries to OSM.

@shaunlewis The boundaries that you have uploaded seem to be grossly overnoded. Please don't do any more data imports without discussing with the wider community first. For imports in GB, the best place to do that is the talk-gb list (https://lists.openstreetmap.org/listinfo/talk-gb).

Re "too many nodes", just zoom in anywhere on the new boundary relation such as at https://www.openstreetmap.org/#map=19/51.82530/-3.28319 and look at the number of nodes in the new relation. No attempt seems to have been made to consolidate immediately adjacent ones.

Ah yes I see. Here they are a direct copy of the 'official' administrative boundaries from Ordnance Survey. I won't carry out any new changeset uploads. But if it would help the situation, I can generalise the boundary if needed?

If only OSM had decided to partner with QGIS or something rather than creating their own dodgy and complex interfaces. Maybe this would be far more straightforward!

@shaunlewis you need to have the discussion with the wider community via talk-gb, not just two people who happen to have noticed this changeset discussion. Did you read http://wiki.openstreetmap.org/wiki/Import/Guidelines ?

@SomeoneElse So you don't mean there are too many nodes in a numerical sense, just that nodes should be re-used where appropriate?

These boundaries from OS and others are already generalised to some extent. I don't think we want to encourage further generalisation. After all, we are reminded frequently that there are no limits to the amount of detail that can be accommodated in OSM and the database is already huge anyway. The data consumer can always generalise if that is appropriate for their case, but you cannot recreate detail which has been lost by generalisation.

No unfortunately I wasn't aware that it existed. In fact I wasn't aware that I was uploading to the live copy, but thought I was uploading to a trace. It has been a steep learning curve. Nevertheless unfortunately the system is full of flaws and limitations and I'm at the process of learning these limitations. I agree, the boundary needs some generaliaing- but surely the goal here is to create more detailed and more accurate data? That's all I've tried to do, and generalising data to the stage where it will become inaccurate seems bizarre,

I apologise for causing inconvenience, but we all got to start somewhere, and this is a learning curve for me. Encouragement is what's needed, to gain more data editors.

I don't believe that this boundary, as imported, already has been "generalised to some extent". See http://www.openstreetmap.org/node/4170092738 , http://www.openstreetmap.org/node/4170092739 and http://www.openstreetmap.org/node/4170092740 . The existence of those three so close together suggests a case of "garbage in, garbage out" rather than any genuine "level of detail".

The National Park boundary I have uploaded is the official boundary. In some areas it follows roads, rivers, and political boundaries from OS MasterMap. Therefore what has already been digitised in OSM is already 'garbage.'

I have a detailed knowledge about the national park boundary and what it follows, and I would love to learn the system more so that I can start aligning rivers and roads and political boundaries so that they too can become really accurate. Is this not a good way forward?

I can see that the NP boundary has a tiny wobble where those three nodes are, whereas the OS boundary line data has a straight line without the wobble nodes. Boundary-Line is based on 1:10000 mapping and is not the most accurate detail that exists.

Do we agree that the new data is the best data (most accurate boundary) to have in OSM? If so, we can get on with a process to replace the current NP boundary with the new data. If not, what is wrong with it and how do we fix it? Or is it so wrong that the old boundary is actually better? Let's move forward here and make some progress.

Thank you The Maarssen Mapper, that's all that I want. The boundary-line data has already been generalized by OS. In mastermap, there is a boundary data which are the 'official political boundaries'm and these are what government use. Of course we're not allowed to follow that data directly as it breeches copyright, but as the National Park is Opendata, there's no reason why we can't trace this.

I think the best way forward is to remove the 2 changesets I created in error, and replace the new boundary with the old. I'm happy to to do this with pointers, but also I would appreciate help.

I notice the English/Welsh border is inaccurate in some areas too. Another benefit of keeping the new national park boundary.

The E/W border in the area of this NP should all be from OS Boundary-Line now. By coincidence I am currently working on Herefordshire boundaries. Further north (Worcs. etc) there may well be issues with old "NPE" based boundaries. Where do you see the inaccuracies?

You can see them all along there Herefordshire boundary from Hay-on-way if you pan in a southerly direction. This is a bizarre section as it zig-zags - but that's what the offical boundary does. It has just been generalised in open data boundaryline:

http://www.openstreetmap.org/node/4170092739#map=18/52.03392/-3.09150

They are tiny inaccuracies really so nothing of major concern for illustrative purposes - but may need amending if people use it as 'data'.

This is going to sound really geeky of me but I'm looking forward to improving steams and rivers like this one, although I OS has released an open roads and open rivers dataset , and if more accurate, I expect this may be used to supersede all roads and rivers anyway:

http://www.openstreetmap.org/changeset/39117825#map=17/51.75817/-3.40991

We've also made some of our datasets open data, such as Public rights of ways, Fforest Fawr Geopark, and International Dark Sky core.

https://data.gov.uk/publisher/brecon-beacons-national-park-authority

Natural Resources Wales has also made their LiDAR data free and from this there's potential to calculate building heights as an additional attribute for every building in Wales, and with EA LiDAR, England too! The potentials are huge :-)

I see what you mean about the boundary south of Hay-on-Wye. It looks like the NP boundary is intended to be colinear with the admin boundaries, and the NP data is less generalised. Then I suggest we use the NP boundary instead of Boundary-Line in this area.

Agreed. So what's the next step for committing the new national park boundary and removing the old?

River and stream data is an interesting case where all sources need to be taken into account. In your example http://www.openstreetmap.org/way/45991154 is from NPE and is obviously ripe for improvement, but rivers move or are moved, and in many areas it's clear to see from the Bing imagery and GPS surveys that the "official" data is wrong - the stream is no longer where it was. However, OS OpenData is really useful in helping to align Bing imagery and GPS traces (and in the absence of GPS traces in upland Wales I'd generally trust its alignment over Bing). From experience the folks at the OS can also be somewhat "optimistic" when thinking that something is actually a stream.

Yes you're absolutely right. The boundary was first created in 1955 and in some lowland areas the river has moved quite a bit since then. But for upland streams (like the one I shared a link) these are in steep valleys and are unlikely to move much. I'm not saying we will be able to copy the National Park boundary in all areas an assume its correct, as it follows old roads in areas which have since been straightened, but much of it can be traced.

AFAIK these volatile boundaries are resurveyed periodically. Certainly every edition of Boundary-Line contains many changes to coastal boundaries where the MLW line has been updated. I assume that the boundary is where OS say it is (although that is second-hand information as they do not determine the boundaries) and the river/stream may or may not follow the boundary; I tend to leave the waterway alignments alone.

I don't want to go into the politics of it because it's mid-blowing. But theoretically, if the official documents of a boundary says 'it follows the centreline of a river', then legally, the boundary can be changed when the river changes. That's what the Lake District has done. But the Brecon Beacons has followed the original river centre line to keep it straightforward. The Brecon Beacons boundary is only as good as MasterMap, which indeed is undergoing a major improvement excercise where much of it's upland data digitised at 1,10k scale, will be redigitsed to 1:2500 scale. In this case, the Brecon Beacons has taken the apparoach that it will continue to improve the boundary so that it's in alignment with MasterMap (this excludes old rivers, roads etc).

Although the OS are not boundary designators, they have worked with the boundary commission etc, and they are indeed the official source for political boundaries - and this is reflected in their MasterMap product only. National Park boundaries and maybe some others are boundaries that OS no not represent in their Mastermap product (yet).

OK, I have sorted the relations. The original relation #357283 now has the new boundary data, but this has not yet been consolidated with other features. The previous boundary is in https://www.openstreetmap.org/relation/6196005 for reference - this relation can be deleted eventually when the consolidation is done. I will start work on the eastern boundary (herefordshire and glouscestershire) - @shaun, can you cruise round the welsh bits?

Thank you so much! I am in debt and if there's anything you need me to do in future, please give me a shout.
Yes I'm happy to make these amendments either tonight or tomorrow. I want to make sure I familiarize myself better to avoid making further mistakes.
Thanks again to both of you.

I have done the section from Hay down to where the NP diverges from the admin boundaries at http://www.openstreetmap.org/relation/357283#map=18/51.90467/-2.96697
For most of this distance I have used the new data, but where there is no significant deviation from the existing Boundary-Line data over a reasonable distance I have let that stand.

All looks excellent to me.
Is it possible to put a note on the boundary asking people not to edit it's shape? Or is this not encouraged by OSM?