piebro/osm-data huggingface dataset:
user_5359 (2016-05-16 13:57:51+00:00): Welcome to OSM! Is this a shop Apple (shop=it) or the company Apple (company=it)?
jlcod (2016-05-05 21:20:56+00:00): Hello,

please do not draw separate lines for non-separated objects. For lanes on streets there are those tags: https://wiki.openstreetmap.org/wiki/Key:lanes
by the way, you write "Liegenschaftsamt Karlsruhe" as a source, which data do you use and does the license of the data permit the usage in OSM?
jlcod (2016-05-07 00:22:58+00:00): (sorry, mistake: source=Liegenschaftsamt Karlsruhe was already there before the edit)
Nakaner (2016-05-17 15:07:16+00:00): This changeset has been manually reverted by jlcod at changeset 39268532.
BushmanK (2016-05-06 20:00:10+00:00): А что там теперь, на месте леса? Стройка?
literan (2016-05-09 22:19:16+00:00): пока ничего. Судя по всему, там пройдет Северо-восточная хорда, но этот участок еще в проектировании
BushmanK (2016-05-09 22:22:32+00:00): Класс, то есть вырубили "на всякий случай"...
literan (2016-05-10 08:08:18+00:00): на roads.ru высказывали предположения, что вырубили исподтишка, в титуле реконструкции МКЖД под пассажирское движение, чтобы когда будет стройка самой СВХ, экологам уже было бы нечего защищать...
BushmanK (2016-05-10 13:51:19+00:00): Легко верю.
user_5359 (2016-05-16 14:02:29+00:00): Welcome to OSM! You change a lake to circular building? It that was your wishes?

If you need help, you are welcome!
tkk (2016-05-05 10:24:35+00:00): Rozcestnik LB244 byl duplicitne, ten co nebyl v relacich jsem odstranil.
arvdk (2017-12-12 20:37:41+00:00): je hebt 'motor_vehicle=no' toegevoegd. Daar is hier een vraag over: https://www.openstreetmap.org/note/1091463
Hendrikklaas (2018-01-24 22:16:20+00:00): De waarneming was toen zo, maak na een recentere survey aanpassingen.
Владимир К (2016-05-07 10:32:14+00:00): На раменье это название дороги или таки просто направление, куда она ведет? я думаю что второе. а в таком случае, название надо удалить
Elbower (2016-06-09 05:57:33+00:00): Если дорога безымянная, то она должна оставаться такой и на карте? Ведь удобнее для навигации, когда дорога подписана? Возможно, я ошибаюсь.
Владимир К (2016-06-10 12:54:10+00:00): Если названия нет, то не должно быть и name. Потому что name для официального названия. Если дорогу как-то называют местные, запишите это в loc_name
Elbower (2016-06-14 23:11:39+00:00): Я все понял, видимо, у меня пробел с тэгами. Где мне почитать обо всех подобных  обозначениях?
Владимир К (2016-06-15 04:56:05+00:00): http://wiki.openstreetmap.org/wiki/RU:Key:name
Вот тут в общем в общем то есть.
Еще тут http://wiki.openstreetmap.org/wiki/RU:Names
Vincent de Phily (2016-05-05 11:32:04+00:00): Hi, welcome to OSM :)

Your first approach to mark the road as access=private was the right one. Deleting a road that actually exists isn't right, so I [reverted the deletion](https://www.openstreetmap.org/changeset/39118437) and tweaked the tags by marking this as a driveway and removing the redundant access tags.

From what I could make out via satellite imagery, the geometry of the driveway was pretty bad and incorrectly mixed with a nearby farm track. I corrected that as well, but if you know the area you'll hopefully be able to improve uppon my work.

Cheers.
nkc1 (2016-05-05 13:42:41+00:00): Not yet conversant with the messaging system so this is a repeat - I think!!!

Vincent.

Thanks for taking the time to correspond. One never knows what the best approach is but I have been mildly irritates by that trail for some time. I don't really want to be contentious but the trail as marked is not possible without 'bending' some rules.

I live there, its my home and has been for many years - there is no parallel farm track close to the driveway. For that trail to have been followed - as shown - would require someone crossing a boundary between two (private) properties to join a quite separate farm track. But mainly it would require someone using the drive way and traversing a private property - commonly known as trespassing. Thats how I read it from a local level. However I have, myself, crossed enough boundaries in my time to understand that such is the nature of rambling.

Finally it is not my wish to be a spoiler in any way for what I genuinely hold to be an excellent project. One which I hope will continue long into the future. I accept your suggestion and we can all move on to more important things.

Regards.
Frank C.
Vincent de Phily (2016-05-05 14:25:22+00:00): Got the message once. You can always look at http://www.openstreetmap.org/changeset/39117035 to get the canonical version of the discussion (you can also reply directly from there).

