Railway=station as an area?

[gymate]

@rurseekatze

Please excuse my late reply. This is a complex issue that requires enough time to think about. Now I have finally found the time.

Yeah of course, no worries! Thank you very much for your reply.

@rurseekatze

I would prefer to add landuse=railway` at the station area.

I agree!

[gymate]

@rurseekatze

I would suggest to replace ref=* at the platforms by local_ref=*. This reflects the local character of this id in contrast to global or operator wide identificators in ref. Would also be more consistent to use local_ref both at platforms and stop_positions as it contains the same data.

Yeah, it would be a good idea to use the local_ref key for railway station platform letters (e.g. in Slovakia and Czechia) or numbers (at most places).

[gymate]

@rurseekatze

It is just redundant information because the information is either already mapped at the station area or can be queried with a simple geometric query without having to maintain a relation

Yeah this would be much easier, but is there a query to download only the elements of a single station where it overlaps (or is overlapped by) another one? E.g. the RER station Charles de Gaulle — Étoile on layer -5 which is overlapped by Métro 2 on layer -3? Because this query for the elements of the RER station also downloads the tracks of Métro 2 (when it works) which could lead to duplicate reference numbers.

Currently this is a rare occasion as most railway=stations are mapped as nodes, but if most of them were mapped as areas, this would be much more common.

[drolbr]

Hi,

in general, I recommend to first look only at ways and then split by
level. You can then get level by level going through the numbers

way(680443640) ->.searchArea;
way(area.searchArea)[level=-5];
out geom;

If you wonder how to get the numbers in the first place then you can use

way(680443640) ->.searchArea;
way(area.searchArea);
make info level=set("{"+t["level"]+"}");
out;

If you want to edit the data then you could use

way(680443640) ->.searchArea;
way(area.searchArea)[level=-5];
(._;>;);
out meta;

but the caveats of Sparse
Editing
apply. Another approach would be to download full data and use the JOSM
level filtering instead.

Relations and nodes are insofar of lesser interest here because they
usually do not carry a level indicator.

[gymate]

@drolbr

If you wonder how to get the numbers in the first place then you can use

way(680443640) ->.searchArea;
way(area.searchArea);
make info level=set("{"+t["level"]+"}");
out;

Thanks, I didn’t know about this! The query results in the following XML element:

<info id="1">
    <tag k="level" v="{-2};{-3};{-5};{}"/>
</info>

So—as far as I understand—this only shows which layers (or in this case, levels) have any elements that are covered by the search area. It doesn’t say which layer is the railway=station on.

@drolbr

way(680443640) ->.searchArea;
way(area.searchArea)[level=-5];
out geom;

And this one only works if you already know the layer number of the station.

So, I guess, the solution is to

1. download all railway=stations in the desired area
2. get their layer=* (e.g. using Python)
3. run a new query to download all elements that
   • are covered by each railway=station and
   • are on the same layer=*.

This means that a query for all 872 railway=stations in the world currently mapped as areas—which is roughly equal to the number of stations and stops (806) the Schweizerische Bundesbahnen has altogether—would be 6843 lines long.

This can’t be run in a browser calling overpass-api.de because it produces an URL that’s too long for the server (Error 414). But it can be run using overpy in a Python script, for example. (It takes an average of 1 minute and 40 seconds for the server to respond.)

So it’s possible, but I think that a built-in Overpass API feature would be nice to make this easier.

[gymate]

@rurseekatze

Now with the recommendation to map railway=station as areas (for the infrastructural boundaries), I no longer see any need for the workaround with railway=facility and propose to deprecate it.

I agree with this one too. I’ll update the illustrations accordingly.

[gymate]

Here it is:

@rurseekatze Please let me know if I have misunderstood anything.

[stevea]

Sweet, succinct. Two thumbs up, A+, making an “OK” with two thumbs and forefingers. I nod my head.

[gymate]

I’ve added two missing train=yes tags and updated both illustrations.

[gymate]

I corrected the instructions for adding labels to areas and multipolygon relations on the railway=station Wiki page. I tagged the following stations accordingly:

• Kimle-Károlyháza (as an area)
• Rajka (as a multipolygon relation)

I also added these to the Wiki as examples.

And I’ve opened an issue on GitHub regarding OSM Carto rendering railway=station labels twice.

[alan_gr (Alan)]

I’m a bit confused by the Carto issue. As a station should only have one railway=station object, it seems like a good thing that Carto renders two labels where there are two objects, as mappers are more likely to realise there is duplication.

I am also a bit concerned that the page is moving beyond clarifying current practice towards prescribing a new approach. It now gives high prominence to railway=facility which is rarely used in some (most?) countries. It now reads almost as if it is compulsory.

[gymate]

@alan_gr

It now gives high prominence to railway=facility which is rarely used in some (most?) countries. It now reads almost as if it is compulsory.

Thanks for the heads-up—I’ve removed all references to railway=facility from the railway=station Wiki page as agreed above.

I’ll also mark railway=facility deprecated on its Wiki page, if you agree.

[gymate]

@alan_gr

As a station should only have one railway=station object, it seems like a good thing that Carto renders two labels where there are two objects, as mappers are more likely to realise there is duplication.

It’s not intended as a duplication but as a correction to the rendering location of the label in the area (to avoid issues like these):

@Kovoschiz

Again, I will emphasize label in =site or type=label can be used for the meaningful and representative centerpoint if needed.

But @Kovoschiz, please correct me if I misunderstood your suggestion!

[gymate]

@gymate

And I’ve opened an issue on GitHub regarding OSM Carto rendering railway=station labels twice.

@imagico Also expressed his concerns on GitHub about using type=label relations and label members on multipolygon relations:

type=label has 51 uses on relations and the documentation indicates it to be intended as a map drawing vehicle rather than a method for documenting geographic information.

Nodes as members of multipolygon relations are undocumented and used rarely (<10k of 36.5M relations). I am not aware of any data users that interpret such.

I don’t see any documentation of railway=station having a different meaning when tagged on:

• nodes
• polygons
• nodes that are member of a relation of some type

Is there a de-facto difference in meaning between these different types of use?

Is there agreement among mappers that the examples of double mapping linked to above are correct? That would seem odd in light of One feature, one OSM element - OpenStreetMap Wiki.

@Kovoschiz Could you please share your thoughts on these too as an experienced mapper? Thank you in advance!

[alan_gr (Alan)]

@gymate

Is there agreement among mappers that the examples of double mapping linked to above are correct?

Speaking only for myself, I found the mapping of Kimle-Károlyháza quite surprising. It wasn’t where I thought the previous discussion was leading. We now have two objects that repeat almost the same tags including railway=station and public_transport=station. How would mappers know which one belongs in a stop area relation, for example? Note there is also an ongoing discussion on this forum about removing duplicate railway=station which informs mappers that there should be strictly one of these objects per station: Maproulette challenge: Fix duplicate railway stations [looking for feedback]

Also, I feel it is unclear whether you are asking for rendering specific to train stations or more generally. Is there any reason to treat stations differently from hospitals, shopping centres, or universities?

Given the low usage of type=label and the fact that the only documentation seems to be a proposal from 2008 that went no further, I would say it is going to be difficult to get this type of relation rendered.

I think it is rather different from the administrative boundary situation, where it is not quite true to say that the Chicago label is only rendered once - the label also appears alongside the boundary line if you zoom in far enough.

[Kovoschiz]

I’m confused on what’s happening. I mentioned label as one possible option to replace the railway=station point if an area is not enough. That may not be needed if areas are accepted.

[gymate]

@Kovoschiz

I mentioned label as one possible option to replace the railway=station point if an area is not enough.

I’m sorry—I misunderstood your suggestion.

@Kovoschiz

That may not be needed if areas are accepted.

So how could we tackle issues like these?

@gymate

In the case of Berlin Hauptbahnhof (copied to OpenGeoFiction as a railway=station area) the marker would be rendered somewhere at the western end of the platforms:

[dieterdreist]

So how could we tackle issues like these?

(Berlin Hbf), this is only a part actually, the station is composed of 2 parts (5 floors lower there is the north/south line)

[gymate]

@alan_gr

I found the mapping of Kimle-Károlyháza quite surprising. It wasn’t where I thought the previous discussion was leading. We now have two objects that repeat almost the same tags including railway=station and public_transport=station. How would mappers know which one belongs in a stop area relation, for example? Note there is also an ongoing discussion on this forum about removing duplicate railway=station which informs mappers that there should be strictly one of these objects per station: Maproulette challenge: Fix duplicate railway stations [looking for feedback]

@alan_gr

Given the low usage of type=label and the fact that the only documentation seems to be a proposal from 2008 that went no further, I would say it is going to be difficult to get this type of relation rendered.

Yeah, I see your point, and I agree that this duplicate tagging is wrong.

@alan_gr

I think it is rather different from the administrative boundary situation, where it is not quite true to say that the Chicago label is only rendered once - the label also appears alongside the boundary line if you zoom in far enough.

Thanks for pointing this out—I’ve edited the issue description.

[gymate]

@gymate

So how could we tackle issues like these?

OSM Carto developers stand by their 2013 decision:

It’s entirely the wrong concept to put a “label” node in the database, and I’ll not be using it for rendering.

The geodatabase is for geodata. Rendering decisions are made by the renderer. If the renderer isn’t sufficiently advanced to place a label to your desire, then lets improve the renderer.

I suggested a method to improve the renderer but it was rejected by @imagico and @pnorman for a number of reasons. @imagico recommended to wait for more consistent mapping methods (e.g. more railway operating sites being mapped as areas) first, and then come back to this question.