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

Add icons for popular sports pitches #3651

Closed
wants to merge 2 commits into from
Closed

Add icons for popular sports pitches #3651

wants to merge 2 commits into from

Conversation

Adamant36
Copy link
Contributor

Formalities
This PR adds icons for popular sports pitches. The sports included in the PR are baseball, basketball, soccer, and tennis.

In light of the recent discussion surrounding icon bloat, I thought it was a better idea to split PRs for sports icons based on popularity of the tags. While some tags sports like shooting have comparatively low tagging number and therefore might be a harder sell and therefore less chance of being added, all the sports in this PR have relatively high numbers and there is clearly demand, along with need, for them to be added to be added to the map. In fact, they all have much larger usage numbers then sport=swimming. Which currently has an icon. In general, sports pitches are good candidates for icons in respect to clutter due to them usually having a wide area that doesn't contain other types of icon inside of it.

Advantages of merging this PR

  1. It will display icons and names of pitches for these sports when mapped as nodes
  2. It will help people to tell what specific sport a pitch is for in places with multiple pitches. Along with weather the sport=* tag is added to the specific pitch or not.
  3. It will hopefully reduce the amount of pitches that get tagged with the name of the sport the pitch is used for (examples of the problem can be seen in a few of the test renderings).
  4. It will reduce the amount of issues opened and questions asked related to adding sports icons (although minor, its still a benefit).

Disadvantages

  1. It expands the code in the amenity file a little more then id like. Although it could potentially be dealt with by compacting the code more, I don't have the skills to do it myself. So it would have to done in a separate issue by someone else.
  2. ?

Test renderings
baseball
https://www.openstreetmap.org/#map=19/37.33632/-121.86619 (way)
baseball way
https://www.openstreetmap.org/#map=19/38.79903/-122.54894 (node)
baseball node
basketball
https://www.openstreetmap.org/#map=19/38.16716/-122.23726 (way)
basketball way
https://www.openstreetmap.org/#map=19/38.79903/-122.54894 (node)
basketball node
soccer
https://www.openstreetmap.org/#map=19/37.97576/-122.53391 (way)
soccer way
https://www.openstreetmap.org/#map=19/38.68179/-121.44361 (node)
soccer node
tennis
https://www.openstreetmap.org/#map=19/38.16685/-122.23624 (way)
tennis way
https://www.openstreetmap.org/#map=19/38.46384/-123.00969 (node)
tennis node

@jeisenbe
Copy link
Collaborator

jeisenbe commented Jan 20, 2019 via email

@Adamant36
Copy link
Contributor Author

The icons look very intuitive on the pitches, except perhaps for the
basketball backboard. I don’t recall if a ball icon was tested instead, but
perhaps that would be easier to recognize?
A ball icon was tested and rejected because it's less intuitive.
basketball icon
The only other one I can think of is from iD Editor. Which is a backboard and ball. Its probably to detailed to work though.
id editor basketball icon
Whatever the case, the icon is going to be either a backboard, a ball, or a combination of both. I think a backboard is the best option. We can't fit a ball and backboard into 14x14 pixels and it probably wouldn't look any better if we could anyway.

I am a little concerned about adding sport icons on nodes without a pitch.
This is less intuitive and will be adding new features to the map, rather
than improving existing features.

I'm not 100% sure about adding icons on nodes either. Its not wrong tagging though. The wiki says pitches can be mapped as nodes and that its the preferred method where the boundary of the pitch is not clear. 35,915 of them are tagged that way. So, "adding extra features" isn't necessarily bad when its how the tag is used. To me, that's just proper rendering.

Ultimately if only 35,915 out of 1,437,809 are rendered as nodes its an extremely small amount and probably won't make that much of a difference when it comes to map clutter anyway. Also, only a small fraction of those are probably included in these sports. Plus, its not an issue with swimming. So there's no reason to make it one here. Otherwise, swimming node rendering should be removed.

@imagico
Copy link
Collaborator

imagico commented Jan 20, 2019