I am not 100% sure, but your description of the separate farm track and driveway seem to match the changes that I made. They are no longer connected, and they are better tagged. Please check that what I did matches reality; you'll have to force a browser refresh or to use the editor to see the latest version. Feel free to make further improvements, or to explain what is wrong (ideally add notes using the button on the right).

OSM isn't here to encourage tresspassing, even if any path that actually exists is ok to map. We have plenty of ways of tagging road type and access restrictions, and we probably don't want to map a path that goes through someone's garden or similar.
Владимир К (2016-06-24 08:47:48+00:00): это ведь точно не house
Владимир К (2016-05-08 08:14:11+00:00): Я настоятельно вас прошу прекратить делать некорректные правки. Пожалуйста, изучите документацию. Или я вынужден буду прибегнуть к помощи DWG
shaunlewis (2016-05-05 13:01:06+00:00): 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.
SomeoneElse (2016-05-05 19:37:10+00:00): 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.
shaunlewis (2016-05-06 10:50:23+00:00): 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
shaunlewis (2016-05-06 10:52:14+00:00): 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.
SomeoneElse (2016-05-06 12:33:06+00:00): 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).
shaunlewis (2016-05-06 17:15:48+00:00): 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
SomeoneElse (2016-05-06 18:29:46+00:00): I'll have a go at reverting them...
SomeoneElse (2016-05-07 00:39:35+00:00): 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)
SomeoneElse (2016-05-07 01:05:48+00:00): 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" :)
Colin Smale (2016-05-07 08:33:46+00:00): 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.
SomeoneElse (2016-05-07 08:38:47+00:00): @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).
Colin Smale (2016-05-07 08:56:12+00:00): OK, still some work to do then.. What's the background to your comment about "possibly too many nodes"?
Colin Smale (2016-05-07 09:13:41+00:00): 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?
shaunlewis (2016-05-07 09:42:11+00:00): 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!
shaunlewis (2016-05-07 09:46:11+00:00): 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.
SomeoneElse (2016-05-07 10:04:26+00:00): @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.
shaunlewis (2016-05-07 10:11:38+00:00): 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!
SomeoneElse (2016-05-07 10:16:37+00:00): @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 ?
Colin Smale (2016-05-07 10:29:39+00:00): @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.
shaunlewis (2016-05-07 10:32:58+00:00): 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.
SomeoneElse (2016-05-07 10:35:06+00:00): 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".
shaunlewis (2016-05-07 10:43:35+00:00): 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?
Colin Smale (2016-05-07 11:01:03+00:00): 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.
shaunlewis (2016-05-07 11:06:57+00:00): 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.
shaunlewis (2016-05-07 11:09:25+00:00): I notice the English/Welsh border is inaccurate in some areas too. Another benefit of keeping the new national park boundary.
Colin Smale (2016-05-07 11:17:58+00:00): 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?
shaunlewis (2016-05-07 11:23:53+00:00): 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'.
shaunlewis (2016-05-07 11:28:54+00:00): 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
shaunlewis (2016-05-07 11:33:37+00:00): 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 :-)
Colin Smale (2016-05-07 11:55:19+00:00): 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.
shaunlewis (2016-05-07 11:59:17+00:00): Agreed. So what's the next step for committing the new national park boundary and removing the old?
SomeoneElse (2016-05-07 12:01:51+00:00): 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.
shaunlewis (2016-05-07 12:08:44+00:00): 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.
Colin Smale (2016-05-07 12:12:56+00:00): 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.
shaunlewis (2016-05-07 12:28:10+00:00): 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).
Colin Smale (2016-05-07 13:12:41+00:00): 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?
shaunlewis (2016-05-07 13:20:20+00:00): 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.
Colin Smale (2016-05-07 14:57:44+00:00): 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.
shaunlewis (2016-05-08 19:07:21+00:00): 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?
bizen241 (2016-05-07 09:46:30+00:00): 岡山市都市計画情報は, 岡山市が著作権を有していて, OpenStreetMapが採用するODbLと互換性のあるライセンスでは公開されていないと思いますが, 岡山市から許諾を得てらっしゃいますか？.
Владимир К (2016-05-07 10:34:10+00:00): Не нужно отмечать бывшие объекты. если там сейчас нет церкви, её не должно быть и в базе. удаляю. Вам нужно пересмотреть ваши принципы редактирования
Владимир К (2016-05-07 10:34:44+00:00): что такое союзмультфильм?
Elbower (2016-06-09 05:55:45+00:00): Владимир, здравствуйте. Я приму к сведению ваши замечания. Однако по поводу данного объекта: вы были в этом месте? Здание церкви с колокольней - это, на ваш взгляд, бывший объект? То, что само здание не является действующим приходом, не значит, что оно не является культурным наследием и интересным местом для посещения. Разве не так?
Elbower (2016-06-09 16:49:37+00:00): https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D1%8E%D0%B7%D0%BC%D1%83%D0%BB%D1%8C%D1%82%D1%84%D0%B8%D0%BB%D1%8C%D0%BC