Talk:Tag:amenity=post box

From OpenStreetMap Wiki
Jump to navigation Jump to search

Disused Post Boxes

Just been trying to get references for the UK post boxes, but came across about 4/5 post boxes that have had their information removed, includeing the next day of delivery metal plaque thing. What is the best way to deal with these PB? Seeing as they are physically there as post_boxes, but they are no-longer an amenity because post will not be collected from them! - Ciarán

Um, they've probably just had their collection plates pinched. I found one in Macclesfield like that around New Year. See [@N00/3153833476/ this photo]. I sent an e-mail to Royal Mail to say it was missing. A couple of weeks later, they come along and replaced it. I'd say still map it as an amenity=post_box. Richard B 22:09, 2nd February 2009 (UTC)
But if it has the hole (officially) blocked up it is disused or temporarily out of service. We could map these as often they can be seen from a far more easily than a nearby replacement. disued=amenity, amenity=postbo_box would be most appropriate. - LastGrape/Gregory 23:15, 17 April 2011 (BST)

Schedule for emptying

There would be nice with some kind of ability to tag the schedule by which the post box is emptied. A suggestion is post_box_emptying=*, eg. "post_box_emptying=monday-friday 18.00;saturday 16.00". -- Erik Lundin 15.44, 27th August 2008 (UTC)

Yes, I thought of if it could be replaced by "opening hours" but then a problem could arise, making people believe that they can only post at certain hours. What do you think? Logictheo 09:47, 15th September 2008 (UTC)
I've been thinking of "opening hours" too (which then could be applied on shops etc.), but for the reason you mention probably something like "emptied" is better. Do we need a stricter listing of the days/times? Maybe abbreviations like "mo-fr"? I could write a proposal and send a message to the mailing list. -- Erik Lundin 01:15, 30th September 2008 (UTC)
The opening_hours=* property seems to provide a useful framework for this. I think we can adapt the syntax used there and also use a more appropriate name, like 'collection' or 'last_collection'. So it's just a copy of the opening_hours syntax, except that the hyphen in the time part isn't allowed:
  • (general syntax) last_collection = wd hh:mm (see opening_hours=* for abbreviations)
  • (e.g.) last_collection = Mo-Fr 19:15; Sa 12:30
Mtcv 19:16, 3rd November 2008 (UTC)
Till now I used opening_hours=* but emptying_time=* sounds better for me with the syntax for opening_hours mentioned above. --Uboot 13:15, 28th November 2008 (UTC)


Okay, how can we make it official? I believe that emptying_time=* is the best name for the tag, and I am in line with the approach to use the opening_hours syntax because it covers all we need for the emptying time. It doesn´t seem to have been discussed Proposed_features list yet. But In my opinion it would be the correct way to get it harmonised.

I have just downloaded all German* post boxes and checked it for the used tags. Here are the interesting results - it really seems that we need to do something here ;)

Count Tag Name Count Tag Name Count Tag Name
505 operator 64 opening_hours 30 source
29 name 23 is_in 19 emptying_time
18 postal_code 16 note 15 addr:postcode
12 addr:street 10 addr:city 9 collect_monfri
9 collect_sat 6 addr:housenumber 4 collect_sun
4 ele 3 highway 3 layer
3 leerungszeiten 3 schedule 2 kismet:coordinates
2 shop 1 fixme 1 Info
1 landuse 1 Leerung 1 lines
1 place 1 railway 1 source_ref
1 stamps 1 wpt_description 1 wpt_symbol

*) Germany plus all which is also covered by the bounding box: [amenity=post_box][bbox=5.6,47.2,15.1,55.15]

--Krza 23:12, 5th December 2008 (UTC)


Proposal Established

I have created a proposal as suggested above:

--Krza 16:10, 11th December 2008 (UTC)

and changed it to

Several boxes at the same place

In some places several boxes are placed due to many letters posted there. They have in general (in Sweden) different references but are otherwise equal. I would say that the prefered way of tagging this would be with one node with

Is it ok if I add a photo of two such boxes and an explaining text? --Erik Lundin 19:31, 2nd February 2009 (UTC)

