Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

railway=station on area=yes behaves like a building, rather than landuse. #327

Closed
javbw opened this issue Feb 5, 2014 · 43 comments · Fixed by #1153
Closed

railway=station on area=yes behaves like a building, rather than landuse. #327

javbw opened this issue Feb 5, 2014 · 43 comments · Fixed by #1153

Comments

@javbw
Copy link

javbw commented Feb 5, 2014

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.

@gravitystorm
Copy link
Owner

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.

  • railway=station should be an area around the station, even if there's no buildings, and treated like landuse.
  • building=train_station should only be tagged around railway buildings, if any, and rendered like an important building

I'm happy to see pull requests for this.

@dieterdreist
Copy link

2014-02-05 Andy Allan [email protected]:

railway=station should be an area around the station, even if there's no
buildings, and treated like landuse.

+1

building=train_station should only be tagged around railway buildings,
if any, and rendered like an important building

IMHO should be tagged only to the "station" building. At a railway station
you'll usually find many railway buildings, at least if its not a very
small station, and not all those buildings should get the train_station tag
(a useful rule might be to put it on those buildings with public/passenger
access).

@gravitystorm
Copy link
Owner

Yes, sorry, I meant to write "station buildings" not "railway buildings".

@javbw
Copy link
Author

javbw commented Feb 6, 2014

is there a landuse=station, or is creating another landuse tag more bothersome than just changing how railway=station is handled?

@gravitystorm
Copy link
Owner

Please don't add more tags when there's an existing one in widespread use.

@dieterdreist
Copy link

2014-02-06 3:40 GMT+01:00 javbw [email protected]:

is there a landuse=station, or is creating another landuse tag more
bothersome than just changing how railway=station is handled?

there is landuse=railway (not only for stations) but for the station area
do use railway=station.

@javbw
Copy link
Author

javbw commented Feb 7, 2014

Understood.

@javbw
Copy link
Author

javbw commented Mar 2, 2014

@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.

@dieterdreist
Copy link

@javbw
let's discuss this on the tagging mailing list!

@matthijsmelissen
Copy link
Collaborator

pnorman added a commit to pnorman/openstreetmap-carto that referenced this issue May 22, 2014
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
pnorman added a commit to pnorman/openstreetmap-carto that referenced this issue May 25, 2014
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
matthijsmelissen pushed a commit to matthijsmelissen/openstreetmap-carto that referenced this issue Oct 1, 2014
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
@matkoniecz
Copy link
Contributor

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.

pnorman added a commit that referenced this issue Oct 16, 2014
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]>
@matkoniecz matkoniecz reopened this Mar 25, 2015
@javbw
Copy link
Author

javbw commented Mar 25, 2015

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.

The area in front of the station (bus stop, taxi booth, car parking, green space) does not fit this definition.

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).

@mboeringa
Copy link

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).

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?):

rotterdam_cs_mapquest

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:

rotterdam_railway_station

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:
#1130

@matthijsmelissen
Copy link
Collaborator

The platforms render in a completely unexpected manner (they render through buildings and disobey layer).

What is the rendering order you would expect?

@javbw
Copy link
Author

javbw commented Mar 25, 2015

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.
trasparency

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.

@javbw
Copy link
Author

javbw commented Mar 25, 2015

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.

@javbw
Copy link
Author

javbw commented Mar 26, 2015

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

@kocio-pl
Copy link
Collaborator

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.

@dieterdreist
Copy link

sent from a phone

Il giorno 25 set 2016, alle ore 03:49, kocio-pl [email protected] ha scritto:

The building can be currently used for some other things (like cafe near Warsaw), so we need to have it tagged also with railway=station.

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?

@kocio-pl
Copy link
Collaborator

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.

@javbw
Copy link
Author

javbw commented Sep 26, 2016

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
Google maps the platforms, but not the station (the building to the NW of the platforms). It is impossible to access the platforms from the south side or west side whatsoever, even along the tracks, it all has to be accessed through the north through the station.

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
https://www.openstreetmap.org/#map=18/36.42592/139.27667

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

On 26 Sep 2016, at 8:33 AM, kocio-pl [email protected] wrote:

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.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@kocio-pl
Copy link
Collaborator

I had commented on this because I want to define the station's area to encompass all the amenities.

Both ways respect this rule.

the historical or architectural significance of a train station not used as a train station should be tagged and rendered differently

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.

@javbw
Copy link
Author

javbw commented Sep 26, 2016

On 26 Sep 2016, at 10:06 AM, kocio-pl [email protected] wrote:
But how?

We use theme=* for playgrounds, and we use foobar:disused=* & foobar:abandoned=* to denote a previous existing business or function of a building.
Perhaps
foobar:previous=*
foobar:architecture=*
foobar:built_as=*

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
Shop=cafe
Building:built_as=bus

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.
Would I still use building=retail when it clearly is a building=commercial or =office now? Or does the fact that it once was a 7-11 change its building classification? I think not. Same is true with train station. Moving the architecture away from usage, especially useful "major" building categories would allow for proper and consistent tagging, instead of train stations being weird outliers compared to other buildings and complexes that are easier to map and logically understand the nesting relationship between building, amenity, and landuse keys.

Javbw.

@dieterdreist
Copy link

sent from a phone

Il giorno 26 set 2016, alle ore 04:41, javbw [email protected] ha scritto:

Building=retail
Shop=cafe
Building:built_as=bus

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.
building=bus + amenity=cafe
building is about "built as", no need for new tags

@javbw
Copy link
Author

javbw commented Sep 26, 2016

On 26 Sep 2016, at 6:13 PM, dieterdreist [email protected] wrote:

discuss tags on tagging
This seems to be something that will or will not be implemented in the renderer because of tagging philosophy and practices. Is there a better place where both can mingle?

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.


