How can we tag (in ) that the employees in a venue are in a labour/trade ?

What about `employee_union=yes/no`? What do you think?

Some countries have seen an increase in places like coffee shops being unionised, and some people want to filter based on this.

Obv. there are regional differences, about closed shops, or whether all employees are in a union, or places where `=no` isn't a bad thing (right?), or whatever. This can't cover everything.

obv. I'm thinking of things like consumer facing cafés here, rather than things like a car factory, or hospital, or things like that. My idea may, or may not, be relevant here. Please feel free to correct me.

@amapanda I'd pick some sort of standard phrasing so you could also have a worker cooperative flag, then be able to easily query for both at once

@neko do you have a good suggestion?

I think some people have tagged such co-ops in OSM before. I would see that as an orthogonal issue to an employee union tag. Here, I am just looking at unions. So I think it's ok to work on a tag for unionised workplaces first, and ignore "co-op owned" for this discussion (or am I mistaken? 🤔)

@amapanda @neko This is really something for wikidata as it is hard to verify and to maintain by contributors. Think of wikidata as entities with key/values too, with a few complications

@pietervdvn @neko OSM is key/value pairs (but ours are Human Readable) 😉

(plus I prefer the OSM licence 😉)

@amapanda @neko yeah, it is easier to grasp, but also easier to make a typo in OSM. For example, would 'SomeUnion' be equal to 'Some Union' or 'Some Union inc.'? Wikidata solves that problem.

And what with e.g. information about that union (image, website, store,...)

@pietervdvn wikidata doesn't solve some things since I've heard it has different definitions of the same thing in different languages

@amapanda That can happen, but then one can state that they are equal entities and redirect one onto the other

@pietervdvn i don't have the mental space for all this wikidata stuff. IMO adding `employee_union=yes` to OpenStreetMap is by far the simplist approach. If you have suggestions on _that OSM tag_, I'm listening. 🙂

@amapanda I understand the lack of mental space, it's a lot to get started with.

However, I'm opposed to a 'employee=union'-tag - that is IMHO out of scope for OSM. Should we also start to tag the baserate of emoloyees? The gender balance and other diversity indicators of a workspace? How rude their manager is?

Don't get me wrong - these are all worthwile social causes to fight for; but OSM isn't the vehicle to collect this data with.

@pietervdvn it's fine if you don't want to map this. But others might. Leave it at that.

@amapanda What is the on-the-ground verifiability of employee syndication data ? Are there examples of online sources compatible with ODBL ?


@amapanda What about small family businesses where being in a union doesn't make sense? I appreciate your good intentions, but make sure it doesn't inadvertently harm someone innocent.

@amapanda Can this be partly offloaded to #Wikidata? I'm thinking of cases where hundreds or thousands of locations would belong to the same entity and follow the same contract.

@nemobis I dont know anything about wikidata. Theoretically there's loads of overlap. I'm just focussing on OpenStreetMap now.

@amapanda This feels like something that would be better handled in a review guide. Especially since large facilities may only be partly union, and depending on season or event may not have union workers.

So, scope and maintainability may be difficult to nail down on this.

I don't see this working on a map and I don't really understand the use.

A bunch of people are in a union and you'll get some pretty much everywhere, however being in a union is a personal choice, thus often you'll get places with some employees in a union and some others who aren't.

Moreover I don't think you can get this kind of data easily, unless the employees themselves declare being in a union.

@rastinza OSM can also function as a database, rather than just a map. If it's “observable” that a venue is “unionized“ (FSVO unionized) (which might be the employees telling you) then it can be added. But also a news story that the venue is “unionized” is OK too

I don't know what you mean by unionized.
This tag anyway would be quite difficult to define properly: if one out of 50 employees is in a union is it =yes?
If one out of 50 is not in a union is it =no?
If half the employees belong to a union and the other half to another one what happens?

I do not like this cramming of any type of information in OSM, I feel that some can be useful while others simply increase the complexity.
In this case I feel that it would be better to perform an analysis and plot the results on the map and not include this data in the map itself.
OSM, as the name says, is a map. It uses a database to store all information related to the map, this doesn't mean that it should become a database of every bit of information that can be located on the map. At the very least there should be a clear and well defined use that people will do with that information.

Is this data really available and maintainable?
How much time will it take to collect a decent amount of data for it to actually be useful?
When this happens, how much of the data available will be out of date?
People change jobs, thus places that have employees in a union change over time.
Collecting this kind of data is also very tedious and complex, very prone to errors and extremely difficult to verify.

I guess the original idea is to study the spread of the unions (in the US?) over the territory. I feel this analysis would be better performed through a separate analysis and a well defined data source.
Moreover I think this idea is very US centric, I would never go around checking which stores have employees in a union, because I can safely assume most of them are in a union in my country.
Moreover, you would have to take into account the different declinations of unions over the world: the definition of a union can change quite a bit and that tag might be senseless in other places in the world.

@rastinza “OSM, as the name says, is a map” hehe, IME one of the main confusing points with OSM is that it is called a map, but is really a database. 😉

I don't think this adds extra complexity. There's already so many extra tags added to things all over the world. It's very easy to just ignore another tag like this. There are some complexities with OSM data, and “here's another tag” isn't one of them.

You did not address any of all the other points I made, you just replied to my personal opinion that adding this tag adds complexity.

@rastinza It's OK if you don't like this sort of data in OSM. Just ignore the tag, in the same way that any other data consumer must ignore tags it doesn't support. No-one's forcing you to map this thing. But you shouldn't delete the data that's there. OSM can, and has, operated successfully for 15+ years with people mapping & consuming different things.

Sure, but since you're trying to add a new tag to the map I feel it would be sensed to at least motivate why it should be added and if it really makes sense to be added.
I'm deleting nothing, I just deem this data questionable; I feel it should be written somewhere else and then correlated with OSM.
I feel there are some big maintenance problems with this tag, moreover it will probably apply only in the US.

@rastinza Plenty of things only apply in one region, that's not a reason that people in that region shouldn't add it.

I've seen people on social media asking for maps of this.

@rastinza Why do I want to add it? Because I want to help destroy capitalism. 🙂

So it's a union formed by the employees of that shop only?

Sign in to participate in the conversation
En OSM Town | Mapstodon for OpenStreetMap

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!