The issue with that (and other halt nearby) is that their position according to railway line is basically in the crossing, meaning: Wrocław Partynice (9,421 km) and the crossing (9,418 km).
Using a multipolygon in this situation, with given rendering, would favor the node to appear in the middle of one of these multipolygons, not necessarily representing the real situation. It applies to other halts as well, where the road (or other “barrier”) is in the middle of the halt (the area still belonging to railway company)
area:railway=station is not rendered by anyone yet. Both railway=station point and area are rendered. There’s no “Tagging For Renderer” here, nor lying. area:highway= already has issue in eg what is a =traffic_island . Eg when a crosswalk refuge island has different levels (one is at kerb=raised ; the other =lowered , =flush , or =no ), or some parts are fenced off , you won’t get the whole island as either a area:highway=traffic_island or area:highway=footway , but different parts of them.
One of the proposals actually suggested to draw eg area:highway=shoulder inside the area:highway=motorway , which I disagree as it’s not part of the carriageway. But this can be said as similar to how area:railway=rail can be enclosed/nested by a area:railway=station . More agreeably, an area:highway=bus_stop can be inside the area:highway= carriageway. Proposal:Street area - OpenStreetMap Wiki
I’m interested in alternatives other than area:*= for both *:railway= , and *:highway= , to distinguish the physical and functional area perspectives. In the meantime, this is the best solution I can think of.
I wouldn’t say that’s really how it is on the ground.
I don’t think that’s too bad though. One will know where the halt is located from afar and from close up it’s obvious that the other platform is part of the same halt. And other applications will easily know it. I’d say you care about rendering a little too much, sacrificing information for better rendering (in your mind; IMO rendering in the middle of the highway is incorrect).
Does the railway company manage the sidewalks on that part of the street?
You could use area:highway=footway + footway=traffic_island. I think that works quite nicely.
Hm, I guess the right move would be to have a version of area:highway that’s similar to building:part.
landuse=railway is already used for that and IMO it’s better than area:railway. It’s not describing the entire area where trains can move because they move only on tracks opposed to wheeled vehicles like cars or bicycles.
The reason why I dislike the combination of a railway=station node with an area:railway=station area is because IMO area:highway should represent landcover (meaning no other area should be contained inside it, maybe excluding nested a:h). So area:railway=station first of all doesn’t represent that and second of all it just seems like a way to keep rendering the label in a specific spot while the exact area of the railway is known. It’s dangerously close to violating One feature, one OSM element - OpenStreetMap Wiki.
area:railway= isn’t eg a kinematic envelope. It’s the rail operational area, reflecting the ballasted or slab track area only. landuse=railway can include grass, walkways, maintenance roads, etc. Proposal:Railway Schematic Mapping - OpenStreetMap Wiki landuse=railway isn’t a feature. It doesn’t describe what this piece of land is either.
As I said, eg an in-lane area:highway=bus_stop already doesn’t represent the physical pavement area. It’s a functional area. This is an area:*= problem, not area:railway=station alone.
I already summarized the problem statement above. If you want a simple analogy, think place= vs boundary=administrative . In a different sense, there’s popular demand for a (linear referenced) point instead of an area, for different purposes, and with a different meaning. railway=station similar to other railway= features, except it’s not attached to the railway= track.
Ps landuse=railway doesn’t work in combination with man_made==bridge or =tunnel
To highlight, this is the result of 300 comments over 2 years for now. As I said now, better ideas welcomed, while area:railway=station is the least worst and most acceptable solution at this moment.
You could try to convince the opponents of railway=station area. But out of practicality, easier to invent a new area solution, than a new solution for the point feature.
landuse=railway isn’t a feature. It doesn’t describe what this piece of land is either.
Not if you pair it with railway=yard or railway=station.
then the feature has still nothing to do with the landuse, it’s the railway=* tag that defines the feature (which doesn’t change at all with or without the landuse=railway tag)
I think this should be open for debate, the public_transport tag could be used on the passenger accessible areas only, while railway=station could be used for the whole station (IMHO it is already like this, with some fuzziness)
I tried to do this at Budapest-Keleti: tourists got misled by kilometres when planning a route there because neither OSM Carto, GraphHopper, OSRM nor Valhalla can handle this type of tagging. If we were to start tagging more stations this way, many-many people are going to be misled; therefore, I don’t see this as a viable solution.
I’m being deliberately flippant here, of course, but the point is a serious one - in the general case, we should try and get OSM data “correct” rather than “something that is understood by a particular third-party data consumer”, and data consumers should be able to work with OSM data as it exists.
In this specific case there’s another issue - this was the area that had been tagged railway=station, and as noted earlier (maybe in a previous thread?) that probably doesn’t correspond to what most people catching a train would think of as “the area of the railway station”.
I see your point—but is there any data consumer that could handle railway=station areas correctly? If not, that’s a serious argument against using them. (But I agree, it’s not a dealbreaker necessarily.) Even if data consumers start implementing correct routing / rendering for them, that would take a long time.
The challenge I suspect will be more generally “routing to entrances to areas”, and it’s been discussed before many times in the context of airports. For example have a look at this “route to the centre of a hospital”. Realistically I think you’d just want to be routed to one of the entrances, which unless a bus had dropped you there probably wouldn’t even be the main entrance.
Probably not "hosted by someone for free on the internet right now, but I’m sure it would be possible to create one.
I don’t know enough about what the various routers offer “out of the box”, but even if nothing, if you preprocess the data to somehow indicate that “this entrance is actually an entrance to Nottingham City Hospital” a router could handle that but the simple examples on the osm.org site don’t. My example above of successfully routing to train station buildings works because the data preprocessor creates an entry on the search menu for railway stations, but makes clear that it’s actually a station building.
So there are basically none right now. I could only find one related open issue on GitHub for GraphHopper and two for OrganicMaps—all stalled, from 2023.
Yeah, but this doesn’t apply to the many operating sites without a station building.
I tried to do this at Budapest-Keleti: tourists got misled by kilometres when planning a route there because neither OSM Carto, GraphHopper, OSRM nor Valhalla can handle this type of tagging. If we were to start tagging more stations this way, many-many people are going to be misled; therefore, I don’t see this as a viable solution.
What do you think?
I think the data users would be able to adapt to more complex schemes and overall in the long run it would lead to better results if complex situations could be represented in a more detailed way rather than condensing a whole railway station into a single point because it works for some usecases.
I agree that condensing the station area into a node and mapping it as a node only is a bad idea. But I think they should coexist—otherwise renderers won’t be able to correctly place the label of the station name.
To be clear, I was quoting this not as an example of a solution to your problem, but as an example of the need for data consumers to handle OSM data as it is (one where I had fixed a router that I use every week to work in situations where it previously did not).
Indeed - code changes don’t magically appear like fairy dust - someone has to work to make it do the thing that you want it to do. I did have a quick look at “routing to station entrances” (for Garmin maps) before adding “routing to station buildings”, but the former was much harder to do and the latter a much quicker win.
Have you tried look at the documentation or the code of any of the routers, and trying to understand what would be needed to solve the routing part of your problem. Going back to your original post, the biggest part of that was addressed fairly early on.
The problem is not in the routing itself, but in the choice of the destination point. The problem is not only in railway stations, is related to routing to/through the entrance of any kind of feature (airports, ferry terminals, shopping malls…), and doing the best to their users, the best choice for pedestrian probably wouldn’t be the same than for car drivers wich would prefer a parking entrance.
Each navigation software should implement a solution according to its user base and design decisions. There are often ambiguous interpretations of what the user is looking for or needs. If someone searches, for example, for “JFK Airport” (in OSM Way: John F. Kennedy International Airport (158042008) | OpenStreetMap ) the software should have the knowledge that is not just routing to the center of the polygon that is sized several square Km. If the size of a feature is more than, e.g. 100mx100m the software should have some kind of algorithm to refine the user’s search to be able to let them choice and guide them to the expected place.
@gymate there are several related issues in Organic Maps, mostly for airports.
Kovoschiz:
I could only find one related open issue on GitHub for