Proposal talk:Funeral hall=*

Subtypes

Very often, in tags like amenity=foobar, foobar=*, the foobar=* describes subtypes of foobar, e.g. amenity=parking, parking=multistorey. Not sure about funeral hall typologies, but I guess you could find them if you looked at enough funeral halls. "yes" and "no" are ok as properties, but "yes" could be a first step to more subtagging (i.e. everything not "no" means yes and also x). --Dieterdreist (talk) 21:10, 17 September 2020 (UTC)

Indeed, so the proposal is inline with OSM good practice. Or do you suggest to introduce now subtypes? Which ones? --Nospam2005 (talk) 21:22, 27 September 2020 (UTC)

I wonder why voting was started only 5 days after this interesting question has been raised. There's defititely more discussion and elaboration needed before the proposal gets ready for voting. --Fkv (talk) 21:58, 2 October 2020 (UTC)

When you treat foobar=* as a subtag, you always need amenity=foobar as the main tag. E.g. if you set map_size=*, you also need tourism=information and information=board. If you set tourism=information + information=board + board_type=geography + map_type=region, applications will certainly ignore map_type=region because they ignore subtags when the higher-level tag is missing. When you treat foobar=* as a flag, you should leave it simple, like atm=yes/no. You could use other values, but it doesn't make sense, because you can't define its properties in detail anyway. You can't add access=* or opening_hours=* etc, as they would apply for the main feature (the bank/supermarket/whatever), not the flag (atm=yes).

A funeral hall is definitely more than what can be mapped with just a flag. As a hall, it's at least a room, and this should be mapped as a room=* or a POI within the building. --Fkv (talk) 21:58, 2 October 2020 (UTC)

Right, like almost everything it *can* be more precise than just a flag. It doesn't *has* to. If a funeral hall is located into a shop=funeral directors with the same opening hours, if you don't have the layout of a room, what do you want to do? Ignore the funeral hall completely? Like almost every thing in OSM, we can what we can tag. You can tag as amenity=funeral_hall if you have enough information.

When I don't know the exact shape and position of the room, I map it as a node (POI). Same as with shops, addresses etc. --Fkv (talk) 23:51, 2 October 2020 (UTC)

BTW 15 days, not 5 days. --Nospam2005 (talk) 22:31, 2 October 2020 (UTC)

Sep 27 - Oct 2 = 5 days. --Fkv (talk) 23:51, 2 October 2020 (UTC)

However you count, there didn't seem to be people interested in discussing, that's why I started the vote. At least now people started to discuss, that's already a good thing, and so, I'll be happy to suspend (just put back to "Proposed"?).

On substance, for me it was a clear-cut thing, like adding toilets=* to amenity=cafe (a café having toilets) or adding atm=* to amenity=bank (a bank branch having an ATM); a completely standard way of proceeding. In the same way, adding funeral_hall=* to amenity=crematorium would indicate a crematorium having a funeral hall. That being said, if a majority is in favour of the solution to just put a node on the building already tagged, I'm fine with that as well and will just change the relevant paragrapgh in amenity=funeral_hall. I'm just wondering what you do then, if your funeral directors already was a node because you didn't know exactly. --Vollis (talk) 10:25, 3 October 2020 (UTC)

By the way, concerning your remark on changeset 71018119 on the main page. This has indeed nothing to do. That issue is rather concerned by the discussions here and here, so it's not as if I had just forgotten about it. --Vollis (talk) 11:24, 3 October 2020 (UTC)

Please note that an analogous scheme has now also been approved for amenity=place_of_mourning and place_of_mourning=yes. Vollis (talk) 15:31, 16 January 2021 (UTC)

As there is no more discussion and the idea of such a scheme seems accepted, I intend to start the vote soon. Vollis (talk) 09:22, 23 January 2021 (UTC)

room=funeral_hall

Fkv's suggestion above to use room=funeral_hall is interesting. I think it deserves a distinct discussion. Please make known what you think about this alternative. --Vollis (talk) 11:26, 3 October 2020 (UTC)

