Proposal talk:Cemetery sector

name vs ref

Hi! Please separate name=* and ref=*. For example, the sentence "Cemetery section has a name (usually alphanumeric identifier, but can be arbitrary name)" suggests to add "alphanumeric identifiers" to name which is not common practice. --Tordanik 18:07, 8 July 2014 (UTC)

Hi! The common practice for cemetery sectors is currently to fill in name, and skip ref (or duplicate this information in both tags). I.e. sectors that are not alphanumeric identifiers (or those that differ from identifier) are an extremely rare case. Personally, I don't like having separate ref and name tags. But if you insist, I don't mind changing it to ref. I just want to highlight that as a map user I don't care whether it is ref or name, I just use the most common name. I.e. if I have "name=Sector 34" and "ref=34", I'd prefer to see "34" on the map, because from the context I know that this is a map of a cemetery and those numbers are sector numbers. Don't forget, that osm is for users, not for satisfaction of database aesthetics --Vanuan (talk) 19:51, 8 July 2014 (UTC)

It's not a matter of aesthetics, but of correct functionality. The number should in fact be in "ref"; if the renderer deems it appropriate, it will render the string with "ref - name". --SimoneSVC (talk) 07:53, 15 July 2014 (UTC)

Support Tordanik, ref=* is needed. --Az09 (talk) 09:54, 9 July 2014 (UTC)

Ref is needed, for example in Staglieno cemetery we have the "Campo dei fanciulli" (children field) which has also a reference number http://www.openstreetmap.org/way/157811531 --Sarchittuorg (talk) 13:07, 14 July 2014 (UTC)

Support either/both. I was mapping a cemetery with an area named "Lawn 7" and another named "Section C". I'd like the choice of using ref=C and/or name=Section C. --Dle0 (talk) 10:32, 23 May 2015 (UTC)

Date of first burial

Please add "Date of the first burial in the section" or period. --Az09 (talk) 09:54, 9 July 2014 (UTC)

Wouldn't something like start_date=* work for this? --Jgpacker (talk) 20:29, 9 July 2014 (UTC)

Added. --Vanuan (talk) 21:30, 12 July 2014 (UTC)

I think end_date=* wouldn't work for this though. To me, it would look like the cemetery sector is closed or in ruins or something like that. To be honest, I'm not 100% sure start_date=* works the same too. --Jgpacker (talk) 22:45, 12 July 2014 (UTC)

Yeah, in most cases end_date would be the same as cemetery closure date. I also think that start_date and end_date are not valuable and are not easily trackable on the ground (you would have to have a list of all burials in this sector). --Vanuan (talk) 03:02, 13 July 2014 (UTC)

What about the sectors when they exhumate and then bury again? It'd have to set again the start_date --Sarchittuorg (talk) 14:08, 14 July 2014 (UTC)

I think you're not realistic. Let's don't try to define corner cases, we'll anyway miss some. --Vanuan (talk) 17:26, 14 July 2014 (UTC)

This proposal is only talking about one sector of a cemetery. One sector certainly could get filled up before the whole cemetery is filled up. Some cemeteries do have lists of all burials like you speak of (for example, military cemeteries). I could see that being helpful for geneologists or historians. I think start_date and end_date would work fine. If the cemetery is in ruins or abandoned, there are other tags that should be used to indicate that. --Neuhausr (talk) 15:48, 15 July 2014 (UTC)

It's not a problem to use start_date=* or end_date=*, the problem would be to re-define them when applied on a cemetery sector. That would not be possible. If start_date=* and end_date=* are used, they will mean date of construction of the object or opening and date of destruction or closing of the object, respectively. If the date of first and last burial are relevant, they should be added as different tags. --Jgpacker (talk) 16:27, 15 July 2014 (UTC)

Roman numbers?

Shall we write (probably in ref=*) also alphanumeric numbers if on the ground the numbering system is Roman numbers (I, II, III, IV, ...) ? I would think not. --Dieterdreist (talk) 14:02, 14 July 2014 (UTC)

