piebro/osm-data huggingface dataset:
rbuch703 (2015-03-25 18:55:00+00:00): So are you saying that for every single change to every single tag that isn't an obvious typo, there has to be a discussion beforehand? In accordance with the first point of the OSM Editing Good Practices ("If you find elements with tags that you think are wrong then do correct them. OSM similar to wiki [sic], your corrections can always be reverted, so be bold."), I was assuming that the usual way to correct potential problems is *without* having to contact anybody. My assumption was (and still is), that dialog is only necessary once actual conflict arises, i.e. when two or more mappers are in expressed disagreement. 

Is there any OSM document that outlines that your suggested process ("ask before you change anything") is the suggested or required standard for OSM?
SK53 (2015-03-27 15:04:49+00:00): There are several simple rules of thumb which you ignored:

1. Am I improving the semantic value of OSM by changing a tag. Moving something to a note does not do so.
2. Has the tag been accepted by other mappers. In this case several mappers had made changes to the object without changing the maker key.
3. If it aint broke dont fix it.
4. If the meaning of a tag is obvious (as this one is) and you do not know of a more widely used alternative leave it alone.
5. If you are not clear about the intentions of the original tagger, ask them! That's why we have a messaging system & changeset comments.
6. Local knowledge and mapping things by visiting places results in better mapping than global edits. Informing people in an area of possible alternatives to tags they use, helps everyone.
7. Tags with low usage numbers are not intrinsically wrong, just not used very much.
augxcgrwxo (2015-03-26 17:56:17+00:00): Спасибо за огромную работу по этому поселку!
klinenok (2015-03-27 04:56:26+00:00): Пожалуйста :)
Self-Perfection (2015-03-25 16:11:45+00:00): POI плачут и страдают, когда у них нет opening_hours...
darkwish (2015-03-26 10:36:34+00:00): Увы, эти обречены (
Стараюсь не доставлять POI'ям страданий.
Но не всегда это получается (
stevea (2015-04-08 00:06:08+00:00): Looks like you cracked open (disconnected) a (rather admittedly complex, I will concur) landuse=conservation multipolygon while editing around Camp Ben Lomond and Empire Grade a couple of weeks ago.  As one of the original authors of this, I have fixed it.
shravan91 (2015-04-08 07:36:16+00:00): Thank you Stevea for the edit. I was working on the road connection and forgot to look at the polygon. Next time, I'll make sure that I don't make the same mistake again.
stevea (2015-04-09 19:52:30+00:00): Not a problem, took me just a couple of minutes.  Thanks for your cooperation and good attitude.  Go OSM!
jgpacker (2015-03-25 17:05:47+00:00): Oi, não seria "Bloco" em vez de "Boco" nesses edifícios do Centro Universitário Tupy?

Ah, e uma dica: Não precisa repetir "Centro Universitário Tupy" em cada edifício. É preferível que seja criado uma área para a universidade que engloba todos os edifícios. Veja a área da UDESC Joinville por exemplo: http://www.openstreetmap.org/way/263290462
lucas_ (2015-03-26 01:17:26+00:00): Olá,
Obrigado pelas dicas!!
Já corrigi os erros de grafia e adicionei alguns edifícios e caminhos.
Em seguida, definirei a área universitária.
emacsen (2015-03-25 20:27:30+00:00): While this information is true (most of the NE corridor tracks) allow for speeds about 120mph, not all do. I know because I was just on Acella a few days ago on this very route and sometimes we were going >100mph, and then in the middle of the journey, we dropped to ~30mph, around bends and populated areas. Other travelers said this was normal for this route.

You say Amtrak is the source. Where does Amtrak specify which tracks do and don't have highspeed access?
emacsen (2015-03-26 01:53:29+00:00): Steve, you sent me an email, but I want to keep all conversations public. Please specify the source for where you say that these track ways are high speed compatible. Based on my experience, some are and some aren't.
emacsen (2015-03-26 02:07:04+00:00): In addition to Amtrak, you're also saying that some Metro-North rails are high speed. Please tell me where you can tell which rails are being replaced with high speed capable rails, because I haven't heard that they've completed that renovation universally. In other words. So what is your source?
emacsen (2015-03-26 03:57:45+00:00): Steve,

I'd request that you please stick to the discussion at hand, which is the issue of the track data.

I'd also ask that you please keep a civil tone and not use condescending language, such as telling someone to "relax".

To the substance of your email, as you say, the tag is for objects, not routes, and you're tagging the tracks as high speed. Unless you know if a tag is high speed, then it shouldn't be tagged as such. The issue regarding the rendering of that tag is separate, and goes to OSM's general policy of not tagging to the renderer (http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer).

Will you please correct your tagging on these objects to reflect which track segments are high speed and which aren't?
stevea (2015-03-26 05:54:24+00:00): Serge, the discussion at hand is:  Amtrak says Acela uses the Northeast Corridor.  Amtrak says Acela is highspeed.  I have put 2 and 2 together and come up with 4:  the tracks of the NEC are highspeed, because they support highspeed service, exactly as the tag is documented.

There are different tags which specify the maximum speed for each individual track segment, for example, where a speed limit sign actively changes the maxspeed.  As I do not have knowledge of these, I have not added those tags.

I do have knowledge of the NEC being a highspeed line:  Amtrak tells me so.  Our minds allow deduction, the inference of a particular instance by reference.  There are examples of this deduction all over OSM.

Steve
stevea (2015-03-26 17:20:59+00:00): Addressing Serge's specific request to "correct (my) tagging on...which track segments are high speed and which aren't," I continue to assert that ALL of the track segments of NEC are high speed.  Again, this particular tag (highspeed=yes) is a correct answer to the semantic of the tag:  "Is this a highspeed line?"  Amtrak says Acela is, Acela runs on NEC, ipso facto, NEC is a highspeed line, therefore tagging highspeed=yes on the segments of track infrastructure which make up the entire line is correct.

Once again, this is NOT the same thing as saying that a particular segment of track (e.g. through a town or on a tight curve) means that trains will travel over it at high speed.  It DOES mean that trains which travel on the line it belongs to CAN travel at high speed on that line.  This is similar to tagging an entire Interstate highway=motorway even though a driver could reasonably enter at one access point, travel at 5 MPH in stop-and-go traffic, get frustrated and exit at the next access point.  That segment of (and the entire infrastructure of Interstate) is still highway=motorway, capable of high speed travel, high speed travel just doesn't always happen.

And again, it is the maxspeed tag (of which I have no knowledge on NEC, so I haven't tagged with maxspeed there) which indicates which rail segments allow particular speeds.  That is likely a much better tag to consult when you find your Acela experience to involve both high-speed and low-speed travel.  Not the highspeed=yes tag, which simply says that the LINE of which this rail segment is a member is capable of supporting high speed route=train service.  In the case of NEC, that is true, hence the tags.

Thanks to your request that I re-read Tagging_for_the_renderer, I did:  I find nothing there to contradict my correct tags.  In fact, the last section (Clarification) actually supports me.  It says "if a specialist map renders a particular specialist tag...then using the tags the renderer understands is a perfectly reasonable thing to do."  I agree.
RussNelson (2015-04-01 04:47:33+00:00): Serge, Amtrak says that it's a high speed route, so ... it IS a high speed route. If you know how Amtrak signs the NEC speeds, you should tell the rest of us, because I don't know.
emacsen (2015-04-01 10:04:16+00:00): Russ, the issue is that individual tracks are tagged as high speed, not a single route. That indicates to me that the tracks must therefore be high speed capable, and many are not.
stevea (2015-04-01 19:23:17+00:00): Serge, individual tracks are tagged this way because that is how the tag is documented:  it means the LINE of which this rail segment is a member is capable of supporting high speed route=train service.  So, it is correct.  (I repeat myself here, not a good sign).

Are there individual track segments which do not always see a particular train (even an Acela), traveling at high speed?  You say yes.  However, that does NOT contradict that the tag is being used properly as it is documented, which it is:  as a MEMBER of a LINE which SUPPORTS high speed route=train service.  There are numerous examples of these in OSM.  But only one in the USA:  this one.  And it is tagged as are other high-speed rail lines, because IT IS ONE.

If you wish to see "more accurate" tagging on this rail line, please enter maxspeed= values where you know them.  I greatly encourage that task.
emacsen (2015-04-01 20:46:58+00:00): Steve, if you want a route to have a specific tag, that's fine, use a relation and apply the tag to that route as a whole.

By tagging each way, you are saying "This track is high speed capable", which isn't true for some of these ways. I don't know which tracks are high speed capable and which aren't, other than by my observation having taken this route that the train seems to slow down during certain times, and speed up during others (all while the train being on schedule). I also know that the news reports that Amtrak wants to upgrade tracks alone this route to make them high speed capable.

If you can find out which tracks are high speed capable and which aren't, then that would be wonderful, but until we have that, please stop tagging individual ways with these tags saying that they're capable of high speed travel.
pnorman (2015-04-01 21:01:17+00:00): That Amtrak wants to upgrade the track makes it pretty clear to me that not all of it is high speed, and the limit on portions is not high speed. The UK is probably the best place to look for how this is tagged, as there's plenty of segments of track which are not high speed capable.

If there is both a high speed route and a low speed route along a section of line, do you then up tagging that it is both high speed and low speed?
woodpeck (2015-04-01 21:13:41+00:00): Wikipedia says that "Much of the [NEC] is built for speeds higher than the 79 mph (127 km/h) allowed on many U.S. tracks." - this implies that some of the NEC is not usable at high speed. I wonder how, in SteveA's understanding, these should be tagged? Surely it must be possible to record that information somehow? -- I agree with emacsen that you should not armchair-tag a railway track as highspeed=yes based solely on the information that it is used by a train line advertised as a high speed train.
stevea (2015-04-01 21:57:31+00:00): To Paul's comment:  Amtrak's "upgrades" are intended to make an already-exists high speed line into an EVEN HIGHER speed line.

To Frederick's comments:  a "more correct" way to capture that certain segments of rail have a limiting speed is with a maxspeed tag.  I welcome these, as then ORM's Maxspeed style would show what Serge both wants to see and experienced on the train in person.

I am in email contact (today, actually) with Michael Reichert (one of the authors of ORM) awaiting answers to several questions, among them whether tagging a route=train with highspeed=yes will render.  If it will, I will happily change tagging to do that, removing them from the infrastructure.  However, it may be that because of CSS limitations on relation rendering, it will not work.  I may also experiment with this without waiting for an answer from Michael.

If this (tagging the route=train relation) does not work, I stand by what "Tagging_for_the_renderer" states:  "If a specialist map renders a particular specialist tag...then using the tags the renderer understands is a perfectly reasonable thing to do."

Frederick, as I look at high speed rail in UK, it is as I suspect:  the highspeed=yes tag is on the rail element, not the relation.  However, there is a "service=highspeed" tag which may render in ORM (though I doubt it).  I can experiment with this service=highspeed tag on the Acela route=train as well.  But if it doesn't work, nor if putting highspeed=yes on the route=train relation works, then I really must do what the whole rest of the world does in OSM to tag high speed rail that renders in ORM:  tag each element of the railway to which it belongs (NEC in this case for Acela) as highspeed=yes.  Just as ORM documents, just as other highspeed lines in the world are tagged.
Nakaner (2015-04-02 09:06:54+00:00): Up to now, there has not been reached any consensus among the railway mappers where to tag highspeed=yes and where not. There is one debate what the minimum speed should be (> 160 km/h, >= 160 km/h oder >= 200 km/h) or if there should be any world-wide minimum speed. For comparison, although we tag railway=narrow_gauge, narrow_gauge has a country-dependent maximum gauge (4 feet in Europe and US, 3 feet in Japan). ######################## The second debate is about how to handle low-speed sections on high-speed lines. Should the tracks in Fulda station tagged highspeed=yes although the speed limit is 100 km/h (250 km/h outside)? http://www.openrailwaymap.org/?lang=de&lat=50.55652465046649&lon=9.690048694610596&zoom=15&style=maxspeed Should the last kilometres from a dedicated high-speed line to the station tagged highspeed=yes although the speed limit is low (100 km/h is not a high speed). http://www.openrailwaymap.org/?lang=de&lat=49.44688165722464&lon=11.10892653465271&zoom=16&style=maxspeed ######### OpenRailwayMap does not render any route relations at the moment and it is not planned to do so in near future. Infrastructure route relations (route=railway) will be rather used for line diagramms like the ones in lots of Wikipedia articles. https://en.wikipedia.org/wiki/West_Rhine_Railway ###################### Public transport route relations (route=train/tram/…) are not used and won't be used because OpenRailwayMap is a infrastructure map.
stevea (2015-04-07 18:02:44+00:00): And there you have it from one of the authors (and a true rail expert from an OSM tagging perspective):  "there has not been reached any consensus."  What this says to me is that we have a bit of a tempest in a teapot here.  Especially as other lines (in Europe, Asia) are tagged as I have tagged NEC (highspeed=yes along the length of the infrastructure), signifying that track segment is part of a high speed line.

To show my continuing good faith and hopefully to assuage the situation somewhat, I have applied a few maxspeed= tags on those sections of NEC track where its Wikipedia article (footnote 64) allows me to determine these.  These are displayed using ORM's Maxspeed style (radio button).  They begin to yield a more comprehensive OSM visualization of the changing speeds that Serge experienced while riding the Acela.  These are early data, but they are all I am easily able to determine now, and I encourage more maxspeed= tagging where it is known.
emacsen (2015-04-07 18:12:33+00:00): > signifying that track segment is part of a high speed line.

There's no evidence of that from what I read.

> To show my continuing good faith and hopefully to assuage the situation somewhat

Why don't you just do what everyone can agree is correct, and tag the route, rather than the individual ways? The route is absolutely high speed, but when you say the tracks are, that's where there's a disagreement.

To me, a track that's labeled high speed is like a road that's labeled max_speed.

Saying the route is high speed makes sense, but these individual tracks... I can't get behind that.
stevea (2015-04-07 18:29:29+00:00): The route (Acela Express, route=train) already is marked high speed, with the service=high_speed tag.  This is precisely how ORM tagging instructions say it should be done.  The tag is not applied (again, exactly as instructed) to the route=railway (NEC) relation.  This is because ORM's tagging sections of Railway Route and Train Route do not document to put a high_speed tag on the former, but to one should put a high_speed tag on the latter.  So, that has been true for some time.

I hear you when you say you object to each element of track being labelled highspeed=yes.  Again, the world over already does this on several (dozens?) of high speed train rail infrastructure segments to indicate that these segments are part of a high-speed line.  I am merely following their lead.  Do you object to those as well?

As 1) this is already done the world over, 2) the author of the primary renderer for this tag says (effectively) "no clear consensus yet" and 3) Tagging_for_the_renderer wiki's Clarification section supports me, my determination to leave these tags in place seems OK.