I want the ability to define a station as an area - just as many other building / manmade tags have an associated area to define large and complex places. I thought railway=station would work, as building=railway_station exists, allowing for nested use, yet separates it from landuse=railway, which is for any land used for rail alignments. 

I will refrain from commenting further, unless directly addressed, as I feel my points are understood. I hope a solution can be found. 

Javbw. 


@kocio-pl
Copy link
Collaborator

@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.

@javbw
Copy link
Author

javbw commented Sep 29, 2016

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

On 29 Sep 2016, at 8:41 PM, kocio-pl [email protected] wrote:

@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.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Sep 29, 2016

It's still to general for me. =}

renderer assumes it is a building,

For me it looks like the area, not like building:
http://www.openstreetmap.org/way/114507529

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?

@javbw
Copy link
Author

javbw commented Sep 30, 2016

On Sep 29, 2016, at 11:51 PM, kocio-pl [email protected] wrote:

It's still to general for me. =}

renderer assumes it is a building,

For me it looks like the area, not like building:
http://www.openstreetmap.org/way/114507529 http://www.openstreetmap.org/way/114507529
If it's only about layers, its a more general issue (like "make layers work global for all type 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

@kocio-pl
Copy link
Collaborator

kocio-pl commented Oct 2, 2016

It was still not succinct for me, but I see several problems here:

  1. Tagging station is not clear enough currently - thanks for starting discussion on Tagging list!
  2. Station color is too dark for you. I try to use it for rendering ferry terminal, because it's darker than airport area, but we could make it lighter, as we did lately with few others. Any color you'd like to have here?
  3. Station building could be rendered like major building - and I just have technical difficulty to do it, any help would be welcome.
  4. Layers belong to other issues, like Building doesn't render on top of highway areas any more #688.

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
Copy link
Author

javbw commented Oct 3, 2016

Javbw

On 3 Oct 2016, at 4:53 AM, kocio-pl [email protected] wrote:

It was still not succinct for me, but I see several problems here:

Tagging station is not clear enough currently - thanks for starting discussion on Tagging list!

No problem, I'm trying to understand if my assumptions on tagging and how it affects rendering decisions. Seems that I am making bad assumptions because I am confusing wildly inconsistent tagging philosophies between different tags, leading to this thread.

Station color is too dark for you. I try to use it for rendering ferry terminal, because it's darker than airport area, but we could make it lighter, as we did lately with few others. Any color you'd like to have here?

I was under the assumption that the "brick" red color was for station buildings to make them extremely visible. Is that dark red color meant for station area? This might be the source of my confusion and this misunderstanding. I assumed people were tagging this on Buildings, making the buildings dark red (similar to the Google maps rendering). Is this dark red color the proper color for non-building areas(like a landuse)??

Airports are a perfect example:

terminal buildings: dark purple.
Runways/taxiways/apron: grey
Overall airport area: light purple

So I want train stations to be rendered this consistently as well:

Train Station buildings: dark red
Platforms: dark grey
Overall station area: ?????? [this thread]

Station building could be rendered like major building - and I just have technical difficulty to do it, any help would be welcome.

Because I don't use OSM in a place where it is well mapped, both in density of ways & areas as well as tagged information (Japan is very sparsely mapped and tagged correctly, much is old or outdated tagging outside of Tokyo or a scrambled mess from a GIS import 6 years ago) maybe my idea of what a "station" is - the land, the ped access, and the building renders might be outdated. Aren't stations rendered as the most visible and outstanding buildings (the red color) already?
Layers belong to other issues, like #688.

Yea, sorry, shouldn't have brought it up. It's part of my frustration of mapping large complexes, but it is not part of this ticket.
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.

It seems form a few comments on the mailing list that my assumption that the area=yes tag on the area would somehow signal that it is not a building is not right. Perhaps I should be looking to add building=no and have that tell the renderer that is an area and not a building. But I am looking for that light area, like the light purple airport grounds.

This might close this whole thread, I'm sorry if my incorrect assumptions have wasted your time.

Javbw

@kocio-pl
Copy link
Collaborator

kocio-pl commented Oct 3, 2016

I was under the assumption that the "brick" red color was for station buildings to make them extremely visible. Is that dark red color meant for station area? This might be the source of my confusion and this misunderstanding.

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.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Oct 3, 2016

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).

@kocio-pl
Copy link
Collaborator

kocio-pl commented Oct 5, 2016

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.

@jojo4u
Copy link

jojo4u commented Oct 5, 2016

which will resolve all our problems with railway stations.

Giving the nature of OSM this is meant as a joke? :)

@kocio-pl
Copy link
Collaborator

kocio-pl commented Oct 5, 2016

Well, I said our problems (related to rendering), not all of the OSM problems. 😄

@dieterdreist
Copy link

2016-10-05 15:58 GMT+02:00 kocio-pl [email protected]:

Well, I said our problems (related to rendering), not all of the OSM
problems.

there's a tiny detail apparently getting in the way (until hstore gets
activated or missing keys added), that likely it would be desirable to
place the icon according to the public_transport=station tag, which is
focussing on passengers, and which will probably be covering only the parts
of a station that are interesting to the passenger (buildings, accessible
ways, platforms)

@kocio-pl
Copy link
Collaborator

kocio-pl commented Dec 3, 2016

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:
http://www.openstreetmap.org/way/114507529

@Tomasz-W
Copy link

Tomasz-W commented Jul 3, 2018

@kocio-pl Rendering of this feature seems to be ok (there is a label and a fill also).
See:
https://www.openstreetmap.org/way/114507529
https://www.openstreetmap.org/way/479178948

Shouldn't it be closed?

@kocio-pl
Copy link
Collaborator

kocio-pl commented Jul 3, 2018

I think you're right - thanks for checking!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants