-
Notifications
You must be signed in to change notification settings - Fork 819
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
Render police grounds like hospital grounds #1450
Conversation
This resolves gravitystorm#848.
I am not entirely sure whatever rendering all amenities with this yellow colour is a good idea. Maybe restricting it to education areas would be better? But that would require either lack of area rendering for some features like police or hordes of new landcover colours/patterns. I am not happy about any of this solutions. |
I thought we can use the same color for social facilities, but the problem is much harder. This is something in the roots of OSM tagging scheme: while we have very useful building scheme, we don't have anything even remotely clean and generic for areas.
I think we need general cleaning here on the project primitives level. Of course we may use some rendering strategies in the meantime for using areas colors, icons and labels, because this process may last for years and have no real solution. But we have to remember it will be very limited and case-based until we know how we should properly deal with areas. |
I'm still on the road so I haven't had a chance to review it, but I am somewhat skeptical about adding too many different features to the same color rendering. I don't see that concerns about the OSM data model are relevant here. By the time we have the data it has been processed by osm2pgsql and there are no issues telling polygons and linestrings apart. |
It's not a technical problem per se, but it means we have no system, so we have to think carefully case-by-case (and the code won't be such clean as for buildings or POIs). On the Tagging list there's a discussion about landuse=civic, so at least one more type we may consider worth showing. But what is more important is that it's hard to know which criteria we should use when thinking about rendering areas. Buildings are easy (normal rendering like building=yes, special rendering like building=*+amenity=place_of_worship, no rendering for building=no), POIs and highways are currently quite easy too (different sets of icons+colors for categories+labels), but areas are a mess - no area categories (colors are tied to specific objects) and just a few tagging schemes are recognized as areas. The problem is we need some categories for coloring/labeling areas to avoid "rainbow" map (if we keep just adding new types or colors), but it is hard to know what categories we should use, because we don't have a clear understanding what is an area at the most fundamental level. If we can do the area categorization, rendering them would be much easier and more consistent. |
I believe the crucial part is labeling, no need to color every area that has a tag which we care for, a label is the important thing when you look at the map cheers |
I would agree with you - it's easier to decide, less risky for the final look, and probably more important than coloring (it's good to know the area type and borders, but the name brings more informations). That would be close analogy to buildings: for generic buildings name tag we use standard text styling, but if we know what it is, we can use different style and even the icon. So which cases of areas we want - or definitely don't want - to show its labels, if there is a name of course? General namespaces that can be areas, which we have now (quick and dirty list):
However labels (and icons) have their own problems the coloring does not have: what label/icon should be visible when it clashes with buildings/POIs inside? For me last resort strategy would be to render areas over the objects inside. But I think first try would be to shift that name/icon somewhere within area borders if there are some important objects (more advanced version of labels placing: SNEW) - is this technically possible now? |
I still think that it would be useful to render the outline of police grounds. I would prefer using the same colour for multiple objects over using a map that looks like a rainbow. We currently use light yellow only for relatively small objects (hospitals and schools), so from the context (name and icon) is should be clear what object it is. |
After thinking more - I think that I prefer removal light yellow fill from hospitals and restricting it to education areas rather than expanding it to even more diverse meanings. I think that the end result may be that it is used for everything and therefore losing any meaning. |
All these campus structures need some coherence. While a police campus often has a mappable fence that currently provides its boundaries, modern hospitals and universities are often fenceless. University hospitals have both educational and medical function - the same colour reflects that currently quite well. Thus I'd be happy to see/keep them filled, being it the same colour for all, or two different, with education+medical tending into one, and police+civic_* (once settled) tending into the other, fire-fighters to be decided. |
2015-05-07 17:05 GMT+02:00 Mateusz Konieczny [email protected]:
+1 |
So should we have one particular area colour for all non-educational services to the community, including hospitals, police, and some that lack area rendering currently such as amenity=social_facility #1295 (32000), community_centre (27000), nursing_home (11000), fire_station (75000) which often have a campus. |
I'm curious why do you split social amenities/services like this (educational vs the rest)? But if we agree this is the right kind of split, I see the only problem that this would be a change for hospitals (now also clinics are like this and I think doctors_office campuses should be the same too). However this makes sense for me and would be huge win for many other social facilities, so there are more pros than cons. And if we include police stations, I think also about fire stations here. Do you think about any particular filling color (or maybe border color)? |
To reach a consensus with folks that want to separate them.
Oh yes, the list above were just a few examples. Added the fire people.
For a fill, I was thinking about a yellow with a bit more grey in it than the current educational. Border is a good alternative, it would fit in the consideration in #1624 to treat all humanly defined sites similar. Consequently, that might then apply to the educational sector as well, and we would need a colour scheme for all these boundaries. Such as tourism-brown, educational-yellow/light, social+civic services-yellow/dark, transportation-blue including the accommodation, nature-green. |
I still don't get why @matkoniecz and @dieterdreist think educational areas should be so special (what about hospital campuses - are they less special or what)? I think boundary color may be indeed better than fill color, because some well-micromapped places are "vanishing" because of being eclipsed (especially by grass and parkings, also by buildings - like for example this hospital). Current zoo rendering shows it really works. I guess educational areas should also be rendered in this manner (without a filling color), so we the problem of being "special" or not would be non-existent then. Colored borders are also less obtrusive than colored filling, so the map will not be so "rainbow" even when we use a couple of colors as you suggested in the last paragraph. Could you provide some code draft to test the idea (maybe also with some interesting places rendering)? |
2015-06-30 18:09 GMT+02:00 kocio-pl [email protected]:
|
I am not thinking that educational areas deserve to have fill more than hospitals and police grounds, just that using the same style for everything would make it meaningless. |
So we could have the boundary colour define the category (tourism-brown, services-yellow, etc), and the icon define the specific type (zoo, museum; school, hospital, police), many of the icons exist. |
Closing this as there seems to be no support for this change. |
This resolves #848.