I think this may be one of the main discussions I had vaguely remembered (along with some other issues linked within it) :
Rereading it now, it is mainly about stops/platforms and has little to say about stations. But some of the general comments about rendering the PTv2 schema are probably relevant. In particular, comments about bus=yes on bus stops may also be relevant to any suggestion that relies on using train=yes on stations.
Perhaps, but I donât see how itâs relevant here. The passenger platforms of Grand Central extend under the same city blocks, which would put its centroid in a misleading place as well. No matter whether youâre a passenger, an employee or a railroad enthusiast, the best place to put the label at Grand Central (and possibly every other terminal station) would be close to the zero milepost, i.e. the beginning of the tracks.
Iâm not against using railway=station on an area, but it doesnât solve the need for a manually-placed label node. A station is not just an area containing railway infrastructureâit is also a linearly-referenced point feature that can be described as a milepost on a route. For example, New Haven Union Station is 72.3 miles along the NYNH&H Main Line from the aforementioned zero milepost (source PDF):
Each of the stations and junctions listed above is conceptually a single point, and there is typically a sign on the ground with matching name and milepost. They have surrounding territory, defining what infrastructure (tracks, signals, platforms, etc.) is associated with the station. But many of them have lopsided territories, and the location of the sign is not always near the center. With railway=station as an area, a lot of stations would be given labels that donât line up with where the station nominally is.
Stations and station territory are two associated, but different, concepts. railway=station as an area may work for the majority of small stations, but there are a lot of edge cases that would be better modeled as a separate railway=station node and landuse=railway area.
no it was so since the public transport proposal. The meaning of railway=station was not changed, but the public transport proposal never covered freight stations, it was always limited to public transport, and made this quite clear already in the initial sentence: âThis proposal covers a complete view on the public transport and extends the existing and well known tags with more exact and clearly defined new tags.â
Admittedly, railway=station was not explicitly documented to cover freight facilities in 2014, and it appearently included definitions for railway=halt, which by that time already had its own tag and page for 6-7 years, so by 2014 there were inconsistencies in the railway=station documentation, both, refering to other tags, and likely also refering to actual usage (freight).
IMHO, the areas should not stand alone, rather they should have entrances or other access points (gates?) on their outlines, so that routing engines can lead you to meaningful points.
@DaveF has also replaced this illustration with this one:
It also has multiple issues. @DaveF, please correct them, when you have some time. Thank you in advance!
This illustration also uses separate platforms for different refs when railway=platform_edge also is a thing to deal with multiple refs so that should also be taken into account IMO.
May I ask you to please be more specific about what you think should be done here? Iâm not fully understanding (railway=platform_edge) and I donât think Iâm alone in that. Specific suggestions are quite welcome here.
Basically, you split an island platform into a multipolygon, assign the edges/ways next to the tracks railway= platform_edge and set the ref to whatever number the platform has.
More on the wiki with corresponding images.
Thank you very much!
After reading through this and related issues, I agree with you that railway=station shouldnât be separated from public_transport=station. The reasons are:
train=yes was not part of the public_transport=station part of the public_transport=* proposal.train=* key is most likely to be missing from the OSM Carto database.public_transport=stations that are also railway=stations are missing the train=yes tag. And OSM Carto developers say that âwe canât render these properly unless mappers add bus=yes / train=yes etc. to each object.âUnfortunately GraphHopper doesnât support this yet.
These are also good points. This idea seems the best to me now:
Which takes us back to @BĂĄthoryPĂ©terâs original suggestion:
Should we name this additional tag perhaps railway:site=area or railway:site=perimeter?
Do you have any other suggestions?
Perhaps railway:site=station, matching the nodeâs value? That would make it more extensible to other railway=* point features, like railway:site=yard or railway:site=junction.
I see three disadvantages about this:
railway=* tag on the railway operating siteâs node*, they might forget to change this one too.railway:site=site looks a bit weird to me.* Although this isnât that common, I guess.
From 4 reasons, there are 3 points related to OSM Carto, forget about Carto, it is mostly stalled, people are now more interested in the upcoming vector maps. The remaining one is about the public transport proposal from 2011, not relevant IMHO, we should just see what is currently done, not what was proposed in 2011.
If we agree that railway=station applies to freight stations, it is clear they cannot be the exact same outline as public_transport=station (and that not every station will have a public_transport tag). E.g. there are exceptions like the vatican train station, which is essentially not used by the public (although WP says it was opened to travellers in 2015): Stazione di CittĂ del Vaticano - Wikipedia (no English article in WP)
There is also an international railway, the Vatican Railway, which btw. is one of the shortest national rail systems as well, which cannot be considered âpublic transportâ because it hardly transports the public: Vatican Railway - Wikipedia
These are just some local examples, but there are many railways which donât transport people but only freight.
Youâve raised a good point. Contrary to the current definition on the Wiki, I donât think that railway=station should apply to freight-only stations. I suggest that we use railway=yard for theseâit was created for this purpose. This would make the tagging schema clearer, so id-tagging-schema might be able to handle it better as well.
Ok somehoiw this being argued again. I will repeat what I originally suggested.
landuse=railway : This is a homogeneous, divisible statistical classification for the land. It doesnât neglect the need for a feature tag. It doesnât work on elevated or underground stations, or when there are multiple levels. railway:site= looks like an attribute, not a feature. landuse=railway should be considered separately from all the indivisible features.railway=station= + public_transport=station area: I suggested this for the publicly usable area in order to keep the combination of railway=station= + public_transport=station together. While one can argue they donât have to match cf highway=bus_stop + public_transport=platform , railway=station= + public_transport=station is more easily understood and clearer to other users.railway=site area: I suggested using this for the operational area. This keeps it unique and highligted as more advanced knowledge of a specialist topic.Use case issues:
railway=milestone be used for it? Eg milestone=station can be invented, and it can be linked in the type=site as station or label (the area would be perimeter ).building=train_station and entrance= or =subway_entrance (even the derived abnormality of =train_station_entrance ) in the public_transport=stop_area .=station points are still commonly positioned at the platforms of an underground stations, not =subway_entrance, or ticket hall / concourse when not overlapping for bored stationsI agree, thatâs what I suggested:
I also agree that the link between this tag and landuse=railway should be weak because of the following:
railway=site is already in use with ~10k usages and a different purpose. I donât think repurposing it would be a good idea.
Because this would involve retagging thousands of stations worldwide, and the current tagging schema handles this situation perfectly fine. The vast majority of railway stations worldwide are mapped as nodes, and if we decide on a tagging schema that incorporates points and areas together, we should avoid a schema that would require a massive mechanical edit.
By analogy, why do we need to have place=city nodes if thereâs already a type=boundary + admin_level=6 relation? Because places are still point features, even if they have an associated area. Utica, New York is an incorporated city with defined boundaries, but if youâre driving and a sign tells you that youâre 42 miles away from it, youâre 42 miles away from a selected point at the center of the city. The administrative boundary of Utica, however, is only 40 miles away from this point.
type=boundary relations would beg to differ 