I am not convinced by this. Reasons:

  • The symbols are very bold and noisy for a minor additional characterization
  • There is a lack of consistency in design between different sports - leading to inbalance and confusion when they are shown together.
  • Several of the symbols are non-intuitive on a global level - the soccer symbol for example is based on a specific and non-universal ball design. The tennis symbol is a generic symbol for any kind of racket ball sport making it prone to tagging for the renderer if other racket sports are not rendered with a symbol.
  • Rendering nodes with symbol only but without a generic symbol for leisure=pitch alone is counter-intuitive for the mapper and incentivizes against one feature, one OSM element (by suggesting to tag multi-use pitches with several pitch nodes)
  • Selectively rendering leisure=pitch + sport=* might also be counterproductive for mapping indoor sports infrastructure - for which tagging sport on leisure=pitch probably is not the most common method (there are for example 82k combinations leisure=sports_centre + sport'=*). That would deserve more thorough analysis.
  • Combining offset labels under symbols with way_area based label scaling would be against established design practice.
  • The lack of a sustainable overall concept for rendering sport pitches and point symbols in general indicating an inflation similar to as it has happened for shops.

@jeisenbe
Copy link
Collaborator

  • The symbols are very bold and noisy for a minor additional characterization

Is this because of the color or the icon shape or size?

I didn't want to bring it up, considering all the other icons colors that need adjustment, but I do think that the leisure-icon color could be less saturated.

Perhaps basing the color off of @pitch instead of @park would also improve the rendering for these icons, while making them less prominent on the pitch background.

  • Several of the symbols are non-intuitive on a global level - the soccer symbol for example is based on a specific and non-universal ball design.

Most of the soccer balls that I've bought here in Indonesia, as well as in Costa Rica and in the USA, have used this classic pattern. It was introduced at the 1970 World Cup in Mexico, the first to be broadcast on TV.

The tennis symbol is a generic symbol for any kind of racket ball sport making it prone to tagging for the renderer if other racket sports are not rendered with a symbol.

Good point. Would you support using this symbol for other racket sports as well, or are you suggesting not rendering any of these?

  • Combining offset labels under symbols with way_area based label scaling would be against established design practice.

Yes, that should be fixed.

@@ -218,6 +218,34 @@
marker-clip: false;
}