I don't know the meaning of the reference numbers in Sweden, but I believe that their meaning is not toooo important. For that reason I would do it as you propose. But in case there are really meaningful differences like collection times, destination restrictions or something, I would map multiple nodes.
Regarding the photos ... you had already uploaded one on the main page ;) But feel free to add another one ;)
--Krza 20:22, 2nd February 2009 (UTC)
Ok, I agree that post box reference numbers not is the most important thing in this world, but I got it on my mind an couldn't get it off. Will hopefully add a photo tomorrow (if I don't break my photo quota for this article :) --Erik Lundin 21:07, 2nd February 2009 (UTC)
Why not just use two nodes? I tend to do this with post boxes and phone boxes in the UK. It reflects reality 'on the ground' and it's simple enough. --LeedsTracker 01:38, 4th February 2009 (UTC)
Striving to reflect reality is a very good objective. However, in this case I think an abstraction of the post box term is better for the following reasons:
  • Most users probably don't care how many boxes there are at the place. They just want to find the nearest place where they can post their letters.
    • Searching for the nearest post box would return all boxes in the area, even if they stand next to each other. This would clutter the search results.
    • On a map, you just want one post box symbol where there are post boxes next to each other. Not two symbols 0.5 meters apart.
--Erik Lundin 11:59, 4th February 2009 (UTC)
  • On your first point, I don't feel having 2 nodes gets in the way of the user posting a letter.
  • Cluttered results can be annoying but in this case there's not that much clutter. In UK cities we often have boxes for franked mail next to normal letter boxes. The user might find that useful, and having them in separate nodes might simplify sorting/filtering results.
    • An example near me (on King Street):
  • How a map renders two nearby symbols is a renderer issue, not a map data issue. Note from my above example that (in mapnik) only one icon renders at z=17, but two at z=18.
  • Arguments for and against on good practice page, I think more against (but then I would!). --LeedsTracker 14:52, 4th February 2009 (UTC)
Ok, I admit that the map argument was invalid. Tagging with two nodes isn't that bad, but I think we at least should have the possibility to tag two boxes standing tight together with one node. --Erik Lundin 22:53, 5th February 2009 (UTC)
(This is a reply to the whole thread): I have a post box node where there are 2 blue boxes and 2 yellow boxes. They are all in close together with equal distances between each other regardless of color. To be precise in what exists on the ground I would give it 4 nodes with different coordinates for each post box. Maybe I'll take a photo of it so we can see it here. logictheo (talk) 07:49, 4 January 2014 (UTC). Just remembered to mention that this is a row of post boxes in Sweden. The blue ones are only for local post and the yellow are for any post.(which I guess can go abroad too)logictheo (talk) 07:52, 4 January 2014 (UTC)

Neighbour box hints

I started collecting emptying times some time ago. Now I searched and found the freshly approved Proposed_features/collection_times and I'll definitely use that schema too. Good idea. However I found something else about post boxes here in the area that's not covered by current tagging features AFAIK: hints about neighbor boxes:

There is actually a reserved space at any (German) post box plate to mention some number of nearby post boxes, ofter with later or even latest overall collection times in town. You can already see the reserved area in the [ German post box plate photo] at the post_box Wiki page (FIXME: catch/find another photo with sample text). To enter neighbor information into OSM I could imagine to create either an

additional key

neighbor=(OSM-ref of nearby object)
neighbor:late_service=(OSM-ref of object with later collection_times)
neighbor:night_service=(OSM-ref of object with latest/nightly collection_times)

use semicolon for multiple OSM-ref values

PRO
  • avoid using relations (good for newbies, easy to implement in editor templates for post_box nodes, apart from that maybe not a valid point at all)
  • reusable for other neighbor relations (but the word already suggests - well, to go a different way)
CON
  • prolongs the list of keys/tags at the nodes
  • finding and copying over OSM-No for the neighbor(s) is not a nice task without special editor support (unlikely to get this in short-term)

or a

new typ of relation

type=neighbours
role=next member=(OSM-ref of nearby objects)
role=next member=(OSM-ref)
role=late_service member=(OSM-ref of object with later collection_times)
role=night_service member=(OSM-ref of object with latest/nightly collection_times)
PRO
  • logically cleaner (to me)
  • finding and adding new neighbor(s) from OSM is easy (if you're already used to work with relations in general)
  • unlimited number of neighbors with same role
CON
  • many OSM mapppers are not familiar with or distracted from using relations at all (even if it is only because of the widespread human-unfriendly examples in OSM-XML style)

or even to

do nothing

Yes, seriously, the whole thing might be obsolete at all, if applications based on OSM could extract and evaluate distances between and collection_times of all post boxes in a certain area place.

By now my survey and experience is based and should be considered valid only for (easter part of) Germany. I invite you to discuss it here for there rest of the world ;-) Why? Well, I'd like to see, if there is the need and something good enough for a proposal.

--Hasienda 22:31, 3rd March 2009 (UTC)

Franked Mail Only

