Hi,
I try to adjust amenities and shops in my hometown.
What is the best way to map them: a node in a building or use the building himself?
What is your way to map?
When are you using nodes and when the area?
Thank you for your answers.
Marc
Node - when it’s one of multiple uses of a building
Area - with building=* whenever it occupies the whole building
or just area - when it’s a facility like school, hospital, university (mainly amenity=*) - draw along the fence
Here you can see all the examples:
Area if you know the exact area covered, otherwise node.
if you map as a way, and the area is big it’s better to also tag a node which belongs to the way, with entrance=main (or entrance=yes)
Thank you for your help.
Personally I prefer on a node.
Reason: On the shape of building, is the place of what the properties of that building is: type, level, heritage, 3D, ect… things that almost never changes.
Shop on node there the info of that shop, when it closed, or changes easy to delete and be shore that everything is gone without destroying properties of the building it self.
Do not map it as a building unless it occupies all the building.
I think it is reasonable to map it as an area, if you really know the area that it occupies.
Does that advice include the case of a shop on the ground floor of a building with a flat above? The shop doesn’t occupy all of the building but it does occupy the entire area of the building on the ground floor.
Sorry, I’m being pedantic here. But depending upon your answer I might have to make a lot of changes…
For the shop on the ground floor, you can map it as an area, but that that area must not be the area that represent the building. Either map it as a building part, or only as an amenity, and include level=0.
Oh dear. You just complicated life a lot. Most shops around here occupy the entire ground floor of a building and have flats above. Shops in single-floor buildings are rare around here. Shops that occupy all floors of a multi-floor building are non-existent around here and not very common even in big cities (I can think of a few in Edinburgh, Nottingham and Sheffield but they’re not that common). Overlapping outlines are more fiddly to make alterations to in iD.
How serious are you on that? I don’t recall any such advice in the wiki (but it’s a big wiki and I could easily have missed it). If you’re talking perfectionist practise or very, very best practise, that’s one thing. If you’re saying that’s ordinary best practise then any shop I map in future may well be a node inside a building, since that is still considered acceptable and is far less of a pain in the bum.
Mapping the business against the building area is just wrong.
There is no need to map it as an area, but if you do, it should not be the same way as the building, unless it is the whole building.
This is commonly done wrong, because people seem to over emphasise the businesses and ignore the flats above.
Wrong as in officially deprecated in the wiki? If so, please give me a link.
Yes, I know there are flats above shops. However, I suspect that most data consumers care more about shops than flats. I also suspect that most data consumers are sophisticated enough to figure out that if somebody says they live at 3 Womble Street and the map shows that 3 Womble Street is a shop then the person lives in a flat above the shop. Of more concern is the limits on how much can be displayed in (say) mapnik: having a shop and a flat marked at the same location may well result in the flat being shown in preference to the shop.
Add in the fact that 3D representations are rarely entered as data and most display s/w handles only 2D. Add in the fact that mapping shops as you suggest is essentially duplicated effort. Oh, and in your representation should both the shop and building have address info? That’s needless duplication. But without the duplication queries would return shops without addresses. It starts to get very messy.
So, again, is your way of doing things officially-sanctioned good practise (with wiki link saying so) or just your concept of what ought to happen in an ideal world? If it’s merely something to strive for, I’m happy with that. If anything but your way or a node is unacceptable, then I’ll be using nodes from now on, and probably won’t bother mapping the building any more.
Wrong as in not representing the true situation. I’m sure I’ve seen several people saying this in the past. I suspect it is too obvious to bother putting in the wiki. (The wiki is unfortunately often wrong in commission as well as omission, so should not be taken as gospel.)
Also, I would say it was much more likely that data consumers would be visiting a relative or attending a colleague’s party, than wanting to find out how to get to a shop on a local parade that they didn’t already know about by having seen it. Even business consumers are probably more likely to need to look up the location of residential addresses than businesses.
Further note that the amenity often occupies a larger area than the building. There are some grey areas in the case of shops, as whilst, legally, the forecourt often belongs to the shop, not the local authority, the casual observer may not realise that part of sidewalk is actually permissive, rather than public, although it is often possible to make a good guess, and a licence may be needed to trade on that area, and that licences may extend to public parts of the pavement. Pubs and schools tend to have much clearer borders beyond the actual building.
Also, the reason why so many people, on this thread, are suggesting a node, and RicoElectric even says node unless it is the entire building, is that tagging a shared building is wrong, and it is often not possible to establish exactly which parts of the building are actually used for the amenity.
Time to drag Korzybski into this: “The map is not the territory.”
All maps are approximations to reality. Given the limited resources OSM has (number of mappers and amount of effort they’re willing to put into it) I think we’re lucky to achieve “good enough” even some of the time.
I beg to differ there. This whole thread started because it wasn’t obvious to somebody whether shops should be mapped as a node or an area. This fine distinction of yours certainly wasn’t obvious to me.
Nevertheless, it’s a good starting point for evaluating if something is accepted practise or merely one person’s opinion.
You may live in a less rural location than I. If you have to travel 30 miles to your nearest shop of a particular kind, or office of a particular kind, then you kinda want to know exactly where it is in advance. You perhaps have houses that are more consistently numbered than I, because around here maybe 50% have names and not numbers. Somebody saying “I live at flat 2, Dunroamin, Womble Street” is less common than “I live above the Spar on Womble Street” when the house is un-numbered. Shops are a lot easier to spot at a distance than house numbers or names.
Yes, there are bizarre cases where extra steps have to be taken. Like splitting my local Boots into a chemist and a pharmacy because the pharmacy closes for lunch whilst the chemist remains open. Like a local pub that occupies the cellars of 3 adjacent buildings and shares a common entrance with the cafe on the ground floor of one of those buildings.
I think the examples you gave would be better handled by areas which included the building. But maybe that’s just me.
Before you raised your requirement for dual mapping, I had the following scale of perfection in mapping shops/offices/organizations.
- Nothing.
- A node marking a shop.
- A building with a node (marking the shop) in it. Sometimes necessary if the building is shared between 2 or more retailers.
- A building marked as a shop. This is very easy to do in iD. Almost like you were meant to do it that way.
- A building containing one or more areas marked as shops. Very fiddly and time-consuming with little gain unless it’s one of those special cases.
I normally used 3 with 4 reserved for special cases. If you’re telling me that 3 is forbidden then for most cases I’m going to go with 2 or even 1. Or maybe give up because it’s too much effort. Insisting on perfection is a barrier to entry and we don’t have enough mappers as it is.
Just my opinion.
I wouldn’t say it’s forbidden to re-use building areas. It’s relatively common to see shops mapped that way, so it’s at the very least tolerated. And if you want to continue using that mapping style, it’s unlikely to cause much conflict. (Depends on the opinions of your fellow local mappers, of course, but still.)
At the same time, I’d argue that a separate area is clearly the better representation, semantically. So while I wouldn’t object to someone re-using a building area for shop tags, I would consider it a further improvement to migrate the shop to its own area (which you seem to agree with given your scale of perfection).
Aside from the issue that shops often only occupy some of a building’s floors, there’s another inevitable problem with using the same way for multiple features: It becomes ambiguous which feature additional tags on the element refer to. Is name=* the name of the building, the shop, or both? Is that Wikipedia link about the historic building or its current occupant? Is start_date when the shop was founded or when the building was built? And so on.
To sum this up, I believe that using the same way for the shop and the building causes some issues, and we might leave this method of mapping behind some day if our quality standards continue to improve. That does not, however, mean that shops mapped using a less than perfect style aren’t a valuable addition to the map today.
On a related situation tagging shops in a multilevel 3 -storey shopping mall, what is the accepted convention for placing the nodes? I am inclined to place shops at he same level , e.g. basement, along rows then 1st floor on the next row.
Any comment, negative or positive helpful or otherwise, is welcome.
They shouldn’t be in rows unless the shops are physically offset by the distance between rows. Putting them in rows just so more of them render is tagging for the renderer, and even doing so for ease of selection in the editor is a form of this.
I’d agree that it’s a more complete representation in the database to separate the shop from the building. As for being “better,” even restricting that “better semantics,” is questionable (see later paragraphs).
I sort of agree. 
Thinking about it, maybe it’s actually a scale of completeness of representation, or a scale of effort involved in mapping, more than a scale of perfection.
Ideally, we should map everything mappable, but I don’t think that’s a realistic proposition. Most shops are very easy to map. You can see what they are and what they’re called with a quick glance as you walk or drive past and you can locate them easily (usually) from aerial imagery. Flats are harder. You have to walk close enough to the building to peer at faded flat numbers on an entry system and then guess as to how the building is partitioned internally. It’s a lot of extra effort to do at all and even more effort to do perfectly.
There’s also the problem of how it affects rendering. Yes, I will recite the holy mantra “don’t map for the renderer” but it’s still the case that with most renderers, even at maximum zoom, the renderer will make an arbitrary (to us) decision of which label to apply. Maybe we need additional tagging to suggest label priorities (display the shop name first, if there’s room display this flat name, if there’s even more room then display this attic flat name), although that may be too much effort for most mappers to bother with. Maybe renderers could use the level=* tag to determine label priority in most cases (levels closer to zero have higher priorities).
Actually, it’s worse than that. Do you give the shop the same address as the building or leave the address blank? Programmers have been taught (rightly) the word “DRY” standing for “Don’t Repeat Yourself.” Having the same information in two places means that data inconsistencies can, and usually do, arise. However, if you do not give the shop an address then some tools will not return the address of the shop, forcing the user to then query the building if the address is required. You could have the tool notice the shop doesn’t have an address and query the enclosing/contiguous building for the address but that will go spectacularly wrong if there isn’t such a building.
The building/shop distinction requires more work to add them in the editor and more (error-prone) work to edit later. Improvements to editors might be able to mitigate this.
That was my viewpoint. It’s not perfect but it’s better than what was there before I started mapping in my area. What was there before was either nodes (often misplaced by being 20 metres away on the wrong side of the road) or nothing. Perfection can wait for another day.
No. This is a decision for the render to make depending on its target audience. There should be enough information already present to allow it to make the priority decisions for itself.