Convert improper element types to Nodes

[secondl1ght]

Some of the elements in the current dataset are either ways or relations when they all should be the type node. More information on element types can be found here: https://wiki.openstreetmap.org/wiki/Elements

We need to update these locations to use the correct node type.

[bubelov]

https://maps.mail.ru/osm/tools/overpass/?Q=(%0Away%5B'currency%3AXBT'%3Dyes%5D%3B%0Away%5B'payment%3Abitcoin'%3Dyes%5D%3B%0A)%3B%0Aout%20geom%3B&C=-3.16246;173.14453;2&R

[mnalis]

As brought up in the Discourse OSM forum, I'm wondering why you seem to think that only node elements are correct? Closed way elements (AKA polygons) are massively used in OSM for mapping especially bigger features.

[bubelov]

@mnalis

why you seem to think that only node elements are correct?

Our scope is elements with Bitcoin tags, no one is suggesting getting rid of other element types, globally.

The current guidelines are based on OSM Wiki pages, namely: https://wiki.openstreetmap.org/wiki/Cryptocurrency

Those pages were created long time ago by the people who aren't related to this project. If you see an issue with that, maybe we should start with updating the Wiki pages. We didn't question this particular advice for the following reasons:

1. Buildings do not accept bitcoins, businesses do.
2. Building can host many businesses.
3. Buildings are more durable and they have a geometry worth keeping, so ways are ideal structures for them.
4. There is a button called Extract node in the OSM editor which hints at the widespread push to separate building tags and geometry from the rest of the things.

To summarize, we're basically just following the official instructions, namely:

Tag points, not ways

In openstreetmap you have a lot of flexibility, a building can be tagged with an address and a shop and a building all at once. But in most parts of the world this is now frowned upon and we have moved to separate those. A building is tagged as a such, and a separate point is added for the store or restaurant that is there.

What this means in practice is that we advice using the currency=* on a point, combined with the merchant information which accepts it. Various online resources will simply skip ways / buildings and as such your tagging efforts will only be seen when you tag the point.

If those quotes seem controversial, I suggest we edit the OSM Wiki.

[mnalis]

• When adding new shops, I agree you should add as shop=* nodes, with appropriate payment=* / currency=* and other tags (name=* etc), as that would be both the simplest and least controversial.

• However, when editing existing shops, I would suggest not touching the geometry (i.e. convert closed ways to nodes or vice versa, etc.) but just updating the tags. That means, you would only add/update payment=* / currency=* tags as needed, and not touch anything else. (assuming your core interest is adding crypto payment information, and not OSM editing in general). This way, you neatly avoid majority of the problems that you can be blamed for (ie. even is the polygon is wrong size, or should better be a node etc., it is not you who made it that way; you just improved payment information on it. There is no requirement that mapper who edits an object must improve all things on it!)

---

Detailed explanation:

Moving polygons to nodes (or nodes to polygons) or duplicating the information (having both polygons and nodes for same thing) is more complex and is thus much more likely to create problems.

Regarding your list of reasons Buildings do not accept bitcoins, businesses do. that is completely correct. That's why you would tag payment=*/currency=* on shop=* nodes/ways instead (which may, or may not, happen to also be marked with building=* and/or other tags)

https://wiki.openstreetmap.org/wiki/Cryptocurrency is likely referring to principle called One Feature, One Element, which is widely (but not universally) accepted as generally good idea.

However closed way (also known as polygon) is not the same thing as building:

• Building is some element (which can be a node or a polygon) which is tagged with building=* tag to indicate it represents a Building.

• You can also have an node or a polygon which is tagged with shop=* tag to indicate that it represents a Shop.

• Now, sometimes (quite often actually, but far from "always") it can happen that mappers take a shorthand and tag a same way (or a node) as both a building=* and a shop=* to indicate that the shop occupies the whole building. That is easier, but breaks above mentioned "One Feature, One Element" principle, which can in same relatively rare cases lead to confusion (e.g. if you have closed way tagged with building=yes+shop=convenience it indeed can be a problem if one added start_date=* it -- because there would be no way to tell if that indicates start date of the building or the start date of the shop)

• https://wiki.openstreetmap.org/wiki/Cryptocurrency also says:

  Various online resources will simply skip ways / buildings and as such your tagging efforts will only be seen when you tag the point.

to which I would reply "citation needed" ? About a quarter of all shops are marked as ways, and I find it unlikely that people would keep using such "various online resources" which would routinely miss a quarter of the mapped shops. Sure, some broken websites probably exist, but if they are unable to handle such common mapping practices as "shops on closed ways", they are much less likely to support (quite esoteric in comparison!) tags like payment or currency either.

[bubelov]

@mnalis

assuming your core interest is adding crypto payment information, and not OSM editing in general

That's one of the reasons we we choose OSM, the goal is to keep that data set clean and up-to-date, not just put a Bitcoin sticker on a bunch of places and call it a day. Some people did it in 2014 and we're still dealing with the negative consequences. Bitcoin tags are useless if the rest of the tags is in the poor condition. I wouldn't personally bother visiting a place which doesn't have a phone or website or at least some social network links. Things like survey:date are also extremely important.

Regarding ways. I really appreciate your explanation, but it's hard to wrap my head around it from the first read, but I'll dig deeper into that. Although theory is essential, would you be interested in discussing a few actual elements from that ways data set, just to clarify what's the best course of action? There are probably only a handful of common patterns, so we can document our previous resolutions and stop bothering OSM editors about that.

