Add bicycle_parking capacity in render.xml

[rouelibre1]

🚀 feature request

Description

Possibility to display the value of "capacity" tag as a label on the POI on the map for amenity=bicycle_parking

Describe the solution you'd like

Have this field available in render.xml to be able have this feature in custom themes.

Describe alternatives you've considered

I'm stuck, it seems currently impossible to achieve from OsmAnd's UI or render.xml
And I don't want to mess with OSM data just to get the display on the map (ie. create a "name" field for each bicycle parking POI and duplicate the value of "capacity" field in it would be hard to maintain and violate OSM's principle of not tagging for renders)

[ceever]

Oppose (but alternative proposal).

I believe this request is too specific and there are dozens or even hundreds of POIs where such additional information would make sense to be displayed. However, who choses which information this shall be? Capacity (like in this case) is not the only thing that can be displayed.

Maybe alternatively (getting back to #5576), it would make sense to somehow make additional information for POIs quickly available, either by an extra button in the bottom POIs menu (besides Add, Marker, Share, Actions ... which could easily give up some space), or by having a floating/transparent information panel that could be drawn from the left or right.
These are just the first two ideas I could think of—I reckon there are more and better ones.

@ALL: Please add some suggestions how such additional POI information could be displayed in a convenient ways without the need for super-specific display patterns for each an every POI, like proposed originally. 🙏

[pebogufi]

A simple tag list would be easy, example:

capacity= 13
charge= 12.10€
fee= yes
internet_access= wlan
internet_access:fee= no
name= La porte des ours, Andlau
operator= CampingCarPark.com
power_supply= yes
sanitary_dump_station= yes
tourism= caravan_site

--- or may be with indenting

[ceever]

The list keys could be made a little more readable though: Underscore2space and Capitalisation.

And the display of this information could appear as hovering/transparent frame above/edging the POI at the same time as the POI menu is displayed at the bottom ... 🤔

[rouelibre1]

Here's what I had in mind

My use case is to display the value of the "capacity" tag as a label under the POI on the map (and not in some sub-menu or drawer that has to be opened, as this already exists and is not practical for some uses) (see how the blue dots of bicycle parking in the above screenshot of CyclOSM are labeled with capacity for example)

Getting to the same result in OsmAnd is my goal.

My understanding is that this is doable by making "capacity" tag available in render.xml (or generalizing to more use cases by allowing flexibility of tags in render.xml)

[ceever]

Oppose.

As explained before, where does all this end? The next thing are other POIs with capacity display, like parking. Then fee indicator for public toilets. Then open/closed indicators for shops. Then accessibility indicators for wheel chairs. Then wifi availability. Then accessibility indicators for barriers (see other issue). And so on, and so on ...
There are sheer endless possible indicators like the one requested by you, each with a specific purpose for a tiny user group. Making maintenance more complicated, reducing map readability and introducing more complexibility.

Instead, we need something alternative to your proposal that provides the information in a convenient but generic way, also applicable to other use cases and not obstructing the view.

[rouelibre1]

Well the information is already available, but in drawer to it's not directly readable on the map.
My (limited) understanding of OsmAnd's philosophy is that many parameters have been made configurable for the end user.
Giving more power to the users over the labels displayed on the map would be helpful in many cases.

[bobeeeze]

Oppose.

As explained before, where does all this end? The next thing are other POIs with capacity display, like parking. Then fee indicator for public toilets. Then open/closed indicators for shops. Then accessibility indicators for wheel chairs. Then wifi availability. Then accessibility indicators for barriers (see other issue). And so on, and so on ... There are sheer endless possible indicators like the one requested by you, each with a specific purpose for a tiny user group. Making maintenance more complicated, reducing map readability and introducing more complexibility.

Instead, we need something alternative to your proposal that provides the information in a convenient but generic way, also applicable to other use cases and not obstructing the view.

Ceever, it is not because this tag is available for display that it is necessarily displayed. It is the rendering style that will decide whether it should be displayed or not. Everyone is free to use the rendering style they want.
In this topic a user just wants to display the capacity tag for bike parking in his own render and for the moment it is not possible. So he asks if it is possible to do so. If one day someone else wants to make a rendering style that displays the capacity of car parkings, he will asks in this github to activate this possibity and the developers will integrate it or not depending on whether they find it useful or not. I don't understand why it is a problem for you. Do you belong to the Osmand Team?

[ceever]

I am sorry. I might have misunderstood the relation of rendering style and app itself. I had the feel that this definitely is a useful request to have (having more than just the name displayed), and since many similar issues are floating around (see other issue), I thought, it would be of greater use to find a more generic solution that helps a larger user group.
But what you are saying is, it is better if developers adjust the rendering style every few months or so whenever someone comes around and requires something like this?

Furthermore, I was under the impression that just like users are able to open a "Nice to have" request, I can oppose such requests and express doubts of their workings. Developers will then take all arguments and decide on the best approach. That's not the idea?

[XandrexOSM]

@ceever there are several levels where data is available, and for different parts of the application.

1. there is data in the OpenStreetMap database
2. there is the data fetched by OsmAnd from the OpenStreetMap database, that data is stored within the OsmAnd database.
3. there is then the data which can be used in several parts of the OsmAnd app, for instance :
   3a when you tap on a POI in the map and get a card with OSM attributes
   3b when the rendering style system displays things on the map

for 3b, the fact that a data (here the capacity) is available does not mean that the style will display it.
On the other hand, if a data is available in the OsmAnd database, but cannot be seen by the rendering style system, then it can never be displayed.

The request of the original poster is, for that specific attribute, which is already stored in the Osmand database, to be usable by the redering style system.
If this is implemented, you as a user will not see any drawback. So I do not understand why a user would oppose to that request.

English is not my mothertongue, so if part of my message is ambiguous, please ask me to rephrase.