[feature = 'leisure_pitch'][sport = 'baseball'][zoom >= 17] {
Copy link
Collaborator

@jeisenbe jeisenbe Jan 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can combine all the sports under one `[feature = 'leisure_pitch'] rather than repeating this 4 times, eg:

  [feature = 'leisure_pitch'][sport != null][zoom >= 18] { 
    marker-fill: @leisure-green;
    marker-placement: interior;
    marker-clip: false;
    [sport = 'baseball'] {
      marker-file: url('symbols/sport/baseball.svg');
    }
    [sport = 'basketball'] {
      marker-file: url('symbols/sport/basketball.svg');
... etc.

And then add a SQL query in project.mml , I think something like:

     CASE WHEN tags->'sport' IN ('baseball', 'basketball', 'soccer', 'tennis') then sport ELSE NULL as sport,

instead of tags->'sport' as sport, - this will prevent a generic marker from rendering for pitches without one of the specified sports.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might give it a try. If not, maybe someone else can do it later after its implemented. I was under the impression that its better not to do an SQL query if you don't have to though. Since its what slows down rendering. There's enough CASE WHEN tags-> instances already in my opinion.

@Adamant36
Copy link
Contributor Author

Good point. Would you support using this symbol for other racket sports as well, or are you suggesting not rendering any of these?

@jeisenbe, the only other racket sport that has enough usage for rendering is table tennis and it had a different icon (its not really a "racket" sport anyway either). There is badminton with 1993 uses, but know one requested it or any other racket sports in the original issue. The only other similar one I could find on tag info is Paddle tennis with 346 uses and its essentially just tennis. So there isn't even any other racket sports on taginfo that would even be requested. If badminton ever was it would probably have a shuttlecock in the icon with the racket.

That being said, I don't see why the symbol couldn't be generalized to other racket sports if ever was any, but that's no different then other icons for other tags that are similar with each other.

@@ -2565,10 +2593,17 @@
[feature = 'leisure_ice_rink'],
[feature = 'leisure_pitch'] {
text-fill: darken(@pitch, 40%);
[sport = 'baseball'],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you add the SQL query as suggested above, you can change this to [sport != null] instead of writing up a long list, I think.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, it should be safe enough to add generic text-dy, so please change it.

@jeisenbe
Copy link
Collaborator

Rendering nodes with symbol only but without a generic symbol for leisure=pitch alone is counter-intuitive for the mapper and incentivizes against one feature, one OSM element (by suggesting to tag multi-use pitches with several pitch nodes)

It would be great if we could design a good generic icon for multisport pitches, or pitches without sport=*, to address this.

I don't recall seeing an example. Does anyone have a idea of an icon that would work?

@imagico
Copy link
Collaborator

imagico commented Jan 21, 2019

  • The symbols are very bold and noisy for a minor additional characterization

Is this because of the color or the icon shape or size?

It is a combination of different aspects. Combining subtlety and readability is hard but there are many possibilities you can try - both within the idea of using a point symbol and outside of it.

Perhaps basing the color off of @pitch instead of @park would also improve the rendering for these icons, while making them less prominent on the pitch background.

Note the current pitch outline color is also in quite serious disharmony with the fill color which obviously does not help in that regard.

The tennis symbol is a generic symbol for any kind of racket ball sport making it prone to tagging for the renderer if other racket sports are not rendered with a symbol.

Good point. Would you support using this symbol for other racket sports as well, or are you suggesting not rendering any of these?

I have no opinion on this but i expect a consistent and viable concept for how this is to be handled. And as said a broader reconsideration of the general approach for differentiating different sports would be advisable instead of just looking at individual symbols.

And in terms of point symbols by the way there is hardly any other thematic field where there is a broader body of pre-existing work on consistent symbolizations than in the fields of sports. From my point of view therefore the expectation that an initiative to add differentiated sport symbology is accompanied by an overall design concept for this is not exorbitant.

@Adamant36
Copy link
Contributor Author

@jeisenbe, do you want me to try testing the icons with the pitch color instead of the park color? Or do you think its a waste of time?

@jeisenbe
Copy link
Collaborator

jeisenbe commented Jan 21, 2019

It's certainly reasonable to consider how the sport symbols will look compared to the pitch outline and fill color.

If you don't mind, I'd suggest trying some different colors for these icons. As discussed in #3641, there is plenty of room for another icon color on the bluer side of green, which would be more similar to the pitch color.

The fill color for @pitch is #aae0cb LCH(85,22,168)

An icon color based off of this would be LCH(60,35,168), #46a083 - this has a delta of over 40 with the most similar blue icon color, and with the current leisure green.

I'd also suggest trying a more harmonious outline color for pitches, so that the outline does not clash with the color of the icons.

Let's try @sport-icon: #46a083 with a new @pitch-outline: #74b9a0 - this color #74b9a0 is LCH(70,28,168), so it's about halfway between the pitch fill color and the suggested sport icon color. It also follows the pattern seen with retail and retail-outline, commercial and commercial-outline etc: L is 15 darker and C is a few points more saturated.

Pitch, new outline, new sport icon color, park color:
small-lch-pitch-outline-sport-park

pitch-pitchoutlinenew-sporticon-park-lch

Test rendering in Wamena with #46a083 for sports symbols and #74b9a0 for pitch-outline:
(https://www.openstreetmap.org/#map=17/-4.09499/138.93994)
z17
z17-sports-test
z18
z18-sports-test

  • It looks like z17 is too soon to render these, at least for small pitches near the equator. A possible solution would be to add [way_pixels > 750] - this would make sure that the symbols are only rendered on pitches that are larger than the height and width of the icon, in almost all cases.

@imagico
Copy link
Collaborator

imagico commented Jan 21, 2019

Yes, that is much better.

I agree on the starting zoom level as well - in particular in case of tennis pitches, it is common to have several of these side by side and the starting zoom level needs to be chosen so that symbols do not block each others at the starting zoom levels leading to arbitrary and confusing selection which to show and which not to show. Near the equator this is probably a problem even at z18 with a 14 pixel symbol:

https://www.openstreetmap.org/#map=18/1.29946/103.77723

@Adamant36
Copy link
Contributor Author

@jeisenbe, thanks for the test. It looks a lot better. I agree the zoom could use adjusting to. I was thinking z18 but z19 might work also. As well as your way pixel idea. I guess it needs testing.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Jan 21, 2019 via email

@Hufkratzer
Copy link

Hufkratzer commented Jan 23, 2019

If someone still has a problem with the racket icon for tennis (I don't have such a problem), here is an alternative icon:
tennis4 tennis.svg
(diameter only 12px because tennis balls are smaller than soccer balls)

EDIT: Icon updated 10 min ago

@Hufkratzer
Copy link

Rendering nodes with symbol only but without a generic symbol for leisure=pitch alone is counter-intuitive for the mapper and incentivizes against one feature, one OSM element (by suggesting to tag multi-use pitches with several pitch nodes)

It would be great if we could design a good generic icon for multisport pitches, or pitches without sport=*, to address this.
I don't recall seeing an example. Does anyone have a idea of an icon that would work?

I assume supporting the comma-separaded list of sports would reduce the incentive to tag multi-use pitches with several pitch nodes.

Here is some icon with a soccer and a volleyball:
multi multi.svg
It is derived from @Tomasz-W's icons and I took soccer and volleyball because these can often played on the same small pitches in sports halls. Probably not so good to draw this on any pitch with no sport tag.

@Adamant36
Copy link
Contributor Author

Adamant36 commented Jan 27, 2019

@jeisenbe, where's @pitch-outline: found in the code? All I can find is line-color: saturate(darken(@pitch, 30%), 20%); on line 697. I don't necessarily feel like creating a new variable for it or whatever. So can you just tell me what the @pitch-outline: color is in "darken pitch percent" format we are already using?

Really, I rather it just be done in another issue. Since it had nothing to do with the icons in the first place.

Also, what color do you think should be used for the icon text? It's currently darken(@pitch, 40%). I guess darken(@sport-icon, 40%) would probably work.

@Adamant36
Copy link
Contributor Author

I changed to the icon to what @jeisenbe, suggested and went with the icon color darkened by 40% for the text. It looks good to me. I also changed the zoom levels to z18 for baseball and soccer, along with z19 for basketball and tennis. The pitch outline can be changed in another issue. I don't feel like doing it and it wasn't the purpose of the original PR anyway. So if someone wants to review the PR so it can be merged and I can get on to other things, id appreciate it.

sports icon color change

@jeisenbe
Copy link
Collaborator

jeisenbe commented Jan 27, 2019 via email

@@ -2565,10 +2593,17 @@
[feature = 'leisure_ice_rink'],
[feature = 'leisure_pitch'] {
text-fill: darken(@pitch, 40%);
[sport = 'baseball'],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, it should be safe enough to add generic text-dy, so please change it.

}
}
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove trailing spaces.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did what @jeisenbe suggested and it didn't work. Maybe you or him can look over it and tell me what I did wrong. SQL isn't really my area of expertise.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not to be a jerk or anything, but does it matter what at all what I feel doing with a PR or not? I was fine with it being rejected if the code was to complicated. Now its extra work that I didn't want to do and @jeisenbe could have done himself in another PR. Since he's the one that suggested it and knows how to do that stuff. It does zero good though if I screw the PR up in the process of trying to implement something I don't have the knowledge how to do. Or I probably would have just done it that way in the first place. I'm lucky I got the icons to render as it was.

@kocio-pl
Copy link
Collaborator

@imagico You have brought multiple issues, but I don't follow the changes. Is there still something blocking merging this code from your point of view?

@imagico
Copy link
Collaborator

imagico commented Jan 28, 2019

Yes, both the arguments brought up here and those in #3635.

@kocio-pl
Copy link
Collaborator

It's not clear for me - which two out of seven are still to be resolved?

#3635 is even less clear to me (no core problem I could identify), but my impression was that this is not "big city" feature, so this should not be a problem?

@Adamant36
Copy link
Contributor Author

I need to fix the SQL anyway. After that though, I don't see how it would be a problem with #3635. Imagico, you said so yourself that you weren't against new icons per say, this seems like a good place to allow them. I've seen no good argument otherwise.

@kocio-pl
Copy link
Collaborator

Oh, I just got it - "both" as in both places, not "both from here", sorry. What I'd like to know is:

  1. are all of them still not resolved?
  2. which ones are blockers for you and which ones are rather wish list?

@imagico
Copy link
Collaborator

imagico commented Jan 28, 2019

I gave my assessment and the reasoning behind it - both here and in #3635. If that changes i will say so.

I would like to add that while there are some relatively specific - technical if you want so - issues i mentioned with this PR the lack of a sustainable outlook for both point symbol rendering in general and for sports infrastructure specifically is a major blocker.

Therefore at this point working on a consensus on #3635 through arguments and evidence, by developing sustainable concepts for the future of POI symbol rendering in this style would probably be the advisable approach to the matter.

@Adamant36
Copy link
Contributor Author

Therefore at this point working on a consensus on #3635 through arguments and evidence, by developing sustainable concepts for the future of POI symbol rendering in this style would probably be the advisable approach to the matter.

It doesn't seem like #3635 is going anywhere. Your the only that's had any real complaints about it, which aren't even clear. It would be none sustainable (I don't know what a good word is) to put the rendering of all new features or icons on hold until your satisfied. Even if it was more then just you that had a problem with it, plenty of "meta tickets" have gone know where, we haven't not modified or added things related to those in the mean time though, and I don't think #3635 should be treated any different.

a sustainable outlook for both point symbol rendering in general and for sports infrastructure specifically is a major blocker.

As vague as you where about those issues, there won't be a sustainable outlook on either of them until your clearer on what specific issues you have. Especially with "sports infrastructure." I'm not trying to make it personal, but again your the only person that has taken issue with it out of all of the conversation there has been over the last five years on it and I still have no idea what your specific problem is.

@kocio-pl
Copy link
Collaborator

sustainable outlook for both point symbol rendering in general and for sports infrastructure specifically is a major blocker

For me this sustainable outlook would be something like "sport infrastructure should be rendered using shades of green different than vegetation (unless the context does make it clear), individual sports could be indicated by icon symbol related to it".

For point symbols in general it's harder of course, but I would draft it more or less like "Point symbols are used for relatively small features, but can be also used for making some areas easier to understand. There's only limited set of colors that could be distinguished, but there are multiple shapes that could be recognized, especially using similar colors to show they belong to the same group".

I don't see much use in defining it more specific, it is the role of ticket discussions to get to the details of implementation. For example golf takes a lot of place, so should be rendered earlier (and it is), while table tennis takes small space, so this should happen at the highest zoom levels.

@Adamant36
Copy link
Contributor Author

"Twiddles thumbs"

I don't see much use in defining it more specific

It seems like you defined it well enough. Can we take @imagico's silence/none specifics here and in #3635 that we can move along with this? I think 21 days without more being said is long enough to wait and I'd like to see this either get merged or closed. Whatever else needs to be said about a "sustainable outlook for symbol rendering" or whatever can be done in another ticket if need be.

If I remember correctly, @jeisenbe did a PR for the pitch outline color correction. I'm not sure what else needed to be done on it. Maybe he can refresh my memory if anything else needs doing and assuming the PR doesn't just get closed.

@kocio-pl
Copy link
Collaborator

Can we take @imagico's silence/none specifics here and in #3635 that we can move along with this?

He said that if he changes his mind, he would tell it, so obviously no.

However lack of any reply does not help finding a common ground. @imagico (and @matkoniecz, since he added 👍), could you tell what can be done now to reach acceptable solution?

@imagico
Copy link
Collaborator

imagico commented Feb 18, 2019

I have not commented any further because there so far is nothing to add to what i already commented.

As said there are issues i pointed out that are of fairly technical nature that could be addressed specifically on this PR. @jeisenbe above well demonstrated that once you do that you can immediately get to improvements.

But as also pointed out the bigger problem is developing consensus on #3635. Therefore i already recommended three weeks ago to concentrate on that. @matthijsmelissen promised he would look at that again when time allows and i look forward to his comments. From the maintainers so far i think @sommerluk is the only one who has not articulated an opinion on #3635 so his views would be very valuable there as well.

@Adamant36
Copy link
Contributor Author

As said there are issues i pointed out that are of fairly technical nature that could be addressed specifically on this PR.

That makes sense. I guess I'm not clear on what specifically those technical issues or their solutions are. Maybe you could put it in terms a layman like myself can understand?

But as also pointed out the bigger problem is developing consensus on #3635. Therefore i already recommended three weeks ago to concentrate on that.

I agree consensus there is important. Issues like that tend to take a really long time to resolve and usually stall end getting stalled out instead though. There's plenty of other issues like it that have gone know where. So I disagree that all development on new features should be stopped until its worked out. Since it could potentially take years or just not be worked out ultimately.

Generally, how things are implemented should be changed when new guidelines are written, but not halted just because a discussion about it is happening or in anticipation of a guideline change that might not happen. Id say that applies to any type of organization. Not just here. There's plenty of meta issues around where we continue developing things related to them while they were still being worked out. There's no reason #3635 should be a particular exception.

@imagico
Copy link
Collaborator

imagico commented Feb 19, 2019

Well - at this point i see no consensus forming on this PR without consensus on #3635. So the options would be to put this on hold until we have found a way forward on #3635 or to reject this.

You can also try to make changes here to turn this into a change that finds approval on its own but as said this would be difficult because of the fundamental concerns that reflect things also discussed in #3635 so i am reluctant to recommend investing a lot of work here with unclear outcome. I can see some options to indicate sport types on pitches that i could probably support and there might be others i don't see but those all would probably go more in the direction of a new PR than a development of this one.

@Adamant36
Copy link
Contributor Author

@matkoniecz, what's your specific issue with it?

@Hufkratzer
Copy link

@imagico

I can see some options to indicate sport types on pitches that i could probably support and there might be others i don't see [...]

Which? May I remind you that the idea to indicate sport types on pitches with icons originally came from @matthijsmelissen (see #844)?

@imagico
Copy link
Collaborator

imagico commented Feb 19, 2019

I can see some options to indicate sport types on pitches that i could probably support and there might be others i don't see [...]

Which?

I don't know - i have not given this much thought. But given that so far only one very specific and fairly non-innovative idea has been suggested and the problems this comes with my intuition says that other options in the cartographic repertoire available are likely more promising. But i can't really tell until someone thinks this through more thoroughly and outside the box so to speak.

I already mentioned above in #3651 (comment) that sport symbology is is a vast field with plenty of pre-existing work to draw inspiration from.

But i don't want to pressure anyone to work in a specific direction. Every developer should be free to work on the problems they are interested in using the methods they prefer. As a maintainer i mainly try to make sure changes keep the style on a sustainable path in line with the purposes of the project.

@Adamant36
Copy link
Contributor Author

But i don't want to pressure anyone to work in a specific direction. Every developer should be free to work on the problems they are interested in using the methods they prefer.

@imagico, it would still be good to know what your opinion on how z19 should be used is. Your one of the maintainers and if your fine saying you don't like something I'm not sure what the difference is. Since your already pressuring people away from a specific direction.

A while back I went off about how I think z18 is under utilized. It mostly feel on def ears though. There's a few other zoom levels besides it that could used better to in my opinion. There should be some basic idea of what each zoom levels purpose is. So id like to know what your thoughts are on it.

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

Successfully merging this pull request may close these issues.

5 participants