Post_partner confusion

General talk Tagging general discussion
21

Data renderer should not be forced to do extra filtering to drop intentionally badly tagged objects

1 Like
22

How exactly is it false data?

Not at all. I meant data consumers are free to ignore the additional tag, which they do by default.

23

I agree with @marc_marc. The proposal merely says that in Germany, the distinction between the shop and the post office service is not clear enough to permit two distinct nodes, one for amenity=post_office and one for (for example) shop=supermarket. This means that in other places the branding and the presence of the post_office service may be clear enough for amenity=post_office + post_office=post_partner to be ok on a separate node.

I think we should update the wiki to make clear that post_office=post_partner may also be used on separate nodes.

24

No, it doesn’t. The proposal was created first of a german view by a German.
But in the discussions the situation was cleared, that not this situation is not only in Germany. I was last winter in Norway, some Supermarkets worked well as “Post Partner”. There was the Cashier also the person, that sold me the stamps.

This Tagging was approved in front of one feature, one Tag; And then it is also necessary for you in Norway to take such proposals seriously and tag them accordingly. It is technically possible, as has already been pointed out here.
You actually risk multiple entries with your import because you do not adhere to the proposed tagging.

25

This Tagging was approved in front of one feature, one Tag;

what defines the feature for us? Is it the same salesroom with the same operation hours and the same people selling the item/service? Or must it be the same operating business?

26

related discussion in post_office=post_partner should NOT be used with amenity=post_office · Issue #784 · Helium314/SCEE · GitHub

27

How I see the situation:

  • in the beginning, there was amenity=post_office. It was used for all things that people connect with “post office”, like e.g. sending packages or letters etc. and all was well
  • then people noticed that there are different types, and that some offer extra functionalities or have special considerations, so post_office=* was invented to record those differences.
  • then people wanted to indicate that some shop or amenity or office also offers (some) postal services, so they used post_office=post_partner to be used as a property tag on those shop=* etc (but not on amenity=post_office). (just like using shop=yes or toilets=yes on amenity=fuel for example).
    That adds valuable information, but if the shop/amenity/office is mapped as a polygon instead of a node (especially if it is a big polygon like shop=supermarket or shop=mall), then it leaves much to be desired regarding the exact position of that post-office-partner-thingy.
  • then some people wanted to indicate exact position of that post-office-thingy in those big shop polygons. Just like adding toilets=yes to shop=mall polygon leaves a lot to be desired (so people tend to also add amenity=toilets node at exact position of the toilets too), so does just adding post_office=post_partner to that shop=mall polygon is insufficient, and people will add amenity=post_office node at the exact position inside a shop.
  • now it begs the question, how should that precise amenity=post_office be additionally tagged to indicate that it is not a full post office, but post partner thingy only?

Some possibilities to handle that last point:

  1. you’re not allowed to add details to that amenity=post_office, so let people guess which one it is forever!
  2. just add post_office=post_partner to amenity=post_office even if wiki is saying it should not be done. (which seems to have happened in practice)
  3. invent a new value that is allowed to be added on amenity=post_office, like post_office=post_partner2 (hello service=driveway2 :grin: ).
    Name of course could be different, but it would have the same meaning about that post-office-thingy just like post_office=post_partner has. Only difference would be that it would be tagged exclusively on amenity=post_office but never on shop=*.
  4. add a description=This is exact location of post_office=post_partner (but we're not allowed to tag it with post_office=post_partner) instead
  5. invent or find some other key to record that information
  6. something else?

My preference would be (2) and to update the wiki indicating it (because it is the talking about the exactly same thing, only the place where it is tagged is different). Data consumers who care about distinguishing post-partner-thingies may then easily decide to include or exclude those depending whether they’re mapped on amenity=post_office or on some shop=*.
Additional benefit of that choice is that it is 42% of current usages


If (2) is however not acceptable to people, then (3) or (5) would be my choice.
Any ideas?