Here is a classic example:

https://www.openstreetmap.org/way/185946268

Here is how I would approach that element:

1. It's a building, red flag.
2. There are plenty of commercial tags, which is not cool.
3. Hit the "edit" button.
4. Thanks to OSM, we have an "extract node" button, hit it.
5. Now we have a way with the following tags:

addr:city=London
addr:housename=St.Lukes Community Hall
addr:housenumber=194
addr:postcode=SW12 8RQ
addr:street=Ramsden Road
building=yes
building:levels=1

6. We now also have a new node with the following tags:

addr:city=London
addr:housename=St.Lukes Community Hall
addr:housenumber=194
addr:postcode=SW12 8RQ
addr:street=Ramsden Road
leisure=sports_centre
name=Semokwan Hapkido Academy
payment:bitcoin=yes
phone=+44 7932 667 336
sport=hapkido
website=http://semokwan-hapkido.co.uk/

7. Looks good, but better to check the website and (blasphemous move) Google Maps and any other third party sources. Please note that it doesn't mean that we're importing any data from those sources, it's just a sanity check (if different sources do disagree on something, than it should be investigated). Updating tag based on the official website, if present, is probably fine, at least it's my current understanding of the licensing situation.
8. Although some OSM mappers aren't happy with deleting the old tags, I believe that the majority of people are OK with deleting payment:bitcoin tag (although some suggested disused: prefix). So, deleting payment:bitcoin and adding currency:XBT instead.
9. Since I'm not in London and I didn't find any Bitcoin related info on the website, I can't add survey:date tag, so my job here is done.
10. Hit "commit", write some comment like "Extract node, upgrade legacy tag and update contact info", hit "upload changes".

Do you see any problems with this approach or do you have any suggestions? This is the most common pattern, so it's directly related to this GH issue.

[ovruni]

A shop can be an area larger than a building, contain several buildings inside or may not even have a building tag. In case the shop does not exist you can add a node, but in case the shop exists previously and is defined by a polygon (way), which may represent the entire area of the shop, the new tags should be added in the polygon and not add a duplicate node with the polygon that already exists.

[bubelov]

@ovruni

A shop can be an area larger than a building, contain several buildings inside or may not even have a building tag. In case the shop does not exist you can add a node, but in case the shop exists previously and is defined by a polygon (way), which may represent the entire area of the shop, the new tags should be added in the polygon and not add a duplicate node with the polygon that already exists.

Can you take a look at the concrete example I listed above? I'm a bit confused since I received conflicting feedback. One one hand, it seems to break the "One Feature, One Element" principle. On the other hand, some mappers say that it's better not to touch those ways. To make things more confusing, there is a hint that new places should get a different treatment, but I'm not sure what's the reason for that.

[ovruni]

Building tag can go along with the tag of a single business (building=yes +amenity=restaurant), but if for example a restaurant and a convenience store inside the building then should not the polygon of the building take the tags "amenity=restaurant" and "shop=convenience" together, in that case can go like two different objects.

In the example you put above leisure=sports_center, a node with amenity=vending_machine can be added inside.

[bubelov]

@ovruni

In the example you put above leisure=sports_center, a node with amenity=vending_machine can be added inside.

Okay, now I'm completely lost. Are you suggesting splitting payment terminals into separate nodes? That would make it pretty hard to link it with the merchant itself (or should we link it into a relation?), and it would make the whole setup more complicated and brittle imo. I assume this method would only apply to buildings with business tags, we probably don't want to extract payment terminals from the node-based shops?

I live in Phuket and it's common for local corner shops to have 5+ different terminals, I wonder how that method would scale in places like this.

[ovruni]

No, what I meant is that having leisure=sports_center as a polygon allows you to detail other smaller objects that exist within this sports center (such as swimming pools, soccer fields, vending machines, etc). If the sports center were a node, it would not be possible to identify to which sports center the swimming pools, soccer fields, etc. belong.

[bubelov]

@ovruni

No, what I meant is that having leisure=sports_center as a polygon allows you to detail other smaller objects that exist within this sports center (such as swimming pools, soccer fields, vending machines, etc). If the sports center were a node, it would not be possible to identify to which sports center the swimming pools, soccer fields, etc. belong.

Makes sense. I guess it would be possible with a relation, but that would complicate things quite a bit. This model works reasonably well if the building itself is hard linked with the certain kind of business so it's not expected to be divided up and re-purposed for another kind of business activity, that would be problematic since all of the contained nodes will be treated as belonging to the new business while they may be no longer functional or no longer exist. Splitting things always includes the risk of unwanted partial modification, someone might forget to change all the "deps" or fail to figure out how to find them.

So, what's the recommended approach? Not touching the existing ways but tagging new merchants as nodes, I assume? If there are no other opinions among other OSM contributors raising this issue, I guess it can be closed. If that's not what you had in mind then we should probably have a broader discussion and update the upstream OSM Wiki page, because now it insists on not tagging ways or relations.

[ovruni]

As I initially said, if there is no shop already mapped as way, then a node can be created, but if there is already the shop as way then the additional tags would have to be added to this and not create an additional node within the existing way.

[bubelov]

Closing the issue.

Reason: we got contacted by a few well-known editors with high rep/number of edits, and their arguments for not doing that were sound. The OSM Wiki page is probably worth updating and including the clarification, but we were informed of ongoing edit wars in the Wiki (we're not involved, seems like an old guard is having some internal fights over something insignificant) so I guess it's better to wait on that and come back with our suggestions later.