Alphanumeric includes Roman numbers. I, II, III, IV are all alphanumeric --Vanuan (talk) 17:23, 14 July 2014 (UTC)

I am not sure. Alphanumeric describes the 26 latin letters plus the 10 Arabic numerals, so usually you'd expect numbers to be expressed in Arabic numerals and not in Roman Numerals. I also don't know why we would impose this system on someone living somewhere where another numeric system is used. (Personally for me it is not a problem, as I am used and like to use the alphanumeric system). I was just wondering why "alphanumeric" was explicitly defined and would not better be omitted. --Dieterdreist (talk) 13:58, 15 July 2014 (UTC)

I, V, X, L, C are latin letters. Alphanumeric just means you can use only [A-Z0-9] characters (no spaces, dashes, dots, commas, colons, etc). Otherwise you should use name. For example "Sector A1" should be placed in name, while "A1" should be placed in ref. As I already said, I don't care about name or ref being used, but since somebody insist on such difference, I think I should somehow define the difference between those. --Vanuan (talk) 15:17, 15 July 2014 (UTC)

name=* is for a human-given pronounced name. A referential designation, that is in a directory, cadaster etc, must be entered into the ref=*, regardless of symbols used in the designation. If a section has a name "Merchants' corner" and a catalogue number "Q-31" then it should be tagged with name=Merchants' corner + ref=Q-31. --Surly (talk) 16:42, 15 July 2014 (UTC)

area=yes

I don't understand why area=yes is required. Aren't all sectors areas? --Dieterdreist (talk) 14:02, 14 July 2014 (UTC)

It would help some editors that don't yet recognize this tag as an area. --Vanuan (talk) 17:29, 14 July 2014 (UTC)

-1. This looks like improper tagging to abuse a consumer. --SimoneSVC (talk) 07:55, 15 July 2014 (UTC)

Adding area=yes to an area is not wrong, though. And until we have a proper area datatype, it helps new tags to get interpreted properly. But I agree that it should not be in the proposal. --Tordanik 15:12, 16 July 2014 (UTC)

While I personally disagree with you, I'll delete area=yes. --Vanuan (talk) 15:19, 15 July 2014 (UTC)

cemetery=sector

I wonder if cemetery=sector is the best tag naming approach. "Thinking loud" here, because I don't have a better suggestion, still I see some problems: typically a=b, b=c tags in OSM are subtags, where "c" expresses a type or subtype of b, while here you seem to be creating a whole cemetery namespace instead. Maybe subdivisions occur also in other contexts and this tag could be more generic? Or more specific in an established key namespace, something like boundary=cemetery_sector? The latter is not really great tagging on the other hand, as a boundary is a linear element, hence this tag would logically be applied to the sector borders/boundaries, and not to the enclosed sector area. --Dieterdreist (talk) 14:02, 14 July 2014 (UTC)

I think it's the most intuitive one. There is a draft generic proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Section But personally, I don't like it. However, I don't care about specific tag name being used. I just want this feature to be defined as soon as possible. --Vanuan (talk) 17:54, 14 July 2014 (UTC)

That was the first thing I thought about and I don't think it's such a bad idea. For example it could just be sector=cemetery instead of cemetery=sector then you could for example have a general render rule for a sector and don't have to work with all the different values, but of course still can. And it would make it easier for additional common tags like sector: --AndiG88 (talk) 16:32, 15 July 2014 (UTC)

Well I would like this suggestion wouldn't I, but I think it has manifold advantages in both providing a more generic tag which, for instance could easily be used by renderers to add the cemetery section name (and or ref), as well as for the other use cases I mentioned in the original proposal. It would also remove the subtag issue described above. SK53 (talk) 16:55, 15 July 2014 (UTC)

I think cemetery=sector is OK and very usefull so we should start voting.

We already have cemetery=grave and we can add other cemetery entities with "cemetery=*". This would make it very easy to control all the objects in the cemetery. --Władysław Komorek (talk) 10:32, 21 September 2017 (UTC)