Proposal:Cemetery sector

From OpenStreetMap Wiki
Jump to navigation Jump to search
Cemetery sector
Proposal status: Abandoned (inactive)
Proposed by: Vanuan
Tagging: cemetery=sector
Applies to: area
Definition: Cemetery sector boundary.
Statistics:

Rendered as: *
Draft started: 2014-07-08
RFC start: 2014-07-14
Vote start: *
Vote end: *
Cemetery sector.jpg
Cemetery sector scheme.jpg

Usage

Proposal

Many cemeteries are very big, so they are divided into sectors (sections, blocks, etc). Each sector has hundreds of graves.

The proposal is to define a tag for mapping (and rendering) cemeteries sections.

Cemetery section usually have an identifier, but can have a dedicated name.

Rationale

If you want to visit a cemetery, you would be astonished by the cemetery size and you should have a detailed map, at least at the sector level.

Tagging

  • cemetery=sector
  • name=[sector name]
  • ref=[sector number]

Required Tagging

  • cemetery=sector

Optional Tagging

  • name=sector name
  • ref=sector number
  • start_date=YYYY-MM-DD - Date of the first burial in the section
  • end_date=YYYY-MM-DD - Date of the last burial in the section

Applies to

Areas

Rendering

Dotted line with text in the middle of polygon. Text appears at zoom levels starting from 16.

Comments

Please use the discussion page.

See also

Preliminary votes

  • I approve this proposal I approve this proposal. Vanuan (talk) 23:11, 7 July 2014 (UTC)----
  • I approve this proposal I approve this proposal. --Władysław Komorek (talk) 07:10, 8 July 2014 (UTC)
  • I approve this proposal I approve this proposal. SK53 Have wanted this sort of thing for ages, see Proposed_features/Section from 2009! SK53 (talk) 08:41, 8 July 2014 (UTC)
  • I approve this proposal I approve this proposal. Az09 (talk) 12:19, 21 January 2015 (UTC)
  • I approve this proposal I approve this proposal. (but could be extended to cover other cemetery objects, please consider a more extensive system to cover tombs and other features) --Sarchittuorg (talk) 13:05, 14 July 2014 (UTC)
  • I oppose this proposal I oppose this proposal. 1) Bad key. Cemetery sector is not subtype or characteristics of landuse=cemetery, so it shouldn't use cemetery=* key. 2) area=yes is not needed. This object is area by default. 3) It's not time yet to start a voting. Discussion is on, so please delay the voting for some time and listen the opinions. --Surly (talk) 18:19, 14 July 2014 (UTC)
  • I oppose this proposal I oppose this proposal. for the same reasons (1 & 2) as Surly --Escada (talk) 09:00, 15 July 2014 (UTC)
  • I oppose this proposal I oppose this proposal. We need this tag but "area=yes" is not required. And it should be possible to use it as a node as well (when the sector boundary is fuzzy or unknown). I have no problem with the key itself and can be extended to other cemetery stuff later. But you move too fast on the adoption process. It will succeed only if you take into account the feedbacks. --Pieren (talk) 09:13, 15 July 2014 (UTC)
  • I oppose this proposal I oppose this proposal. I think the same as Pieren --Foxxi59 (talk) 11:48, 16 July 2014 (UTC)
  • I abstain from voting but have comments I have comments but abstain from voting on this proposal. I'm not into cemetery tagging, so I won't oppose it. But I see two problems with the proposal:
  • The tag area=yes is unnecessary, as was already mentioned.
  • cemetery=sector is not a good key, in my opinion. Such keys are usually used to specify more precisely what kind of cemetery it is.
I would recommend subclass-keys, which are used within the area tagged with landuse=cemetery
  • cemetery:sectorname=[name]
  • cemetery:sectorref=[ref]
Just my thoughts. Maybe it would be better to go back to RFC for some time. --Imagic (talk) 13:22, 16 July 2014 (UTC)
  • I oppose this proposal I oppose this proposal.Why is ref insufficient?Basstoelpel (talk) 04:40, 23 July 2014 (UTC)
ref is sufficient, but there is also optional name. I don't care about name vs ref. --Vanuan (talk) 01:29, 25 July 2014 (UTC)
  • I approve this proposal I approve this proposal. The hierarchical "cemetery" key might not be ideal, but until someone offers a better suggestion I support this one. --Tordanik 18:05, 25 July 2014 (UTC)
  • I approve this proposal I approve this proposal. I agree with Pieren's idea: this tag should be applied to nodes as well. --kisaa (talk) 01:14, 6 October 2014 (UTC)
  • I oppose this proposal I oppose this proposal. Good idea, but... key "name" is a bad idea as anything has a kind of name, but is not further specific. Area is implicit, isn't it? I think even a single node make sense. I support cemetery:xxx=yyy tagging scheme. --EinKonstanzer (talk) 20:55, 27 December 2014 (UTC)
  • I approve this proposal I approve this proposal. I agree with kisaa: this tag should be applied to nodes as well. --Dromedar61 (talk) 17:45, 4 October 2015 (UTC)
  • I approve this proposal I approve this proposal. Sledzik1984 (talk) 19:35, 28 October 2015 (UTC+1)----

Preliminary results

There were the following comments after RFC:

  • Bad key
    • cemetery:xxx=yyy suggested
  • area=yes is not required (accepted)
  • some comments against allowing "name"
  • allow applying to points

There was a fair amount of support for this proposal as is. I don't know how to proceed. Should we organize voting for each of these suggestions? Or voting overall?

Voting for "bad key" (cemetery:xxx=yyy) means we should start from the scratch. While "name" and "points" are trivial.

--Vanuan (talk) 18:38, 1 September 2016 (UTC)

I do not agree to add "Bad key". This proposal is OK and it is already implemented on many cemeteries. Thus, the vote should be accepted positively, not delayed indefinitely. --Władysław Komorek (talk) 09:16, 23 October 2017 (UTC)