Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Render operator on amenity=post_box and amenity=post_office #1023

Closed
1ec5 opened this issue Oct 7, 2014 · 18 comments
Closed

Render operator on amenity=post_box and amenity=post_office #1023

1ec5 opened this issue Oct 7, 2014 · 18 comments

Comments

@1ec5
Copy link

1ec5 commented Oct 7, 2014

According to the wiki, amenity=post_office and amenity=post_box can be used for facilities operated by either (quasi-)government agencies or commercial parcel services (UPS, FedEx, DHL, etc.). But if you come across a brown ✉︎⃝ icon on the map, you’re going to assume initially that it’s a traditional post office rather than something like a UPS Store. To reduce confusion, the renderer should place a small label underneath the icon indicating the operator. (But only if there isn’t already a name on the feature, since the name would probably indicate the type of facility.)

According to taginfo, operator is used on 27,965 post offices and 75,760 postboxes. (brand is used on 6,309 postboxes.)

(This issue was inspired by this talk-us thread.)

@dieterdreist
Copy link

2014-10-07 9:02 GMT+02:00 Minh Nguyễn notifications@github.com:

To reduce confusion, the renderer should place a small label underneath
the icon indicating the operator.

I think this would indeed be a valueable amendment, but it should not
happen on anything below z18 or z19. This could also be done for
amenity=police and a bunch of other POIs. Maybe we should also take "brand"
into account.

@matkoniecz
Copy link
Contributor

for displaying brand see #698

@mboeringa
Copy link

But if you come across a brown ✉︎⃝ icon on the map, you’re going to assume initially that it’s a traditional post office rather than something like a UPS Store.

While I can see the sense of the basic idea you are proposing, I don't think this is a really big issue in reality. Many of the non-traditional parcel service providers, are not located within city centres where traditional post offices are often found. The commercial parcel service providers more often than not, have their base within some industrial zone, where you don't go for posting your typical vacation card...

@pnorman
Copy link
Collaborator

pnorman commented Oct 7, 2014

Many of the non-traditional parcel service providers, are not located within city centres where traditional post offices are often found. The commercial parcel service providers more often than not, have their base within some industrial zone, where you don't go for posting your typical vacation card...

This is probably region specific - there are plenty of FedEx and UPS drop boxes in areas with post boxes, and there are similar overlaps for the offices.

e.g.
image
Image from FedEx site

This being said, I see one FedEx and one UPS drop box mapped in the Pacific Northwest, so these things are hugely undermapped or not tagged with operator.

@mboeringa
Copy link

This is probably region specific - there are plenty of FedEx and UPS drop boxes in areas with post boxes, and there are similar overlaps for the offices.

You may be right. Here in the Netherlands, these parcel service providers almost exclusively operate on the basis of pick-up of parcels at the sending address. Therefore, there is not much use of having a "post office" type facility in a city centre, which just incurs high costs. I can see the sense of such a facility though, in dense urban financial or commercial districts, like the Manhattan you are showing.

@pnorman
Copy link
Collaborator

pnorman commented Oct 7, 2014

Just for the record, operator on amenity=post_box

┌───────────────────────────────┬───────┐
│          operator             │ count │
├───────────────────────────────┼───────┤
│ ¤                             │ 90691 │
│ Deutsche Post AG              │ 18320 │
│ Deutsche Post                 │ 14522 │
│ Royal Mail                    │ 13683 │
│ La Poste                      │  7509 │
│ Canada Post                   │  2136 │
│ bpost                         │  1796 │
│ Почта России                  │  1156 │
│ USPS                          │  1131 │
│ Correos                       │  1042 │
│ PostNL                        │   989 │
│ Posten                        │   840 │
│ United States Postal Service  │   805 │
│ Post                          │   797 │
│ Česká pošta, s. p.            │   752 │
│ Australia Post                │   659 │
│ Poczta Polska                 │   575 │
│ Poste Italiane                │   535 │
│ An Post                       │   434 │
│ Die Post                      │   420 │
│ MEDIA Logistik                │   318 │
│ Die Schweizerische Post       │   315 │
│ Itella                        │   223 │
│ TNT                           │   209 │
│ Íslandspóstur                 │   209 │
│ 日本郵便                      │   183 │
│ P&T                           │   176 │
│ Jersey Post                   │   165 │
│ 中華郵政                      │   164 │
│ DHL                           │   163 │
│ TNT Post                      │   149 │
│ US Postal Service             │   138 │
│ Post AG                       │   137 │

@daganzdaanda
Copy link

Hm, "United States Postal Service" is a bit long for a little box.
Could we use an automatic abbreviation, replacing "United States Postal Service" and "US Postal Service" with "USPS"? But that might be very confusing for new mappers. There is a tag "short_name", but that doesn't fit perfectly for operator.

@pnorman
Copy link
Collaborator

pnorman commented Oct 7, 2014

Could we use an automatic abbreviation

No. USPS is the most common anyways.

@mboeringa
Copy link

Just for the record, operator on amenity=post_box

What about amenity=post_office, because I think this issue is more about a confused tourist with his holiday card ending up at a parcel processing station, instead of a traditional post office, than necessarily about a different type of post_box and its rendering, considering the OP's first post here.

@matthijsmelissen
Copy link
Collaborator

Post box: there are hardly any postboxes in the database by an operator other than the national carrier. Rendering a few operators that are not the national carrier is not worth having to render the national carrier name under almost all mailboxes.

Post office: duplicate with #840.

@1ec5
Copy link
Author

1ec5 commented Mar 22, 2015

@math1985 How should collection boxes for UPS, FedEx, DHL, and the like be tagged? They probably have more collection boxes than the national carrier in my city and probably many others.

@matthijsmelissen
Copy link
Collaborator

@1ec5 I'm not sure. I suppose this is in the US? Perhaps ask on the US mailing list what the tagging standard is?

@1ec5
Copy link
Author

1ec5 commented Mar 22, 2015

This issue grew out of a talk-us thread, actually:

https://lists.openstreetmap.org/pipermail/talk-us/2014-October/013661.html

@matthijsmelissen
Copy link
Collaborator

I see, I missed that in your first post.

I can re-open this issue, but I'm still not sure of what the best solution would be.

@1ec5
Copy link
Author

1ec5 commented Mar 22, 2015

Compounding the problem, many private carriers put their boxes right next to their competitors’ (maybe due to city ordinance; I’m not sure). It might be difficult to cram three carriers’ labels right next to each other.

@mboeringa
Copy link

The best solution to me, especially taking into account this last raised issue, is not rendering this on the standard style, but on a dedicated site with togglable overlays depicting per layer each carrier's boxes. E.g.: This site by Marc Zoutendijk is an excellent example, that can display multiple backgrounds for the overlays, including OSM Standard:

Taglocator
http://mijndev.openstreetmap.nl/~marczoutendijk/openpoimap/taglocator.html

@Tomasz-W
Copy link

Tomasz-W commented Jul 15, 2018

Is anybody still interested in this? I think it would clutter the map with needless information.
@kocio-pl What about closing this ticket?

@matkoniecz
Copy link
Contributor

I see no good reason to render this particular part of OSM data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants