Again, the last part is a limitation of OSM. You aren't meant to account for every single possible platform combination. Do as you wish

I can understand the route master argument. I used it because 1. it already existed, 2. these routes use the same trunk line through the city centre, so the North Clyde line or Argyle line. I can also understand adding different stopping patterns. But what I don't get is adding all different platform variations as separate routes; in this case you would have possibly more than 20 route relations for the London-Birmingham service as both stations have many platforms and the trains servicing the route can use most of them. So I don't think the wiki covers the case for multiple platform usage as it would very quickly bloat the OSM database with data that isn't useful, as train services usually only use the one or two platforms assigned to them, and passengers should rely on station screens, not on OSM

This is not needed. Why did you create separate relations simply for different platforms? The Milngavie-Edinburgh and Milngavie-Springburn services already exist, please don't duplicate it. Also, if you want to add more services, please add them to the already existing route master: relation/6399061

Hello, sorry, I'll stop doing this. I was going off the wiki article railway=platform_edge

Thanks, I'll add the circular service later

The route=railway relation should contain just the tracks of the railway route, although I'm not sure if the Fife Circle is a route as the sectional appendix divides it into the main line and the Cowdenbeath line. For now I suggest that the stops be removed and only the ways remain, as I've added most of the train services.

Yes, because this is just a collection of all the track that constitutes the Fife Circle, thus route=railway. I added the train services using route=train (e.g. Edinburgh-Leven), besides the old relation uses the PTv1 scheme which is outdated.

Thank you for letting me know, I realised after seeing new signals from satellite imagery. I added the old signals for now.

Hello, I used maxspeed=default because it was used in my area before and I didn't know maxspeed=implicit is more common.

Hello, I was going off the Wikipedia article on ATP, I didn't know it was removed. In that case I will remove it from the line, apologies.

Hi, not sure. I will merge it back

We tend to use established tags to describe the point of interest in order for computers to be able to compile the information, but if you really want to you can add a 'description' tag for end users or a 'note' tag for other mappers.

Hello, thank you for contributing. Please note that the name tag is for objects that are explicitly named - please do not add names like "water tap". In the case of the bike shop just "beCyCle" is enough, no need for descriptors in the name tag.

Спасибо за информацию, ещё раз извиняюсь.

Здравствуйте, извиняюсь за снос мапинга. У меня была уверенность в том, что парковки можно интерполировать и склеивать маленькие сегменты улиц с разными тегами. Ещё я не знал, что parking.mos.ru можно использовать в качестве источника и использовал Яндекс.Панорамы. Теперь буду учитывать и верну правильные парковки на сретенские переулки.

Здравствуйте, не знал про это, буду исправлять.

Спасибо, исправлю

Hi, I'm using Relatify which is a github script to add stops and ways to bus route relations. It's known to split ways randomly and I don't know how to stop it from doing that.

Again here you are clearly deleting bus gates/contraflow lanes without any source.

Again here someone has left a note explaining the tags but you have chosen to ignore and 'fix' it.