If i want to tag both the finished construction date of a building, and the establishment date of the organization that occupies the the building, how its done?
Thanks!
1 Like
The date of finished construction would be start_date on the building element.
You also want to map the establishment date of the organisation in the building. Depending on the situation, I’m not sure if that kind of information would even belong on the map. Would it be better to add that information to a Wikidata page for the organisation, which can then be linked with the operator:wikidator=* (or similar) tag?
On the other hand, there are situations where it would make sense to tag an organisation’s start date, e.g. if there’s a Restaurant node inside the building, and the restaurant opened after the building was constructed.
(This would get more complicated if said restaurant and building are the same element… Others may be able to provide further guidance.)
On the other hand, there are situations where it would make sense to tag an organisation’s start date, e.g. if there’s a Restaurant node inside the building, and the restaurant opened after the building was constructed.
in the case of a restaurant, it is not clear what start_date refers to. I am using either the date of the opening (as it happens or as I know) or the date they use themselves (“since 1975”). But what is it about, the operator (company)? The name of the restaurant? The name of the restaurant at this place? The owner? The management? The chef?
These are not important questions if there wasn’t such a business before in a place, unless maybe a business moves and it should not be considered a new start date because they have been somewhere else and are still “the same”. A shop that moves next door, is it new? And if it enlarges and is now also next door?
If the operator is a person, it will change if she sells it, but if it is a company it would remain the same even if the company was sold, as long as the new owners keep operating with the same company?
This is not really clear (for example I have seen restaurants change the name and announcing new opening, but the operator and vat id remained the same).
Often it doesn’t matter, but in the other cases it isn’t clear what the rules are.
Cheers Martin
According to the wiki page start_date seems to apply to the node itself. Beyound a basic tag page for construction:start_date, I couldn’t find any guidance on how to attach a start or end date to a namespace.
I would convert the quote to:
restaurant node; start_date=1975 on
only indicatecurrent operator; operator:start_date=
OSM doesn’t really care about anything more than the physical building and its occupants. The current occupant is usually mapped as a node, tagged with it’s own basic details (Yelp or similar). That node should be placed in the location as the business or living space currently located with in the building.
Previous occupants or buildings that were standing on the same should be recorded in OHM. Any further information should be on a website or the appropriate Wikipedia page.
If there is multiple organizations then it could be nodes, however if the organization own the whole building then the “one feature, one element” -rule applies.
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
This does not really reflect reality in the said example. In my town we tend to map POIs separate from buildings, regardless if it is occupying the whole building or not. The reason is mainly the ever increasing amount of detail a building gets. Things like the year it has been built, architect, heritage status, addresses, 3D tags and the like make it increasingly sensible to separate the data.
Also if you study the wiki article above, there’s lots of situations where deviating from the general rule makes sense. In this case you can argue there’s two features, so make it two elements.
2 Likes
however if the organization own the whole building then the “one feature, one element” -rule applies.
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
a building and a business are never the same feature (unless we define it as such 
), they may coexist in current mapping but the cited “rule” does not help in any way to solve the question because we define ourselves what constitutes a “feature” and can define it either way and have indeed also done so and can add to the feature set at any time by introducing new tags
1 Like
There are several problems here:
- mapping POI and building as one object is a bad idea (ideally shop and building would be a separate objects - see One feature, one OSM element - OpenStreetMap Wiki )
- start date is dubious to map in OSM as typically unverifiable, I would rather map it in OHM
- start date is poorly defined for many objects which were rebuilt/recreated etc
not really, we do not map all hotels owned by one company as globe-spanning multipolygon
1 Like
The corollary to the “One feature, one element” principle is “Two features, two elements”. The fact that the building and organization have different lifecycles speaks to there being two features in reality, so you could map the building and its occupant as two distinct elements. The organization could be a node within the building, or to express the fact that it occupies the whole building, you could make it an area coincident to the building (sharing all the nodes). Then you’d add a different start_date to both without worrying about namespaces.
When time comes into the picture, the ship of Theseus must not be not far behind. 
I don’t map start_date very frequently in OSM, but when I do it’s in response to an establishment date that’s readily available, like on a cornerstone. These dates can hide a lot of nuance, like the difference between a building’s completion and its official dedication. In my region, most road bridges have a sign or stamp bearing the year built, but sometimes the year stays the same if the bridge deck is rebuilt. A company may claim to be “established in 1800” even though it’s actually a much newer company that purchased the older one. So far I haven’t encountered a situation where it makes a practical difference in the context of OSM.
Wikidata and OpenHistoricalMap both have more robust mechanisms to organize these dates and changes. For example, Wikidata has an item about a building in San Francisco that Mapbox used to occupy; the dates during which Mapbox occupied the building are distinct from the company’s dates of operation and the building’s establishment. OpenHistoricalMap doubles down on the “two features” approach I mentioned above, to the point that a chronology relation becomes useful for tying together the various copies of a house or an art gallery that has moved repeatedly, or a school building that has been expanded multiple times. I don’t tend to dual-tag a building with its occupant nearly as often in these projects as I do in OSM, because dual-tagging makes it a lot harder to keep these concepts straight.
4 Likes
I would use multipolygons (sharing outer way) or smaller area within building (justifiable as they use rooms inside).
Area sharing the same nodes are irritating to edit.
I don’t understand how a multipolygon would be helpful.
to reiterate above reflections about start_date, here some cases:
-
A restaurant moves from one location to another, say 2km apart, and keeps all their staff and the name and the operator, etc. From my understanding start_date would be the date when the restaurant started operating on the first place, no? After all, we separate features from buildings?
-
I you believe the answer to 1 is start_date at the second location, what if it moves from the second floor to the third?
-
The restaurant remains on the same location, doesn’t change the name, interior, menu or the staff, but the owner sells it to someone else (different tax number, different operator, different owner)
-
Like 3 but the operator changes the name of the operating company (same owner, same operator but different operator company name)
-
The owner and staff remain the same, the place undergoes some redesign and they also change the name of the restaurant (same operator company and operator name, same tax id)
1 Like
It would be easier to select building/POI multipolygon over situation where you have two ways over the same nodes.
The multipolygon approach does make routine editing more convenient in some editors, though both iD and JOSM have shortcuts for selecting overlapping ways. On the other hand, if the business subsequently downsizes by leasing half the building to another business, if it moves elsewhere, or if you discover that a different business occupies the upper floor, then it becomes difficult to update the original business without discarding history. At least in iD, you can separate an overlapping area from a building area with one keystroke using the Disconnect command. (If the building is dual-tagged as a business, the Extract command accomplishes the same effect.)
3 Likes
Do you have an example? I don’t understand how the members of the MP wouldn’t still be ways sharing the same nodes.
1 Like
multipolygons:
- 4 nodes
- single way on that 4 nodes
multipolygon A: tags + has this way as sole outer member
multipolygon B: tags + has this way as sole outer member
accessing objects for editing annoying but doable
two ways:
- 4 nodes
- way A on that 4 nodes, has tags
- way B on that 4 nodes, has tags
requires special keys to access bottom way (and in both iD and JOSM I would have trouble to do this)
I would never go with a relation if things are mappable without. Relations confuse newbies and often break because of that.
Map the building → put node(s) for POIs inside → done.
2 Likes
At least in iD, you can separate an overlapping area from a building area with one keystroke using the Disconnect command.
in josm with unglue (shortcut g)
I don’t see how it’s easier to select one of two multipolygons at the same location than to select one of two ways at the same location. But even if it was, I don’t think we should “tag for the editor”. A multipolygon with only one member doesn’t make sense from a data model perspective.
I don’t see how it’s easier to select one of two multipolygons at the same location than to select one of two ways at the same location.
you select a member way and the editor will show all relations in the properties window (josm and gomap this is)
But even if it was, I don’t think we should “tag for the editor”. A multipolygon with only one member doesn’t make sense from a data model perspective.
it makes more sense than overlapping two identical ways with tens or even hundreds of nodes.
And it is a preparational step when you want to tag walls and fences around the thing.
Stacked ways also bear the problem that it is almost impossible to spot connection problems (other ways or nodes not connected to all ways but only some of them)
These are only some aspects, and there are likely more, relations being considered complicated by newbies is one of them
1 Like