I’ve wrapped up the grocery store POI import over the last week or so and am looking to move on to hotels. The process will be basically the same as with grocery stores, in that I plan to not overwrite existing OSM data, and missing objects will go into the MapRoulette challenges. The main difference for this one is that I plan to overwrite name, branch, brand:wikidata when the ATP data has branch or brand:wikidata info. The branch tag seems strangely underutilized for hotels in the US, so this seems like a good opportunity to rectify that.
The cleaned hotel data is all available in the project’s GitHub repository, and the updated OSM wiki page is here. I haven’t split out the data with examples because each of the files has many sub-brands with varying amounts of data that I’ve mentioned in the wiki page. I can do that though if it’s useful. Happy to answer any questions again or field feedback!
Interesting. Could you point me to where this has been discussed? I wasn’t able to find any back-and-forth on this for the US context, so I figured this was nonstandard tagging instead of established practice.
Here’s a discussion from OSMUS Slack a few years ago that’s relevant: Slack. The consensus seemed to be that the non-uniform names are preferred, or at least accepted as commonly used. I agree that automatically changing portions of existing name= tags to branch= on hotels would be controversial.
I think the reason for this is that unlike, say, grocery stores, which are all roughly interchangeable within a brand, for a hotel it very much matters to the consumer which particular branch a location is. This is both because location is a major feature of a hotel, and because one books a reservation for a specific branch.
For a concrete example, take this hotel: Way: Hampton Inn & Suites Santa Monica (398282112) | OpenStreetMap. Per atp-import/data/hotel/hilton.geojson at master · whubsch/atp-import · GitHub, it looks like your proposed edit would change it from name=Hampton Inn & Suites Santa Monica to name=Hampton Inn & Suites + branch=Santa Monica. I don’t think either is wrong, per se, but I think that for the average use case, it’s important that this is specifically the Santa Monica Hampton Inn rather than, say, the Hollywood one. Compare that to discerning between branches of a Bank of America or Target or something, in which the branch is ancillary information that isn’t as vital to the typical use case. In a sense, each location of a hotel has a sufficiently specific identity for the OSM items to have non-standardized names.
Or do people prefer to have the branch name in the name tag because of poor support for branch in the frontend?
E.g., see this issue at Organic Maps about not utilizing the branch tag
I have to say I’m not that convinced by this argument and see it more as @eisa01 suggests - that it’s more a reflection of spotty rendering support - but it sounds like a bigger conversation would need to be had about this that’s beyond the scope of this import. An acceptable compromise for the purposes of this import I think would be to add the branch tag and leave the unstructured combo name as it is, effectively leaving the branch information twice (potentially for easy future cleanup).
branch=* is a valid tag to use, but name=* should include branch=*. Otherwise, it’s basically impossible to reliably reconstruct the fully qualified name that many users would expect for certain POI categories like hotels. This is not purely a rendering issue; geocoders also need to be able to display a conventional, fully-qualified name.
Supermarkets are a poor precedent here. Most chains merely number their stores for internal purposes; you generally only encounter the store number on a receipt. By contrast, hotel chains generally give each location’s name much more prominence.
For both supermarkets and hotels, the individual location names can be more important than the brand name in chains with looser affiliation models, such as IGA and Best Western. You can’t be sure that the fully-qualified name is the brand plus the branch; it could be branch’s brand or brand at branch, or even just branch in the case of luxury hotels that don’t want to say Best Western too loudly. At the very least, you should keep the fully-qualified name in official_name=* to avoid dataloss.
To be clear, I now plan on keeping name as it is and just adding branch where it doesn’t yet exist. I’ll leave the “branch in the name” discussion for another day as it sounds like a beast of its own
I noticed this import and I found the use of the “ref” tag questionable. As far as I understand, the “ref” value imported here is a foreign key as used by the ATP dataset. Therefore, at the very least, I would have expected it to go into “ref:atp” or something like that. Surely if a hotel chain were to assign references to their own hotels, those would go into “ref” and not those assigned by an independent third-party system?
Independent of what tag is used - and I really think “ref” is a bad idea for storing the ATP ID of something - the question of whether to keep a reference to third-party data at all has been debated widely in the context of imports. Personally I am against it because it unnecessarily bloats the OSM database and removes agency from the OSM mapper - if I map in Massachusetts and I want to merge two buildings with two different MASSGIS IDs, what should I be doing? Will some future automatic task overwrite my edit? Most mappers will simply shy away and do nothing. I think that keeping an ATP ID runs a danger of sending the same signal (“this is a read-only copy of some external data, don’t edit”). Speaking very generally, in my eyes if you put external data into OSM then you put it into a melting pot and you cannot expect your data to remain individually identifiable - it might be broken up, merged, changed, whatever. If there is any desire to make future comparisons between OSM and the external dataset used to import some data, then this comparison must work even in the absence of explicit reference tags - and therefore, we can skip their insertion altogehter.
Has the use of “ref” tags in the context of the ATP import been discussed anywhere? I can see the wiki page says “I will seek to maintain ref values to facilitate future semi-automated syncing if such tooling becomes available.” but I’d say using the “ref” tag for this is certainly wrong, and retaining the ref value in any from is at best questionable.
I think this may be at least partially–if not entirely–a misunderstanding, but I’m also open to not using the ref going forward if folks still feel strongly. I think what you’re suggesting the ref value should be used for is exactly what it is. Neither I nor the ATP system created what I’ve called the ref values for hotels (or for grocery stores, although those were less prevalent). They are taken from the brands themselves, presumably as a way for the companies to distinguish between different branches.
The most obvious place they are often used is in website URLs, but I think they are used in other business areas too, like accounting/billing. It is not a totally random alphanumeric string; an example would be SANVR, which for Marriott represents the Residence Inn San Diego Chula Vista.
I don’t think I will be updating any objects using these keys in large part because I’m not technically proficient enough to create a system to do so, and that was not the main intent of including that information. Happy to discuss more!