Finally, a road (highway) with a maxspeed tag (let's say it is 65 mph, because of posted signs that say so) doesn't mean that cars will always travel over it at 65 mph.  They might travel over it at 75 mph (and violate the Vehicle Code) or they might travel over it at 5 mph in heavy traffic (as was the point of my earlier effort to point this out).  However, the maxspeed tag of 65 mph remains correct on that road, doesn't it?  Yes, it does.
woodpeck (2015-04-07 18:40:27+00:00): What is the practical use of a railway track marked highspeed=yes when this duplicates information from a relation? Is OpenRailwayMap unable to make the link between the relation and the track? -- Your maxspeed argument misses the point. If a road is tagged maxspeed=65 then I can legally go at 65 unless traffic or weather prohibit it; however what we're discussing here is sections of track that cannot be legally used at high speed but are still tagged as such.
stevea (2015-04-07 19:04:53+00:00): Yes, as Nakaner (and ORM tagging) document, ORM truly IS unable to "make the link between" (render) the relation, UNLESS the track is so tagged.

AGAIN, (I repeat) AS IT IS DOCUMENTED, the "highspeed=yes" tag literally means:  "Is this line a high-speed line?"  Emphasis on the LINE to which that track segment belongs.

An analogous situation we seem to be touching upon (with our motorway example having a maxspeed=65 mph tag) would be if an Interstate highway had segments within it which were not quite up to Interstate highway standards.  For example, perhaps a few km were highway=trunk instead of highway=motorway.  In that case, AASHTO would not grant full Interstate status to that highway (or specifically exclude that segment, as is I-210 and CA-210 in southern California).  But the difference is that Amtrak regarding conferring "high speed status" is not as strict as AASHTO is at conferring "Interstate status."  In the latter case, the higher-class tag should not be applied, as the official designation has not been granted.  But in the former case (Amtrak saying Acela on NEC is high-speed), the official designation HAS been granted.  Ipso facto, the tracks can be (and should be) tagged with highspeed=yes, as each track segment meets the documented definition:  "Is this line a high-speed line?"
Nakaner (2015-04-07 19:12:07+00:00): I suggest following temporary compromise between you as long as there has been no consensus about highspeed=yes found: highspeed=yes may only be tagged on those tracks which can be used with a speed greater than 100 mph (160 km/h). The usage of highspeed=yes on relations is not affected by this compromise.
Nakaner (2015-04-07 19:14:58+00:00): I think that argueing here a longer time will not lead us to a consensus. It will only cost valueable time of each of us. Please continue this debate either at ORM or Tagging mailing list. (Tagging is suitable in this case because it is not a topic where people have to have much knowledge about signalling, workrules etc.)
stevea (2015-04-08 02:43:10+00:00): It isn't too far a stretch to say NEC is "somewhere between orange and red."  Subtle, huh, yeah, I know.  As we best know how to tag.
stevea (2015-04-09 00:40:40+00:00): In changeset 30077144, I have deprecated the highspeed=yes tags from all NEC segments.  However, previous changesets have set maxspeed= tags.  As a net result, on segments where maxspeed>=160, highspeed=yes is "back" to being set.  These segments include the great majority of the NEC, absent primarily around Newark, New York City and New London and between New Rochelle/New Haven.
stevea (2015-04-10 16:55:22+00:00): OpenRailwayMap's Infrastructure and Maxspeed styles now render these changes accurately.  I consider this resolved.
Nakaner (2015-03-25 11:01:46+00:00): Ergänzung: Als Quelle wurde auch die Bahnhofskategorienliste der DB verwendet.
GerdP (2016-01-08 07:58:50+00:00): Hallo!
Du hast einen Weg mit dem seltenen highway=ramp gemappt. Ist das ein "behindertengerechter" Zugang?
Dann passt highway=footway + wheelchair=yes
besser.
Nakaner (2015-03-25 15:39:56+00:00): danke
Harry Wood (2015-03-25 15:19:35+00:00): We need a twitter <-> changeset discussion link :-) https://twitter.com/gregorymarler/status/580746665524662274
LivingWithDragons (2015-03-30 12:57:21+00:00): "Drat, I've just deleted Bishop Langley." was thankfully just a reference to my local copy of the data which was open in QGIS.
edward17 (2015-03-25 16:49:54+00:00): Разве Ж/Д депо - это landuse=industrial, а не landuse=railway?
http://wiki.openstreetmap.org/wiki/Tag:landuse%3Drailway
trolleway (2015-03-26 08:13:01+00:00): Вобще точно не знаю
Rainero (2017-03-27 20:26:42+00:00): Hier beim Weg 46790962 und einigen weiteren bekommen ich in JOSM Fehler angezeigt, weil tracktype=grade2;grade3;grade4 oder andere Kombinationen von grades getaggt wurden.
Ich denke, wenn sich der Grade im Verlaufe des Weges ändert, müßte man ihn in Abschnitte aufteilen.
Ich vermute, iD wirft bzw. warf bei solchen Tags keinen Fehler.
Mangels Ortskenntnis kann ich das jetzt nicht ändern.
ksharma198 (2015-03-25 13:34:12+00:00): Added new location
shura0 (2019-12-13 13:14:51+00:00): Привет.
А откуда ты тут родники срисовал? Там не было данных о том, можно ли из них пить?
KoraxDC (2016-06-21 07:20:42+00:00): Добрый день! Обозначаю стройку на месте парковок http://stroi.mos.ru/construction/1417
Адрес объекта и карта указывают на название "1-й стрелецкий проезд". Но как я понимаю исправляли не зря. Попробую сегодня уточнить, но предварительно предлагаю заменить Переулок на Проезд.
KoraxDC (2016-06-21 07:32:04+00:00): Upd. Посмотрел на своих утренних фотках, на указателях написано именно переулок. Вопрос снимаю)
catoblepa (2015-03-25 18:02:47+00:00): Ho annullato il changeset; come vi ho spiegato il nodo non andava necessariamente cancellato.
catoblepa (2015-03-25 18:05:05+00:00): Ho annullato il changeset, il nodo non andava necessariamente cancellato.
dudka (2015-03-25 17:03:41+00:00): Please revert this changeset since it corrupted hundred of ways.
Why(and how) did you add this node http://www.openstreetmap.org/node/1895314979 to so many ways?
dudka (2015-03-25 17:11:28+00:00): I've reverted it.
abel801 (2015-11-16 15:00:37+00:00): thank you for reverting my errors.
neiljp (2015-03-26 12:30:39+00:00): Is this a kind of business or shop?
fra76mm (2015-03-27 08:15:52+00:00): It's a building where some companies have their offices.
https://www.google.it/search?q=%22the+exchange%22+aberdeen&ie=utf-8&oe=utf-8&gws_rd=cr&ei=iBEVVcSCJqaCzAOSp4GACA
SomeoneElse (2015-04-10 15:04:10+00:00): Hello and welcome to OpenStreetMap!  Just for info, you've moved the node that is part of the river, but in the editor ("Potlatch 2") you're using that won't automatically join it to the stream to the north - you'll need to click on the stream, delete the node at the end of it, and then extend it to join the river for that to happen.
Cheers, Andy
burtdakarax (2015-04-11 05:11:26+00:00): Thanks Andy, I will have a go.