Hallo,
Kannst du erklären, warum du zahlreiche korrekt nach Verkehrsträger aufgeteilte stop_area-Relationen wieder in Super-stop_areas zusammengefasst hast? Das sorgt für Probleme, da so etwa Halt-Infrastrukturen von Busse, Trams, U- und S-Bahn fehlerhaft in einem stop_area zusammengefasst werden. Da wird dann korrekterweise von Validatoren wie z.B. http://osm-subway.maps.me/austria.html bemängelt.

Can you please clarify your source for this large scale re-tagging of road infrastructure?
I have personally driven a lot of these roads and can testify that they are not Freeways, which is the only road type in Iran that highway=motorway is used for.

Hi,
Can you please clarify your source for this large scale re-tagging of road infrastructure?
I have personally driven a lot of these roads and can testify that they are not Freeways, which is the only road type in Iran that highway=motorway is used for.

It seems you are adapting data to fit your personal use case. The station's reference number (e.g. 10009) belongs into the reference tag of the station. It is not the name of the station though. Can you please revert your changes accordingly so the stations are tagged correctly?
If your use case is obtaining the reference number for a station may I suggest you take a look at apps using OpenStreetMap data that show this information, e.g. the app OSMand

Currently the guideline for people mover infrastructure in OSM is to tag them with railway=monorail - See osm.wiki/Railways#Types_of_railway_line
I find this less than ideal, but it has been the consensus for the past 10 years. And actually if you look at most people mover systems they consist of one (=mono) central guiding rail with the rolling stock running on rubber tyres.
So tagging them as railway=rail is even more wrong since they don't have any outer rails.
Let me know if you are okay with me reverting the tagging of Phoenix Sky Train to monorail.

Hi Paul,
Back in the days there was more consensus on the public transport tagging to preferably tag stations as nodes. As I created duplicate objects back then: Sorry for that.
Are you regularly mapping in Bangkok? What's the preferred tagging: railway=station on node or area?
I am happy to clean up accordingly.

You can also denote the building level for a place using the level-tag. So if you know this restaurant is on the first floor you can tag it as level=1
(NB: The convention is level=0 to be Ground level storey)
---

Published using OSMCha: https://osmcha.org/changesets/81156186

Welcome to OpenStreetMap and thanks for your contributions so far.
If you are unsure about the name of a place, shop or amenity please do not use a descriptive name, e.g. "Nail Parlor". It's impossible to tell then if this is indeed the name or if the name is still missing. Just leave the name tag empty and fill it in the next time you surveyed the location or someone else will.

Also part of this changeset you accidentally deleted a railway tag of the L line. When saving your changes use the opportunity to quickly if all the changes you want to upload are intentional to prevent this.

Happy mapping
---

Published using OSMCha: https://osmcha.org/changesets/81957603

Correct changeset description:
Updated park constructions which had finished meanwhile. Also added layer tags to bridges
Source: Bing

Hi Halbtax,
Was there a specific reason that I miss out on why you removed the Leman Express train stop position from the stop area relation relation/9003408 ? I can see that one could separate the stop areas for train infrastructure and bus, but I am not sure if that is what you were aiming at.

Yes, station=subway is a reference to the railway infrastructure and not the location. You can add location=underground for subterranean or location=overground for elevated stations. But this is some evolving tagging still.
Thanks for restoring the station=subway tags

Sorry. Missed your comment earlier.
Established practice for tagging the railway=station is on a node. The problem with tagging it on the area is where you draw the boundary? Does it include the track sections as well? Where does the station end on the tracks as they are leaving the station area?
Now to the specifics of Sydney Central:
- There is already a landuse=railway area that give information about the area used by railway infrastructure
- Furthermore there are polygons for the train station building and the platforms. The latter are linked to the whole station via a stop area relation so as a data consumer you can always determine whether you are within the bounds of an object that belongs to the station

Do you currently have a service that relies on the station polygon you created?

Wrong changeset description. Should read:
Removed duplicate place node for Sehzade Camii Prince's Mosque

Do you verify the location of the airport metro station of Goldline? I am not sure it is actually at this location judging from the construction visible on satellite imagery. Would be best to be verified on the ground

Calgary of course, not Edmonton *facepalm*

Restored metro station in changeset/73183128

Can you explain why you re-tagged LRT line 2 to light rail? The name is light rail, because it started like that, but line 2 has meanwhile changed to heavy metro rail vehicles, the infrastructure has characteristics of a rapid transit (metro) system, such as high passenger throughput, exclusive right-of-way and use of full metro rolling stock. I would suggest you revert the tagging of infrastructure and routes back to subway therefor.

In regard to maintainability: As you already pointed out upon changes to a line (like opening of finished segments) we always need to update both individual nodes and ways as well as the accompanying relation. So it's just the question which is the cleaner way to capture the elements of the members of a route. As I said earlier I think it is not correct for the route "HarbourFront <-> Punggol" to include elements that go beyond this section, even if they are tagged as inactive. Also for data consumers it's easier to tell that a "construction:route" / "planned:route" / "proposed:route" relation is actually a whole route section that is not active (and most likely discard it). This can of course also be realized by using the lifecycle prefix on member roles. So in the end it's just a question of taste and preference.

If it's easier for you to maintain the routes with tagging members we can re-tag Singapore accordingly.

I think it makes sense to tag network as the modality and operator as Transport for NSW.
I have updated the source document for the Subway Validator to cover light rail and trains as well. Should be included in tomorrows run and then we can work through the list of routes and stations to update :)

I agree with you wholeheartedly. This combination of monorail and APM has been practiced in OSM data for years though. So if we come up with a new tagging variant it should be a distinct improvement covering more variations like the air cushion funicular at https://en.wikipedia.org/wiki/Dorfbahn_Serfaus or the cable propelled https://en.wikipedia.org/wiki/MiniMetro
One could even argue that these should not even belong within the railway=* tagging group and instead form something like transit=* - For simplicity of the tagging I would suggest to keep them inside railway.

The simplest would be to just summarize all these different movers as railway=people_mover and then specify further via people_mover:type=automatic or people_mover:type=funicular