Some postboxes on industrial estates in the UK are marked to indicate that they only accept pre-franked mail. I currently add this detail in the note tag, but perhaps there should be a yes/no attribute to set? --Pinkduck 13:31, 9 March 2009 (UTC)

Agreed, they are often found in business areas of city centres too. I've seen some double boxes which have one slot for stamped, one for franked mail, both with the same reference number. Maybe we need mailtypes=franked;stamped which defaults to stamped only, if the tag is omitted --LeedsTracker 00:40, 10 March 2009 (UTC)

In the London area it is not unusual to see an elliptical post box with two slots (presumably once used for 1st & 2nd class mail) and a funny square shaped box next to it for franked mail. At the moment I just put this info in a note. SK53 16:58, 21 April 2009 (UTC)

Dracos Post Box list legal status

The list mentioned on the main page for UK Post Boxes is sourced from the Royal Mail via a Freedom of Information request. There was some controversy about whether the information provided could be used to locate postboxes which are then entered into OSM. (The list itself is not entered into OSM since it does not provide enough information to locate postboxes without some extra work.) This was discussed on the legal-talk mailing list[1][2] and the view is it's okay to use the Dracos data, which has been entered by people finding the postboxes on the map, in OSM.

I would say that it's ok to use the location data that says "there is a post box at (lat,lon)", but surely the reference values and collection times are covered by crown database right, and as such can't be imported directly into OSM. -- Rjw62 18:03, 18 December 2009 (UTC)

One reason for not entering ref=* data from dracos.co.uk - I have discovered that the post box references in RH10 and RH11 are incorrect in the data Dracos has. This is leading to post boxes being incorrectly matched up on his site. I don't know if this is a problem elsewhere.

There are certainly a lot of issues with the the Royal Mail data and the locations on the dracos site. The RM list probably has both missing boxes, and boxes included twice with different reference numbers (I'm guessing largely as a result of post-code district re-assignments). The Dracos locations can also be inaccurate, with people not always trying to get to the 2-5m accuracy OSM would like, matching reference numbers to the wrong box, or just placing boxes in the middle of random fields. -- Rjw62 18:03, 18 December 2009 (UTC)

Post Box Types

In the UK, there are various types of post box. From memory, these include:

  • Pillar Box
  • Lamp Box
  • Wall Box

There might be some other types. It might be good to agree a tagging scheme for this. I would suggest type=*. I can think of a couple of situations where this info could be useful - mainly navigation and finding the post box - the conspicuity of post boxes varies according to type.

If people wanted to get even geekier, they could start tagging which monarch's initials are on the post box. Daveemtb 07:54, 12 May 2009 (UTC) (I know a family friend who collects photos of post boxes!!)

It seems that post_box:type=* rather than type=* is now commonly used for tagging the type of postbox (usually with a value of pillar, lamp or wall), probably because the use of type=* for things other than relation types is generally discouraged. Perhaps this should be mentioned on the wiki page. sinh 16:35, 18 November 2012 (UTC)
box_type=* is almost as common as post_box:type=* (1820 vs 1964). We could do with some discussion and then agree to standardize on one or the other. Personally, I think I'd prefer the shorter box_type=*, as there seem little need for a post_box name-space. Rjw62 22:21, 18 November 2012 (UTC)
We also need to agree on the values, as box_type=* is mostly used with values of pillar_box, lamp_box and wall_box, rather than the values of pillar, lamp and wall that are used with post_box:type=*. The shorter values seem preferable to me, since "box" is redundant with either key. --sinh 13:14, 19 November 2012 (UTC)

Then are also now the permanent post-(sorry)Olympic gold postboxes, who won them will be listed on a plaque...

Post boxes not for public use

My municipality (Sykies, in Thessaloniki) decided for a short while to let people view their Geographical Information System from the internet, and I saw many post boxes, which I also visited, but most of them were not designed to be used by the public. I think that for showing it , it could mean it is useful for them to know where they are, or it could be useful for the Hellenic post. An example tag like postingpossible=yes/no could be used for that, or something shorter and more simple. Logictheo 08:17, 29 June 2009 (UTC)

It think you should use access=public or access=private instead.--Vsandre 07:05, 7 July 2009 (UTC)
Yes, true. Nowadays I do that generally for all things that are either for the public or used by some private group or company :) . Thanks logictheo (talk) 07:57, 4 January 2014 (UTC)

Proposal for tagging extra details for postboxes

I have created a proposal for tagging extra details of postboxes, some of which is based on things discussed/suggested here: Proposed features/Extend post box

It includes tags for the type of postbox, number of apertures, royal cypher, type of mail accepted, opening hours, and indoor.

