piebro/osm-data huggingface dataset:
ediyes (2016-04-29 19:22:04+00:00): Hi,
Thanks for the review, I will be more careful.
:)
freeExec (2014-12-23 06:34:52+00:00): Извини, конечно, но что за порнографию ты нарисовал http://savepic.su/4652771.png ?
4rch (2015-02-06 16:20:23+00:00): Why is the boundary of Helena obsolete? Please state out sources. Wikipedia states out that the boundary of Helena is correct: https://de.wikipedia.org/wiki/Helena_%28Montana%29 (Google shows also the boundary which you've deleted)

When you delete boundaries please delete them completely and not only partly. It is a mess, you've deleted only 50% of the boundaries and left the rest in the database.
lampropeltis (2015-02-06 16:58:53+00:00): You are correct in that the city boundaries you are referring to are in Google Earth when you check "More" in the layers window but there are alot of things that appear when that layer is checked that don't necessarily make sense to have in OSM. If you feel they are important of course I won't delete them going forward but in my view the Helena City boundary only obscures the highly accurate city landownership that added from our states cadastral system. The city boundaries are rough, highly innacurate, and serve little purpose by obscuring more accurate land ownership boundaries.
lampropeltis (2015-02-06 17:01:39+00:00): And, to top it off, those goofy city lines cut right through my back yard! :)

No offense. I'll leave them alone. Just a little defensive from the tone of your comment and wanted to make my case for removing them.

Cheers!
lampropeltis (2015-02-06 17:08:00+00:00): Allow me to state my sources and provide proof that these city lines are highly innaccurate. Please go to 46.593141 / -112.080665 in Google Earth. Make sure "More" is checked in the layers window. Now you can see the "City Boundaries" as a yellow line and the true city ownership boundary as a green line. I have verified this in the state cadastral system found at the following link: http://svc.mt.gov/msl/mtcadastral/

You can see how inaccurate and basically worthless the city boundary lines actually are.

Again, I'll leave them since you feel strongly about them but perhaps you would reconsider.
4rch (2015-02-06 18:45:42+00:00): Sorry for my tone, I've fixed about 30 other damaged boundaries before and was a bit annoyed.
I've compared the boundary with some sources on Lewis & Clark County’s website [1]. You get redirected to this site when you select "Maps" on the City of Helena website.
The sources are:
http://www.lccountymt.gov/fileadmin/user_upload/GIS/CompPlanMaps/PDF/Administrative/CityofHelenaZoning2014.pdf
http://www.lccountymt.gov/fileadmin/user_upload/GIS/CompPlanMaps/PDF/Administrative/HelenaHistCityLimits11x17.pdf
Shapefile "Helena City Limits": http://www.lccountymt.gov/it/gis-maps/download-data.html
As you can see there are no huge differences between the boundary in OSM and those mentioned above.

[1] http://www.lccountymt.gov/it/gis-maps/helena-county-atlas.html
berndw (2014-12-25 09:19:47+00:00): Hi
Du hast in diesem Changeset die Siebachstraße noch mal angelegt ;-)
Das habe ich korrigiert
Ansonsten viel Spass weiterhin
SomeoneElse (2014-12-26 20:05:08+00:00): The changeset comment here is just "fix cycleways".  Can you describe in a bit more detail what you've actually done?  In the case of http://www.openstreetmap.org/way/237210198/history you just seem to have removed one tag.  Have you contacted the mapper who originally added that tag explaining what you've done, so that they know who best to tag cycleways in the future?
Test360 (2015-01-08 22:11:23+00:00): Contacting the original mapper is unecessary, because the mistake is obvious.

"cycleway=left:track" has the same meaning that "cycleway:left=track". Thus, the tags are redundant. "cycleway:left=track" is the good one, thus "cycleway=left:track" should be deleted.

 The same mapper has added the good tag after adding the wrong one. Thus, this mapper already know how to correctly tag a cycleway.
SomeoneElse (2015-01-08 22:16:58+00:00): You said "Contacting the original mapper is unecessary, because the mistake is obvious.".  It may be obvious to you (and me) that the tagging is incorrect here - the point of contacting the original mapper is so that _they_ know that there was a problem (they clearly didn't know the original tagging was wrong at the time that they used it, obviously).  There's an English saying that applies here:

http://en.wiktionary.org/wiki/give_a_man_a_fish_and_you_feed_him_for_a_day;_teach_a_man_to_fish_and_you_feed_him_for_a_lifetime
Test360 (2015-01-08 22:38:16+00:00): I have said the sentence that you quote because I misinterpreted what you have said. Sorry for that.

I get what you say and I agree with you. I sometimes take the time to explain to a user a mistake that I have spotted. But for practical reasons, I can't do this each time.
osmsaj (2014-12-22 23:47:43+00:00): change to living-street, renamed "Privatstrasse"
DUGA (2021-03-25 02:42:12+00:00): way 318453984 removed
BAGgeraar (2024-11-08 15:33:08+00:00): Zou je eens willen kijken naar https://www.openstreetmap.org/node/46657766 ? Volgens mij zit er sowieso een typefout in removeable, ik denk dat de e weg moet. Maar klopt de locatie van deze verkeerspaal op de kruising van de wegen?
trigpoint (2014-12-24 10:08:51+00:00): Why did this need fixing?
Did you spot any serious errors when you visited Shrewsbury?
You have deleted and redrawn the regimental museum, amongst other things, why? In so doing you have destroyed the history and the contributions of other mappers which is very disrespectful.
pkoby (2014-12-24 13:22:51+00:00): Fair point. Editing may have been a better term. While nothing was seriously broken (routing issues, for instance), there were a lot of topological inconsistencies, so I made some changes to that. I apologize for deleting and redrawing the museum. I did not think about the history of changesets that would be removed. I will consider that in future.
trigpoint (2014-12-24 10:02:58+00:00): I didn't know it was broken.
However you have deleted https://www.openstreetmap.org/way/193924966, why?
The way contained information such as one way, bicycle dismount and made Pride Hill usable by pedestrian routers.
pkoby (2014-12-24 13:17:02+00:00): My apologies. I should have phrased the changeset comment differently. I also apologize for entering your mapping territory. I understand your comments, and I didn't think about the issues for routing it would create.

I have reverted the deletion of the Pride Hill way. If there are other issues, let me know.
arceyes (2014-12-23 01:42:52+00:00): 真溪中学
Skippern (2014-12-23 11:27:56+00:00): Favor adicionar comentario no seu conjuntos de edicao, e difícil verificar o que fui alterado se não ha.
DaCor (2014-12-23 10:13:54+00:00): Please limit your changes to smaller areas.  Given the amount of changes you made and the size of the area, it is impossible for local mappers to verify if your changes are correct. Your changeset comment is also very poor, what exactly did you fix?? I am seriously tempted to revert your changes or at the least escalate to the DWG. I await your response
zool (2014-12-23 16:18:02+00:00): This set of changes has by now been submitted to the Data Working Group for  examination.

This seems to be a set of "mechanical edits" changing one set of tags highway=noexit to noexit=yes on a programmatic basis.

However, we're not aware of any public discussion of these sweeping changes with potentially affected mappers or data re-users in the OSM community. Have these changes been discussed and if so can you provide a link?

If you look at the history of one of the nodes included in this changeset, you'll see the same sweeping change was made by another mapper about 9 months ago, and reverted on the ground that it hadn't been subjected to a public discussion. 

https://www.openstreetmap.org/node/589526422/history

On behalf of the DWG, I look forward to hearing more about this changeset.
Test360 (2014-12-24 00:54:55+00:00): These two attributes :
* highway=noexit
* noexit=yes
have obviously the same meaning (check the wiki page of the Key:noexit).

the Key:noexit is heavily used (340 000 according to taginfo), highway=noexit is rarely used (150: 0,04% of the key:noexit).

Moreover, highway=noexit is undocumented. The OSM wiki does not have any reference to this attribute.

So, according to these facts, I have changed highway=noexit to noexit=yes.

This improvement to the OSM database seems so obvious to me that I didn't consider to have a public discussion about it.
DaCor (2014-12-24 01:27:44+00:00): The reasoning behind the change seems perfectly logical. If your nick showed up in my feed and I was able to see your change for what it was then there would be no issue as far as I am concerned. However the problem is the size of the area your changeset bounding box covers. It means I can't do a quick validation of an edit done by a user not local so I have to do extra digging, leave changeset comments etc. The end result, a lot of irritation and wasted time by all involved. Please keep this in mind the next time you plan on making fixes. Just for the record I agree with the fix you made here, but next time consider local mappers who monitor edits
SomeoneElse (2014-12-24 12:25:45+00:00): Note that this appears to be one of a series of mechanical edits, in some or even most of which information has actually been lost.  See http://www.openstreetmap.org/changeset/27658932 as an example.
Talitha IRM-ED (2021-05-06 03:37:03+00:00): Hi, folkn. I adjusted this tertiary road 318473665 (https://pewu.github.io/osm-history/#/way/318473665) based on Maxar Premium Imagery (Beta). Thank you
SomeoneElse (2014-12-23 13:43:27+00:00): What possible extra information does "seamark:type=cable_submarine" add to something like http://www.openstreetmap.org/way/78434602/history that is already mapped as "communication=line; submarine=yes"
mentor (2014-12-23 13:54:03+00:00): The seamark tag is part of the seamark specification on the wiki.
zenfunk (2014-12-23 14:11:17+00:00): This conforms with the tagging scheme that is advocated by the Openseamap project. 
I know you should not map for the renderer, but only with a seamark:type= something the Openseamap renderer will start to render stuff. The Openseamap renderer is very not very flexible and seems to need these tags to work. The Openseamap tagging scheme is not very OSM like, but it is actually quite wide spread. http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Objects
SomeoneElse (2014-12-24 15:23:58+00:00): It'd be a shame if the OpenSeaMap renderer couldn't render "ordinary OSM tags", if there already a form of tagging for that thing in OSM already.  Tagging something as both "foo=value" and "seamark:foo=value" is obviously a duplication when the value is the same, and leads to the possibility of contradictions (if e.g. a value changes, will ordinary mappers know to change "seamark:value" as well?).  Is there a bug tracker for the seamark renderer anywhere where these issues can be discussed?
zenfunk (2014-12-24 22:57:12+00:00): You could try their mailing list:
https://lists.sourceforge.net/lists/listinfo/openseamap-develop , in the past there have been a lot of discussions about exactly that topic, but well, in the end this monster of a tagging scheme is what came of it :-(. 

You basically have to install a JOSM plugin (Seamap editor) to edit those things. 

OTOH, the marine mapping stuff really is complicated and manual edits of e. g. a light house is next to impossible. Sometimes there are more than 10 tags to describe the light alone. The tower itself then is another item alltogether. Marine mapping became actually very sophisticated over the centuries.
SomeoneElse (2014-12-28 14:41:05+00:00): Thanks - I'm guessing that the issues list might be https://github.com/OpenSeaMap/online_chart perhaps?
sergeybe (2015-03-28 04:51:25+00:00): В этом месте нет никаких пеших дорожек. OSM не место для добавления несуществующих объектов. Используйте http://www.gpsies.com/ для ваших треков.
4rch (2014-12-30 01:22:31+00:00): This is the 12 nautical miles boundary of Vietnam. I've restored the boundary.
alphensebezorger (2016-08-29 17:01:57+00:00): This changeset lowers the maxspeed at night to the same value as valid during the daytime (between 6 am and 7 pm). Was this intentional? The conditional maxspeed was not removed, which makes no sense to me, as it is now identical to the default value.
5m4u9 (2014-12-24 05:04:57+00:00): thanks for update info! Consider upgrading Osmand to v.1.9.4!
Maskulinum (2014-12-27 21:44:22+00:00): Hallo Matrix, die Kreuzung wurde in diesem Änderungssatz leider extrem verkompliziert. Besser wäre es gewesen hier mit dem lanes-tag und turn:lanes-tag zu arbeiten.
Möchtest du es ändern oder soll ich mich ran wagen? Grüße Maskulinum
Maskulinum (2015-01-10 18:09:35+00:00): Habe die Kreuzung nun korrigiert.
SomeoneElse (2014-12-23 13:55:24+00:00): Hello, this appears to be a mechanical edit of a large number of shops based on shop name.  In some cases the shop tag has been changed, for example:

http://www.openstreetmap.org/node/1784628850/history

In the cases where you've changed the shop tag from one perfectly valid shop tag to another, have you verified by an on site survey that the new shop tag is correct?

In cases where you've changed the spelling such as http://www.openstreetmap.org/way/120036342/history have you discussed the spelling change with the previous mapper so that they know to update their maps?  This is not a theoretical question; in this particular example the previous mapper _does_ maintain a map of the area and one of the overlays is local retail.
Syl (2014-12-23 20:52:08+00:00): Hello, 
I have manually edit a lot of video games shops because sometimes they are mapped with a wrong shop tag (electronics, computer, hifi, toys...) or are misspelling.
Sometime I check on shop site. For exemple, all GameStop  shops should be video games shop.
I don't understand your last exemple.
SomeoneElse (2014-12-24 11:40:21+00:00): Re the "manual editing" - have you actually surveyed (i.e. visited) each of these shops to make sure that they're part of the same video game shop chain, and are not e.g. an unrelated toyshop called "GameStop"?
SomeoneElse (2014-12-24 11:44:56+00:00): Re the second point (presumably you were referring to http://www.openstreetmap.org/way/120036342/history ) there are two reasons why it is important than mechanical edits are discussed before being carried out.  One is so that the previous mapper knows that they've used a tag that means the same thing as another key but is spelt differently (e.g. video_game vs video_games).  The other is that people do actually use this data - they might have code somewhere that looks for "video_game", and if you change the tag without telling people, things will disappear from their extracted data or map without them knowing why.  That is why https://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy has "Discuss" as the first requirement.
tuxayo (2014-12-23 14:18:05+00:00): This is a test

Of the formating of the comments
https://www.openstreetmap.org/changeset/27649048

This was a test link
tuxayo (2014-12-23 14:18:54+00:00): This is a test


Of the formating of the comments
https://www.openstreetmap.org/changeset/27649048


This was a test link


I hope line will be more separated this time
tuxayo (2014-12-23 14:20:20+00:00): This is a test
--
Of the formating of the comments
https://www.openstreetmap.org/changeset/27649048
--
This was a test link
--
I hope line will be more separated this time
tuxayo (2014-12-23 14:23:40+00:00): https://www.openstreetmap.org/changeset/27649048#djgfdijgfdigjfdigjfdijgfdigfdggfdgfdgfdgfdg
Yey another test because It's hard to format long message in comment but I need to # bla balb balvbbez fgfdgfdsgfd gfdg
--
https://www.openstreetmap.org/changeset/27649048#djgfdijgfdigjfdigjfdijgfdigfdggfdgfdgfdgfdg
Yey another test because It's hard to format long message in comment but I need to
--
tuxayo (2017-07-23 01:41:38+00:00): Encore un test formatage des commentaires des changeset.

J'ai sauté une ligne, on va voir ce que ça donne.
Didoa (2014-12-23 12:22:38+00:00): Dobry den prajem, len pre zaujimavost, co predstavuju tieto koeficienty ?  Dakujem.
saintam1 (2014-12-23 15:24:26+00:00): What is the full address for this block, is it zh.k Studentski Grad bl.10, or bul Dimitrov bl.10, or ul 21-vi vek bl.10, or something else?
daPainkilla (2014-12-23 16:32:36+00:00): well it's just kv. Vitosha, bl. 10,  the street is new and as far as i know unnamed, all the buildings on the street are named as blocks in kv. Vitosha
eiger (2014-12-23 20:41:35+00:00): Il y a un problème dans ton changeset 27650106. Tu as supprimé le "landuse=cemetery" et conservé "name=Cimetière". J'imagine que tu voulais faire l'inverse. Merci de corriger.
Test360 (2014-12-24 01:18:46+00:00): Tout à fait. J'ai corrigé. Merci.
malenki (2014-12-23 20:38:47+00:00): Stellte gerade fest, dass ich das Changeset nach dem Revert in Berlin nicht geschlossen habe – und die nächste Änderung auch noch darin gemacht habe…
EugenyN (2015-04-20 10:50:46+00:00): тут видимо не клиф
keder (2015-04-20 11:35:13+00:00): По всей видимости да, просто хотелось выделить както необычный объект, у него вершина вроде плоская, редко такое вижу.
EugenyN (2015-04-20 12:56:39+00:00): интересно. жаль в гугле фотографий найти не получилось
keder (2015-04-20 13:36:29+00:00): В викимапии одна фотография есть, была бы машина съездил бы посмотреть что это за чудной объект
EugenyN (2015-04-20 13:46:37+00:00): посмотрел в викимапии...интересная штука.
Rockus (2015-09-09 10:19:40+00:00): Hallo Maper,

in diesem und mehreren weiteren Änderungssätzen trägst Du Rettungspunkte auf sächsischem Forstgebiet ein. Aus welcher Quelle stammen die Daten dazu oder sind die Rettungspunkte selbst erfasst?
Im Jahr 2014 gab es bereits eine Anfrage zur Datenübernahme an den Staatsbetrieb Sachsenforst, die klar ablehnend beantwortet wurde. Siehe http://wiki.openstreetmap.org/wiki/DE:Permissions dazu.
nuxper_np (2015-06-07 12:16:47+00:00): Bonjour,

J'essaye d'ajouter les noms de rue dans Andard. Je remarque que la disposition de l'Allée Ambroise Paré est différente sur les photos satellites et ce que vous avez cartographié en décembre.

En effet, sur l'image satellite bing, l'Allée Ambroise Paré semble etre une voie sans issue au du batiment numéro 2, continuée par un jardin.

Dans la disposition que vous avez entré dans OSM, l'allée est connectée a la Place des Andégaves.

Je me permet de modifier la cartographie telle qu'observé sur l'image satellite. 

Si les modifications provenaient en fait d'une observation terrain, veuillez m'en excuser et ne pas hésiter a annuler la modification. Il est recommandé dans ce cas d'ajouter une clef source=survey. Cela indique aux autres editeurs que la source d'information est plus fiable qu'une image satellite / le cadastre.

Cordialement
Zbigniew_Cz (2014-12-23 16:17:49+00:00): a do ronda dodajemy junction=roundabout ;-)
kocio (2014-12-23 16:18:48+00:00): Nie wiedziałem - dzięki! =}
SomeoneElse (2014-12-24 11:54:22+00:00): Your changeset comment here suggests that the parking sub-tab is obsolete.  Can you point to where the discussion about that took place, please?
Test360 (2014-12-24 14:11:31+00:00): As specified in the source of the changeset, this information is in the OSM wiki.
http://wiki.openstreetmap.org/wiki/Proposed_features/Park_and_Ride 
"Status: Obsoleted (inactive)"
SomeoneElse (2014-12-24 14:17:21+00:00): That just means that someone who was following a proposal through on the wiki decided to stop doing so (back in November 2008, as far as I can see).  It doesn't mean that it's OK to change the tags on all the features that people have mapped in the last 6 years.

There are a number of reasons why https://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy says "Discuss" as the first step - one is so that mappers are aware of alternate taggings for something (and just because someone's updated a wiki page it doesn't mean that it's "accepted" tagging).

Also note that you changed "parking=park_and_ride"; the wiki page that you refer to was actually about "amenity=park_ride" - a completely different tag.
rab (2014-12-23 21:49:55+00:00): Hallo,
Am nördlichen Ende stimmt mit den Oneways was nicht. 
Hier muß wahrscheinlich noch ein motorroad=yes + lanes=2  drann.  
https://www.openstreetmap.org/way/318548265
Im Bereich des Tunnels fehlt auch noch lanes=2
B 256 ist nicht "name" sondern nur  "ref"
wernerhxxx (2014-12-26 10:53:05+00:00): Stimmt. Danke fürs Ändern.
rickmastfan67 (2014-12-24 04:59:19+00:00): Test comment request via GitHub. https://github.com/openstreetmap/openstreetmap-website/issues/860#issuecomment-68004445
Polarbear (2014-12-24 10:40:00+00:00): Email notification received, thanks.
SammysHP (2015-02-28 20:19:35+00:00): Könntest du bitte natural=cliff durch man_made=embankment o.ä. ersetzen? Klippen gibt es hier nicht, nur kleineres Gefälle. Gilt für das gesamte Gebiet, also ggf. auch andere Änderungssätze.
Polarbear (2014-12-23 21:30:33+00:00): test
surveyor54 (2014-12-23 22:46:13+00:00): Den Hydranten nur Namen vergeben, wenn der Hydrant auch wirklich einen Namen hat.
http://wiki.openstreetmap.org/wiki/DE:Tag:emergency=fire%20hydrant?uselang=de
Wenn dem so ist, kann es bleiben. Sonst bitte wieder löschen.
Gruß
surveyor54
SomeoneElse (2014-12-24 12:00:19+00:00): You have removed the "natural=swamp" tag from http://www.openstreetmap.org/way/134760983 .  Was this as a result of a survey?
Test360 (2014-12-24 14:44:24+00:00): No, this is the result of the Bing imagery.
SomeoneElse (2014-12-24 14:59:38+00:00): Looking at the imagery, that does look quite a stretch.  What's certainly true is that the ways that are mapped there don't really match the imagery at all well.  In cases like this, perhaps an OSM note would be the better option, rather than just arbitrarily changing the tagging?  That way local mappers can see that something there "isn't quite right" and go and have a look on the ground.
dforsi (2014-12-23 21:00:57+00:00): Hai inserito un sentiero senza collegarlo alle strade esistenti per cui è inutilizzabile per il routing. A sud l'ho collegato io, a nord collegalo tu e dalle foto di Bing l'ultima parte sembra track invece che path.
Nota anche che di solito non si buttano dentro tracce GPS senza ripulirle (magari usando lo sfondo di Bing) perché le tracce GPS sono piene di rumore.
SomeoneElse (2014-12-24 12:08:33+00:00): You've changed http://www.openstreetmap.org/way/191683850/history from "natural=woodland" to "landuse=forest".  How do you know that landuse=forest is the appropriate tag here and not, say, natural=wood?
Polarbear (2015-02-23 14:11:40+00:00): Why do you assign street names to private driveways into a property?
SomeoneElse (2014-12-24 11:46:28+00:00): Re http://www.openstreetmap.org/way/47328415/history how did you know that "landuse=forest" and not "natural=wood" was the appropriate tag here?
SomeoneElse (2014-12-24 12:16:52+00:00): Also, in your change to http://www.openstreetmap.org/way/76823138/history you seem to be under a misapprehension that a deciduous tree is necessarily broadleaved.  It isn't - see http://en.wikipedia.org/wiki/Larch .
Test360 (2014-12-24 14:34:08+00:00): "landuse=wood" tag is commonly used by mistake. So, "landuse=forest" is a more appropriate tag.
Test360 (2014-12-24 14:37:35+00:00): "natural=wood" may be more appropriate, but it seems dubious that it's an ancient or virgin woodland.
iWowik (2014-12-24 14:43:02+00:00): You are wrong and vandal "natural=wood" is appropriate for any type of group of trees!
Test360 (2014-12-24 14:49:34+00:00): iWowik : the OSM wiki does not say at all that "natural=wood" is appropriate for any type of group of trees.

Please watch your language and do not call me a vandal.