I do agree, it's an orthogonal proposal. Both are compatible, and IMHO both make sense. --Nospam2005 (talk) 19:08, 3 October 2020 (UTC)

Having a closer look at room=*, it seems to me that that key is not supposed to be used to tag the whole building of which the room is a part. If that is so, then using room=funeral_hall isn't any different than to have a node with amenity=funeral_hall within the building tagged e.g. amenity=crematorium. So, that would be just a variation of the suggestion to always map apart? In which case this sends us back to the basic choice whether we need a subtag at all or whether we want to map apart in all cases, even if it is just a room in funeral directors premises used for ceremonies the exact location of which we don't know. --Vollis (talk) 06:48, 5 October 2020 (UTC)

If it is a room inside a funeral home, then room makes sense (either as a node or an area). If we are describing a further subtype of a funeral home, it would seem that the OSM convention would want to have a funeral_directors=* key that would then indicate the specific type of funeral home. ZeLonewolf (talk) 15:54, 5 October 2020 (UTC)

Your first sentence is what I finally understood as well. On the second, I'm not sure that we can talk about a subtype of a funeral home (or of a crematorium, for that matter). Just as an amenity=cafe doesn't become a different type of café if it has toilets (toilets=yes), I doubt that a funeral home is a specific subtype of funeral home just because it has a room for ceremonies. We might also run into practical problems with all the values needed for a key funeral_directors=*. Indeed, there is another proposal for chapels of rest. Assume for a second that this is approved. Then we would get four "subtypes". (1) those with neither viewing rooms ("chapels of rest") nor funeral halls (for ceremonies), (2) those with the former but not the latter, (3) those with the latter but not the former, (4) those with both. The same for crematoria. And I'm sure, someone will find other services offered that merit tagging in not too distant a future; then it becomes exponential. --Vollis (talk) 16:36, 5 October 2020 (UTC)

First voting attempt

Below is the last state of a first voting attempt:

• I approve this proposal. --Nospam2005 (talk) 16:45, 2 October 2020 (UTC)
• I have comments but abstain from voting on this proposal. It is unclear how this differs from amenity=funeral_hall other than to "get around" not being able to apply two amenity=* tags. This would create two different ways to tag a funeral hall. Also, the use of a funeral_hall=* by OSM convention should be describing a sub-type of funeral hall, which is not what is proposed here. ZeLonewolf (talk) 18:26, 2 October 2020 (UTC)

Please take part to the proposal discussions before the vote, it follows the OSM convention as mentioned on the discussion page. --Nospam2005 (talk) 18:57, 2 October 2020 (UTC)

Updating to change to abstain since I did not participate in discussion in the first round. ZeLonewolf (talk) 19:35, 2 October 2020 (UTC)

Please move the relevant part to the discussion page. Feel free to remove my stuff --Nospam2005 (talk) 11:51, 3 October 2020 (UTC)

• I oppose this proposal. This proposal is not yet ready for voting. 2 weeks are just the minimum time span between RFC and Voting. If discussion is still ongoing, or if complex issues have been raised, voting needs to be delayed. This is the case here, see Talk page. It's strange that Nospam2005 asked an intersting question on the Talk page and then forgot about it. Before you blame people for not taking part in a discussion, you need to leave them enough time to do so. Apart from the short discussion period, I also dislike about this tag that it doesn't solve the problems that became obvious in the discussion of changeset 71018119. You agreed that they should be discussed in the wiki. These problems only exist because amenity=funeral_hall was approved before properly discussing it. Now you make the same mistake again. --Fkv (talk) 22:27, 2 October 2020 (UTC)

As for the previous vote I suggest to move the relevant parts to the discussion page.

And no, there is nothing strange, I asked Dieterdreist if he saw some usage as subtags. More than two weeks later, he hasn't given any. You haven't either. Nobody has. So it's simply a flag. It doesn't prevent to use is as a subtag later on if some people find such usage useful. --Nospam2005 (talk) 11:51, 3 October 2020 (UTC)