Nodes/ways with building=entrance should be rendered at z18 as a tiny grey label, similar to housenumbers/housenames but possibly smaller font.
A popular use for osm is showing people how to get to your home and in the "east Germany" style giant blocks of flats the entrance/stairwell name is an important data point.
The building=entrance tag is superseded by the entrance=* scheme. However, the entrance key is not in the database. We will therefore postpone this to 3.x.
I would also recommend to render that objects (maybe both tagging schemes for some time) as it shows that OSM has highly detailed data and the entrance is (IMHO) a important info for big buildings (campus, malls, hospitals, ...) on sites to plan your route and on which side you need to enter.
As this seems to be a simple node selector and symbol, I don't understand why we schedule it for 3.x as AFAIK there is no Mapnik source patch nessesary? Can anbody please explain if this is useful?
The milestone is named "upgrade of mapnik or openstreetmap-carto.style". Here we need the entrance key in the database.
These are they keys we currently have in the database: https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style The entrance key is not there, and that's the key we need, if I'm not mistaken. As we'd need to reload the database with new keys for this, this is scheduled for 3.0. See also #1243.
Thanks for the feedback. I'm very ok with waiting for 3.0 for altering the DB import schema.
But as key:building seems to be already present, might we add building=entrance for now and replace it later on with the new tagging schema? Currently the old schema is still supported by all editors and visualized.
building=entrance is deprecated since a few weeks in josm.
Right now we have 10x more entrances=* than building=entrance. Rendering the old tag would promote a retagging to the old schema.
2015-01-21 13:17 GMT+01:00 Holger Jeromin [email protected]:
building=entrance is deprecated since a few weeks
https://josm.openstreetmap.de/changeset/7795/josm in josm.
Right now we have 10x
http://taginfo.openstreetmap.org/compare/building=entrance/entrance
more entrances=* than building=entrance. Rendering the old tag would
promote a retagging to the old schema.
+1, building=entrance is deprecated for years in the wiki and db.
Does the fix to #2488 (released with v4.4.0) also fix this issue?
addr:housename, addr:housenumber and addr:unit are now rendered also on entrance nodes.
I guess not - this is about "gate A" for example and not about addresses.
It seems the time has come to implement this feature.
entrance type and access is rendered by merged #2936
So only the name=* is missing from this issue.
We should decide what zoom level, what color (brown probably) and probably when and how to use name and ref for labels. Anybody willing to write the code or just has some ideas to move it forward?
related to #3038
What tag is being requested for rendering in this issue?
Here are the frequent combinations: (https://taginfo.openstreetmap.org/keys/?key=entrance#combinations):
227, 242 - 10.54% | ref
148, 925 - 6.91% | addr:flats
56, 224 - 2.61% | name
addr:unit is less common, and already rendered now.
The ref=* tag appears to be the most common, on over 10% of the entrance=* features.
Has anyone looked into how this is being used, and how it differs from addr:unit or addr:flats?
We now render addr:flats since PR #4082
This will solve some of these cases, but not for the larger number of entrances which have a ref=* or the smaller number that have a name. Should we just render the ref=*?
Should we just render the ref=*?
Yes.
The ref=* tag appears to be the most common, on over 10% of the entrance=* features.
Has anyone looked into how this is being used, and how it differs from addr:unit or addr:flats?
I believe it's mostly the case of numbered or "lettered" entrances, often in addition to flat ranges.
For example, an entrance could have addr:flats=1-20, and ref=1, or ref=A.
There is/was addr:entrance, which seems a bit more descriptive - but then it might be fragmenting the keyspace too much.
Thinking about a few specific examples, such entrances would need to have both addr:flats and ref rendered.
sent from a phone
On 22. May 2020, at 00:43, Richlv notifications@github.com wrote:
I believe it's mostly the case of numbered or "lettered" entrances, often in addition to flat ranges.
For example, an entrance could have addr:flats=1-20, and ref=1, or ref=A.
another case are huge sites (factories, stadiums, shopping centers, beach resorts, etc.) which have many entrances and might use letters to “number” them
another case are huge sites (factories, stadiums, shopping centers, beach resorts, etc.) which have many entrances and might use letters to “number” them
It's hard to tell if those would be cases for the name or ref tag. I've had a few discussions with people in relation to similar things, like descriptive or reference names for objects in state parks on official maps and I could never figure out what the correct route to go with it was. I could see a for either name or ref in those cases.
If the vast majority of entrance names are numbers, it would probably be better to label them with the ref tag instead. I could see a use for that in cases of emergency exists or things like loading docks. I don't think the name tag, if it's a number or not, is appropriate in those situations though.
Most helpful comment
It seems the time has come to implement this feature.