Reading the wiki, it seems pretty clear that post_office=post_partner is an attribute to go on the shop which is operating as a post partner. Not an actual amenity=post_office.
However there seems to be a surprising amountamenity=post_office + post_office=post_partner. They seem to largely come from a hand full of changesets, 1, 2 and be bulk remappings from post_office:type=post_partner. However the 2 tags don’t mean the same thing…
Should these be turned back to post_office:type=post_partner? It is deprecated, but now basically half of post_office=post_partner is misstagged. Or should the wiki be updated to say post_office=post_partner could mean 2 things? An attribute of a shop that offers postal services or a type of post office.
From my point of view, they don’t fit together very well.
Here, the change from post_office:type=post_partner to post_office=post_partner should have been made in a single view:
the amenity=post_office should also have been removed and the correct amenity=* / shop=* etc. entered accordingly or
the amenity=post_office data would have had to be added to the existing amenity=* / shop=*.
The combination of amenity=post_office and post_office:type=post_partner is not intended, as mentioned in the wiki.
See also under:
post_office=post_partner; A relay point in shops or amenities for a limited number of postal services like letters, parcels, packets provided as a complementary business.This is used with some other primary amenity=, office= or shop=* instead of amenity=post_office
I see from the history that the source for many of these was the postal service’s database of post offices. The postal service lists some of them as being full-service post office and some as being limited-service post office in store.
The postal service database contains coordinates, and I suspect that trying to match these coordinates to a nearby amenity=shop would be futile in many cases.
Instead, the post offices were imported with their coordinates verbatim, and to distinguish the full-service ones from the limited-service ones, this mash-up of tags was used.
“Posten” in this case has shop-in-shop branches with separate counters, separate branding/colours and separate official branch names which are different from the supermarket hosts. The local post branches are operated by the staff from the supermarkets.
The amenity=post_office wiki describes a amenity=post_office + post_office=* tagging scheme, and my preference is to continue to tag them this way. This is not a problem, I think, it just makes the post_office tag more flexible.
then the English page of the wiki needs to be improved because during the proposal on this tag, it was clear that there were 2 different schemes :
one with an object representing the postal department as a separate entity (as in France) from a possible shop
the other with a shop+postal service object (like in, by memory, in Germany)
the french version describe it verw well.
Besides, I don’t see the problem with “misstag” of post_office=post_partner, which describes a postal department by a poi whose main activity is not this. because defining the main tag is a problem that has nothing to do with post_office=post_partner <> post_office:type=post_partner
From memory, the first version was even rejected when it tried to change the problem with the main tag
there is therefore no reason in France to cancel the mass edition that was approved 2 years ago, but rather an improvement to the wiki in English is maybe needed.
if someone wants to reopen a proposal about the main tag of a postal department in an POI where this is not the main activity, I’m not against it but it’s not related to post_office with or without :type sufix
The GB would fit the pattern of official data not containing which stop the fake post offices are located in, nor does the official GB data tell us if it’s a real stand alone post office inside a shop vs the shop offering some post office functions.
However GB didn’t use post_office=post_partner on these. They are left blank, arguably they should be merged into the post_office=post_partner spec, however the lack of data and whos gonna give the time means that probably wont happen any time soon. Also they can arguably be left as amenity=post_office this is the standard here and we aren’t damaging post_office=post_partner.
It seems clear that there is a need for a post_office=post_partner to sometimes be mapped using a separate node. In these cases, isn’t amenity=post_office + post_office=post_partner the logical combination?
Creating a separate node tagged only as amenity=post_office means we discard information we have. It would look like a full-service post office, which it isn’t. Arguably this is better than nothing, but why not be able to capture all the information that we have?
Data consumers who disregard post_office=post_partner on a amentity=post_office will be no worse off – it would look like a full-service post office to them.
" These postal partners often do not offer the full range of services. Because this POIs can not be marked as amenity=post_office there is an approved tagging scheme."
I don’t know the origin of the data, but usually there must be some kind of ID. And this could also be linked to shops= etc.
It’s just a bit more work, but the data is better
Isn’t the whole point that it doesn’t describe them as full-service post offices, though? I think if they were merely tagged amenity=post_office, no one would have objected in the first place.
Both of them seem worse to me. Not importing anything means no one knows what is there. Leaving free-floating post partner nodes means no existing data consumers who follow a particular interpretation of the schema will see them. The graceful degradation allowed by this particular tagging seems better.
