Nearly complete coverage in Norway, Poland, Slovakia
Commonly used in Russia, United States
Other countries not mentioned appear to have a mixture of the above tagging schemes.
My point about ref or local_ref being redundant on a railway stop is that railway:track_ref, in its original definition, was intended to represent that track number.[1] In countries where it’s common to simply tag railway:track_ref=* and leave the railway=stop without a track number, it would be unreasonable to enforce a tagging scheme that requires each stop to match the track number of the underlying railway.
This definition was expanded about 4 years ago to represent “track number” more broadly. ↩︎
This is an important detail that I think could be discussed later in a proposal process. My illustration is not exhaustive, it’s just a guideline for how stations should be mapped in general.
That’s a good point. I’ve mentioned my concerns about this before, but both important points have now been addressed. So I’ve updated the illustration:
I think you already asked this here, and I (hopefully) answered it here. But if not, see these further arguments: 1, 2, 3, 4, 5, 6 and 7.
I don’t think your reply was helpful, it seems this “non geometric center” is arbitrary and not helpful for stations with multiple entrances and parts. A polygon with entrances seems a better representation for complex stations.
IMHO node:amenity=station would be a nicer tag for these arbitrary and in detail unverifiable station nodes so that we can tag amenity=station on the train station without having to deduplicate multiple objects
Sometimes the placement of point features is subjective. In fact, this is accepted practice on OSM for place=*.
Here is Houston, a node tagged place=city. This node’s placement locally, and within the city at large, is rather arbitrary. Why is it Downtown? Why is it sitting over the One Shell Plaza building? Is this node needed at all, considering that the city limits have already been mapped in a relation? After all, Houston is a sprawling city with several centers. Why not put it Uptown, maybe near the Galleria?
We can deduce from signage on the ground (like this distance marker 20 miles away from Downtown) that people conceptualize Houston not only as a municipality with defined boundaries, but also as a point feature with a distinct center. Clearly, this center is Downtown, but there’s no distinct part of Downtown that stands out as worthy of highlighting as a center. Literally any location within that porkchop-shaped freeway loop could serve as the center of Houston, and it would still match the mileage on distance markers elsewhere. So we put the node wherever it looks pretty, while still satisfying the distance-based requirement that it remains Downtown. For the person who mapped it 17 years ago, that happened to be on top of One Shell Plaza, and clearly nobody has disagreed since.
Likewise, railway stations have both a defined area and a defined point location based on distance. If the community can find a way to add nodes for populated places that correspond to administrative boundaries, then station nodes should be no problem.
According to taginfo, there are ~94,000 railway=station mapped as nodes, and ~7,000 railway=station mapped as ways. A tagging scheme that would require changing 93% of existing railway stations worldwide is a non-starter. If we’re going to redefine and retag one or the other, it should be ways.
According to taginfo, there are ~94,000 railway=station mapped as nodes, and ~7,000 railway=station mapped as ways. A tagging scheme that would require changing 93% of existing railway stations worldwide is a non-starter. If we’re going to redefine and retag one or the other, it should be ways.
will this be limited to railway stations or is the intention to use different tags for the same thing, according to the object type, something we will extend on all POIs? Are you aware it is implicit whether an object is an area or a node?
A simple observation this morning on the standard railway station node. Up and down the Adriatic coast each station has a single node affixed to a rail in the station area. When I came to Scilla in the south of Italy the node was to the side and when then reading, the wiki has a contention warning, it says to map an unconnected node close to the station centre. More checking west bound from Pescara, all are fixed to the rail through Pratola, but then onwards west from Sulmona to Avezzano, it’s to the side again.
Frankly it’s wurscht to me as long as that what is documented is solid and reliable… apparently not. Can we get a damoclian sword swinging please and fix this yes/no, on/off rail. Where does station node go?
That’s not much of an argument. We require that mappers use abstraction, approximation and common sense: place nodes are placed at an arbitrary location near the place center, and waterway lines somewhere along an arbitrary midway of a large river. What would be more beneficial in general is to have a specific convention where station nodes should be placed, and stick to that convention.
If we regard the railway network as a specific layer that can be extracted from the main map and analyzed separately, I think it is logical that a station node is placed on the rail so that e.g. the distances can be calculated unambiguously by consumers of such data.
Supplemental to my previous enquiry. While mapping rail corridors through the Apennines mountains woodland areas, had noticed some halts on the rail, also with name. The mentioned Scilla station had a stop node each binary, no name. Hard to connect to a name for trip calculations, so can see Duja’s argument, we judge and apply all the time to our best ability.
edit: then getting to L’Aquila both station and stopS on the rails, but not all, WITH name.
)