All of these are optional, additional tags. Some of them (eg royal cypher) may be UK specific, and not apply elsewhere in the world. Suggestions / comments welcome. --Vclaw 18:02, 5 August 2010 (BST)

Posta CZ

Ein Bild von der Tschechischen Postbox: File:Ceska Posta - Briefkasten in Cinovec.jpg - wer kann es einbinden?--Geri-oc (talk) 18:07, 9 November 2013 (UTC)

[DK] Post box for picking up/sending packages

April the 2nd, 2008 Post Denmark started a service called "Pakkeboksen" (Formerly known as Døgnposten) which in short is post boxes where you can send or receive packages (and only packages), usually available 24/7, except some, which are located inside "Coop Danmark" supermarkets. I haven't been able to find a standard tag for these. Any suggestions? In https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extend_post_box I found mail_type=*. How about mail_type=package?

See Packstation for a similar sort of thing in Germany. That page suggests tagging them as amenity=vending_machine. --Vclaw (talk) 17:23, 5 March 2014 (UTC)

[DK] pickup-only postboxes

Israel has boxes for pickup-only. How would I mark those?

-- SwiftFast (talk) 21:41, 9 April 2017 (UTC)

Do we really need brand in this context?

Do we really need brand in this context? Or it is sufficient to specify the operator? According to my research, the tag brand is used in Germany only. And if the tag brand is used the tag operator with the same text is used at the same time. It does not seem reasonable to store the term twice. In the first step, I would change the Wiki rule, then we can still later clean up the database.--geozeisig (talk) 10:35, 7 June 2017 (UTC)

I am in favor of not using brand. Registering the maker of the box is not relevant. Would be as irrelevant as registering the maker of traffic lights, lamp posts, etc.--Pander (talk) 11:08, 7 June 2017 (UTC)
The maker of boxes in the United Kingdom and commonwealth countries is an area of serious study. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:37, 24 July 2017 (UTC)
Brand and operator may be, but are not always, the same. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:37, 24 July 2017 (UTC)
Historic note: there's manufacturer=* and model=* for the physical feature itself. brand=* would be for its facility function. ---- Kovposch (talk) 15:10, 8 January 2021 (UTC)

[GB] Priority Postbox

In The UK, with the pandemic going on, we have Priority Postboxes. There's an article here about what they are: https://www.scotsman.com/health/royal-mail-priority-postbox-what-are-they-and-where-nearest-one-sending-my-covid-test-sample-3019259

I suggest using `priority:covid_19=*` to mark postboxes as priority. --JayTurnr (talk) 19:19, 7 January 2021 (UTC)

Is there even a priority=* in use for amenity=post_box? For this tag solely, breaking up post_box:type=* to better tags including purpose (eg *:function=* or *:for=* would be useful anyway. Also, some box accept letters and parcels separately. Some tag could be used for what it accepts, and how fast it's delivered. As a whole, with vaccination being put forth in Proposed_features/vaccination ("approed") and Proposed_features/Tag:healthcare=vaccination_centre (in voting), you can possibly do the same for testing, sampling kit distribution, and sample return. ---- Kovposch (talk) 15:04, 8 January 2021 (UTC)

Displaying of disused post boxes

I hope it's good policy to open a new topic rather than continuing the one that is 10 years old. I'm working on a tutorial about post boxes in Ireland (but most of it would apply to the UK as well) and I mapped a disused one with amenity:disused=post_box, yet it is rendered on the map. Would it not make more sense not to render it, since it is misleading to display them with the same icon as the in-use ones? B-unicycling (talk) 20:41, 15 February 2021 (UTC)

I don't know wich renderer you are referring to (probably osm-carto) but disused is commonly used as a prefix, like disused:amenity=post_box as described on the Key description page disused:=*. Changing the order accordingly might probably help with your issue.--Kjon (talk) 22:02, 15 February 2021 (UTC)
A variant of disused postboxes, how should post boxes within museums be marked that are not in use ? I am thinking of the 4 or 5 in the museum at Amberley [GB Sussex] that includes a rare telephone box with a built in post box & stamp machine. That in itself is difficult to tag being 3 items in one. Assuming these should be included in OSM should the operator be the museum ?

Address

Each US mailbox has a sticker with its address on it. If the user copies this address into the tags, when rendering, please don't assume it is the location of this address point. As it is often the address of the nearest building. Jidanni (talk) 17:31, 22 November 2022 (UTC)

For reference, here's an example of an address sticker at or near 1910 County Road B West in Roseville, California:

Standard collection box sticker

 – Minh Nguyễn 💬 00:15, 23 November 2022 (UTC)