railway=station on area=yes behaves like a building, rather than landuse. #327
Comments
|
Yes, this has been something that has annoyed me for years. The rendering has also promoted bad tagging too, and I've struggled to deal with it in my other styles.
I'm happy to see pull requests for this. |
|
2014-02-05 Andy Allan [email protected]:
+1
IMHO should be tagged only to the "station" building. At a railway station |
|
Yes, sorry, I meant to write "station buildings" not "railway buildings". |
|
is there a landuse=station, or is creating another landuse tag more bothersome than just changing how railway=station is handled? |
|
Please don't add more tags when there's an existing one in widespread use. |
|
2014-02-06 3:40 GMT+01:00 javbw [email protected]:
there is landuse=railway (not only for stations) but for the station area |
|
Understood. |
|
@dieterdreist - I had a question about the landuse tag - there are a couple glaringly missing from the landuse wiki page, and I was wondering if you have any advice about it. I use landuse to outline almost everything I work on, so there are a lot of times where the catchall laduses don't seem to make sense - like the land use for libraries, fire stations, pension offices, DMV, etc and other civic/public buildings. It doesn't seem that there is a landuse:civic or anything similar. I have been using landuse:commerical (aka not retail or industrial so it is like a "business office") do you have some dos and don'ts suggestion for this case? I really wish they would have of some more generic landuse definitions. I like your proposal for landuse BTW. |
|
@javbw |
Replace the old buildings SQL and MSS. This involves resulting changes to landcover stylings to handle landcover which was previously in buildings.mss. Stops rendering supermarkets in a crazy pink to fix gravitystorm#520. Superceeds gravitystorm#550. Moves the rendering of train station areas to landcover. Fixes gravitystorm#327. Fixes gravitystorm#389 Removes outline differences based on a distinction that no one fully understands. Superceeds gravitystorm#533. Fixes gravitystorm#68
Replace the old buildings SQL and MSS. This involves resulting changes to landcover stylings to handle landcover which was previously in buildings.mss. Stops rendering supermarkets in a crazy pink to fix gravitystorm#520. Superceeds gravitystorm#550. Moves the rendering of train station areas to landcover. Fixes gravitystorm#327. Fixes gravitystorm#389 Removes outline differences based on a distinction that no one fully understands. Superceeds gravitystorm#533. Fixes gravitystorm#68
Replace the old buildings SQL and MSS. This involves resulting changes to landcover stylings to handle landcover which was previously in buildings.mss. Stops rendering supermarkets in a crazy pink to fix gravitystorm#520. Superceeds gravitystorm#550. Moves the rendering of train station areas to landcover. Fixes gravitystorm#327. Fixes gravitystorm#389 Removes outline differences based on a distinction that no one fully understands. Superceeds gravitystorm#533. Fixes gravitystorm#68
|
this seems to be fixed (probably by changing how buildings are displayed) - see for example http://www.openstreetmap.org/#map=18/52.25569/21.03909. |
Refactor buildings code Replace the old buildings SQL and MSS. This involves resulting changes to landcover stylings to handle landcover which was previously in buildings.mss. Stops rendering supermarkets in a crazy pink to fix #520. Superceeds #550. Moves the rendering of train station areas to landcover. Fixes #327. Fixes #389 Removes outline differences based on a distinction that no one fully understands. Superceeds #533. Fixes #68 Rebased in 6b2a4de by math1985 <[email protected]>
|
comment continued from #1457 I'm bringing this up because tagging it like other objects results in an unexpected action (there's no way to tag a station as a single landuse correctly). And the reasoning for unexpected action seems to not be in line with a lot of other tagging schemes for mapping areas of buildings and other places throughout town - so it causes confusion with new mappers (and me), and is counterintuitive (IMO) - espcially as landuse=* gets wider and wider (the last real holdout is some kind of landuse=civic, which Im working on in the tagging mailing list.) There are very few man-made/used areas that can't be defined by a landuse. Finding stations like this is a real surprise. I got distracted and stopped tagging stations, and now I came back to it when I started mapping a city with good enough imagery to map the sidewalks and trees and whatnot.
I understand about the landuse=railway not fitting the definition well (because, yea, a bus circle isn't railway), then why isn't there a landuse=transport_station or something similar? Should I suggest it in the tagging list? Why are railway stations treated completely differently than any other place? It makes no sense - the tracks and the buildings are just as much part of the station as the bus circle and other related amenities. The platforms render in a completely unexpected manner (they render through buildings and disobey layer). The only reason it is a station is because that is where the two transportation methods come together. having a landuse for the railway side and a landuse for the non-railway side is a failure of the tagging system, IMO - the whole thing is one single place. Having to tie pieces of things together to make a single whole thing feels very weird. No such weirdness is needed for an airport, though it is where two transportation methods collide (the parking lots, bus stations, and everything sit comfortably in "the airport's" landuse. The whole thing is a transport station. It also feels like this is against the "one thing, one object" that works so well for every other single building and landuse in OSM. With all the other landuses, I'm surprised that there isn't a good one for public transport stations. I don't need a relation to add a driveway and parking to a mall. A station should be the same - especially with the "stop position" in existence to differentiate the different stop positions on the different lines (as I understand how relations could work). |
You probably don't want to hear this, but I think this is actually a _conscious_ and _deliberate_ choice by the developers of the styles (which I have implemented in my personal ArcGIS renderer too). By rendering tracks and platforms on top of all buildings, the layout of the railway station's tracks and platforms is visible, even in a 2D rendered map, without the need of fancy transparency, or 3D functionality. This tells you way more about a station. For example, if the tracks were not drawn on top, and no transparency was applied, you would never be able to tell if the tracks were actually continuous through a station building, or a station possibly was a two sided "head" station. Also, no information about track layout with switches and all, would be visible, as covered by the building. Since there are many active "railway" mappers on OSM, I think they generally, or in the majority, prefer this type of rendering (but maybe not all like you...), versus one where nothing of the tracks is visible. Transparency can only do so much... Personally, I find transparency quite useless with more than one transparent layer on top of each other, as it just becomes a mess of indefinable layers of which it is unclear at what relative position they are, e.g. like here (Rotterdam CS, can you tell what is on top of the other?):
In my renderer, to make the "tracks and platforms on top of buildings", more acceptable, I have decided to render the building=roof tag (for open sided roofs, often applied on railway stations) as an open cross hatch, which kind of gets you the best of both worlds: a roof over the tracks and platforms, but still visible tracks and platforms. Also, the building=roof tagging, is often a more accurate measure of where the tracks are actually covered, as the building itself may be much bigger than the roof covering the tracks, and building=roof also generally represents the true "top-level" feature of a building, versus possible "deeper" building layers defined by layer=x or level=x. See this result:
I also think you are seriously underestimating the difficulty of implementing, or doing something sensible, with layer=x or level=x in relation to buildings, and even more so in combination with highways and railways. This is (hideously?...) complex to implement properly in combination with thematic rendering... Also see this related issue and discussion: |
What is the rendering order you would expect? |
|
mboeringa had a good comment - thanks for the replies. I think that whatever makes it better for parsing rail by itself is great for rail maps, but makes it difficult in default -carto to see where stations meet other transport - and giving you some idea of where to go if the station is complex. I am also out of my element completely, as I don't code, so what -carto creates is inside a back box to m, i can only comment on the output. i threw together a quick example of what I would expect the output to look like with railway=station on the area or a similar landuse=transport_station encompassing the station. I did it from memory of shimmaebashi station (the overtrack station), but it might be a little off. The station building is at ~80% transparancy. having some kind of casing hash or something similar to what is used for tunnels would me more accurate to what I was thinking. |
|
Rendering the The roofs idea is a good one, but in this case the entire station is on posts over the tracks - convenience store, ramen shop, ticket office, bathrooms, everything is suspended over the tracks, so its more than a roof. |
|
the station I'm talking about. https://goo.gl/maps/Kon3R I want to be able to show that the station is over the tracks and platforms. It is also hard to show that the overhead walkway directly accesses the station on the second floor (from way across the tracks from the north. Google maps has a user picture. (no short link ><) https://www.google.com/maps/place/Gunma+Prefecture,+Japan/@36.378902,139.04711,3a,75y,90t/data=!3m5!1e2!3m3!1s-k_qFkFZ9NS8%2FUqz83yK_ZII%2FAAAAAAAAAng%2Fm3xxhgT8qFw!2e4!3e12!4m2!3m1!1s0x601e6085c836ae59:0xd799356889717292 |
|
I may be wrong, but I guess this is similar problem I described about main stations in Berlin or Warsaw (the roof is the most important shape here). See #688 (also #552 to some extent): the more complex building with more levels, the more issues with current layering. My opinion is this belongs rather to the public transport map than to the general one, although it would be just a quick fix - the final form should be linking to indoor/3D models. |
|
sent from a phone
you could check for a building=trainstation inside a railway=station area. If you tag the building with the railway tag, how do you tag the whole station? Do you have a railway=station inside a railway=station area? |
|
It all depends on how do we understand "railway=station"? If we just read it on wiki, there's only one way - there may be only one such tag, so this must be used for the widest scope only. But wiki is not set in stone - maybe nobody thought about the case when the station building is not used like it was intended? Then it makes a lot of sense to me to tag station area as railway=station, and station building as building=* (whatever form it is, usually a train_station of course) and railway=station (because this is the current function of this building). In the end I think it's safer to go with rendering all the building=train_station as major, because "major" is just what we want it to be. See my PR. |
|
I had commented on this because I want to define the station's area to encompass all the amenities. I may have a wrong idea about tagging, but in the same way we tag landuse=retail to define a shopping mall and it's amenities, and building=retail to define the structures, I want to define the area used by a station and it's amenities, especially when some amenities (entrances, walkways, driveways, parking) is adjacent to places where you cannot park or walk or access as a traveler. The example I wanted to map is to avoid this kind of problem that google maps has: https://goo.gl/maps/xgX2jHq1kk22 We have the building=train_station and railway=platform, and the promenade sublet for the walkways, but in this case, they are separate things. There is also diffferent entrances, parking and bus loops, all an amenity to the station (not the rail tracks, sidings, or other landuse=railway, but the amenities of the station itself) On OSM Just as we can map a store as a point, a building, or a collection of amenities and buildings on a landuse, mapping should be consistent above all else, and the historical or architectural significance of a train station not used as a train station should be tagged and rendered differently (I don't want a train museum in an old station building that is no longer a transportation stop to ever be rendered as an actual working station), especially at the expense of consistent mapping. Javbw
|
Both ways respect this rule.
But how? While I like your rants, because they are always insightful, IMO It's time to talk about details rather than just general ideas, at least here. I understand that your issue is not about station buildings, but currently it doesn't look to me like it's going to be solved easily and many topics discussed here should be on Tagging list really before we get back here. |
We use theme=* for playgrounds, and we use foobar:disused=* & foobar:abandoned=* to denote a previous existing business or function of a building. People have cafes in old train cars, planes, and nearby my house here in Japan is an old double-decker London bus used as a cafe. It is part of the ground now. Building=retail I don't think we would pull public_transport into it because it is a bus, nor should building=train_station (if it denotes a building currently used as a station) should be used as an old station. This would let Building=train_station work for the building, and railway=station be used for the area of its amenities- the area where the railway interacts with other transportation methods, separating it from land use=railway. There are hundreds of repurposed 7-11s in Japan. You know instantly it was a 7-11 when seeing it as you drive by, now used as a laundromat or a ramen shop. Some have been turned into offices. Javbw. |
|
sent from a phone
discuss tags on tagging, this is an issue tracker for the rendering style and an issue about train stations. a bus used as cafe is far from a building=retail. |
Im sorry my bus example is incorrect. I will follow any guidelines that are suggested in the wiki. however the 7-11 example is a perfect example of how building=* defining architecture can be problematic, rather than purpose. |
|
@javbw I believe you should change the name of this issue or close it and start a new one (whatever you feel is right), because now it's hard for me to understand what is the scope in the end. |
|
I think the title explains it the best. If I put railway=station on a polygon, the renderer assumes it is a building, even though we have building=train_station for further differentiation. So if I know the boundary of a train station area, and draw a polygon to show the land used by the station (its bus circle, its bike parking, its multiple related buildings and amenities that all belong to the station, as I would a landuse) the polygon is rendered as if it is a building, even with an area=yes tag. I want railway=station+area=yes to be rendered like other areas, with ways and building polygons able to be rendered over it (respecting the layer=tag), rather than as a building that always renders over everything. If this means it needs to have some other tag pairing(s), such as building=no / layer=0 / landuse=railway for the renderer to correctly understand that it shouldn't be rendered as a building - great, I will add those tags if deemed necessary by you guys. I just want a rendered "area" that is not the same shade and strength as a station building, so the station building on this new area is still identifiable as a building, yet no ambiguity that the area around the building belongs to the station too (like a school campus or airport grounds). I know my explanations are a bit wordy, but I am trying to be succinct. Javbw
|
|
It's still to general for me. =}
For me it looks like the area, not like building: If it's only about layers, its a more general issue (like "make layers work global for all types of objects"). Did I understand you correctly? |
Here is an area I just drew around Ota train station with railway=station + area=yes This is the extent of the station - the area that where the road, bus, bicycle, and pedestrian system meets the train system (“the station”), and is unambiguously and easily mappable from imagery as “the station” and is the extent of the area that contains the amenities owned and operated by “the station”. the area around the station is not fully nor correctly mapped currently (no pedestrian areas at all, no station amenities nor surrounding businesses), but this polygon is pretty accurate (to about the meter). this area rendered in the darker red like a building. I consider this unexpected behavior, as it is not a building. Contrast this to to convenience store near the south circle: the retail landuse with a retail building and a pin. they render as expected. I have totally mapped Maebashi station, https://www.openstreetmap.org/#map=19/36.38331/139.07330 https://www.openstreetmap.org/#map=19/36.38331/139.07330 and this is when this rendering issue really bothered me. Between railway=station rendering like a red building (and building=train_station not rendered in red for some reason) and highway=pedestrian ignoring or over-rendering roof polygons or not rendering covered=yes, it was not rendered in a way I expected. The giant dark red ground flooding the bus circles looked very bad in particular. I removed the railway=station tag from the area and made this ticket because it rendered in an unexpected way that would be a misrepresentation of the station. Not having a proper accompanying light red to go with the “station building red” does not accurately depict the station, and not mapping the extent at all is an oversight. So I expect, like many other tags, adding area=yes to the polygon will tell the renderer that this is an area, and treat it as an area, not a way nor a building. railway=station+area=yes should be rendered in a shade that is useful as a landuse, rather than “strong building red”. for stations where the platforms and the station buildings are are not on top of each other, and the area covered by the station’s other amenities greatly exceeds the area covered by the just the platforms and station building, then the current rendering is not useful and doesn’t render in an expected manner (to me). Does that make it clear? Javbw |
|
It was still not succinct for me, but I see several problems here:
What do you think about these descriptions and maybe is there something still missing? It's better to stick with small, well-defined issues, because they have much bigger chances to be solved. |
|
Javbw
Airports are a perfect example: terminal buildings: dark purple. So I want train stations to be rendered this consistently as well: Train Station buildings: dark red
This might close this whole thread, I'm sorry if my incorrect assumptions have wasted your time. Javbw |
I don't know, maybe it was back then. In #389 it was not clear. But since I prefer to make station building to be rendered as a major building (dark brown, like in building+place of worship) it doesn't matter now and we can focus on area color. |
|
Area option for railway=station has been restored on the wiki (it was like this until last year, as someone wrote in the Tagging thread). |
|
The discussion on Tagging keeps going, so I hope we will have consistent proposition in the near future, which will resolve all our problems with railway stations. |
Giving the nature of OSM this is meant as a joke? :) |
|
Well, I said our problems (related to rendering), not all of the OSM problems. 😄 |
|
2016-10-05 15:58 GMT+02:00 kocio-pl [email protected]:
there's a tiny detail apparently getting in the way (until hstore gets |
|
Now that railway station buildings render as major buildings, I want to change railway station area color to be the same as aeroway=aerodrome. It's part of a bigger transport areas unification plan, see #2094. See for example this area with railway station building inside: |
|
@kocio-pl Rendering of this feature seems to be ok (there is a label and a fill also). Shouldn't it be closed? |
|
I think you're right - thanks for checking! |
When making many things in OSM, simply marking the point is okay, naming a building is good, and marking it's land use, then the objects inside (roads / buildings / walkways, etc) is best (as I understand it)
But there is no land use for station (as opposed to school, industrial, residential, etc)
so the rendering of railway=station (and public_transport=station?) with area=yes should behave similarly to a land use tag - the area should accept things on above layers (pedestrian areas, platforms, etc) but it currently is does not.
Please make the the railway=station tag behave in this manner.
The text was updated successfully, but these errors were encountered: