Hello everyone,

We are developing an app for bar, hotel and restaurant reviews, called Revuie.

With all the changes that have happened with hospitality recently, we need to be able to give our users a quick and easy way to edit or add venues. Hopefully, we can add back by contributing those edits. But we’re wary of the risk of bad edits.

One initial idea was to just make the edits in our local data, and then publish a change file that could be used as a source for the community. But the problem we can’t get our heads around is how to de-dupe those changes on future imports of OSM data.

Another alternative is to use the API to make the changes, identifying them as coming from a user tied to our app - and maybe setting them as needing review?

Whatever approach we take, we can create guides for users so that they can get a feel for how and when to make edits - and as the change functionality is implemented in the app it can be buttoned down.

We’d love to be a part of the community, and to contribute it back, so it would be great to get any advice and feedback people have on this, please.

Another puzzle we're facing is how to enable users to tag venues, and keep that tag list in line with existing OSM tags, as the tags could come from various sources. For example, we'd definitely want to include cuisine. Some pubs have sport tags (like pool) which could be useful. Across food, drink and accommodation, there must be lots of tags that we haven't considered. Any advice on this would be great too. Ultimately, we want to encourage tagging of venues in the app to enhance user search, and it would be great to contribute this back too.

Many thanks,

John

asked 24 Jun, 15:11

JohnB-Revuie's gravatar image

JohnB-Revuie
41114
accept rate: 0%

edited 25 Jun, 08:21


Hi John, it sounds like you have two possible approaches here:

  • Include limited OSM editing capability as a feature of your app, calling the API directly from users' devices. Many apps do this; OsmAnd is probably the most prominent. Any user of your app who wished to contribute data to OSM would need to create an OSM account, and supply your app with their credentials.
  • Collect and curate data from your users into your own database, and import that data into OSM at intervals using a single dedicated OSM account. As you mention, there's the obvious problem of deduplication. Also, imports in general are a tricky topic, and there have been many over the years that have done a lot of damage, so prepare for a lot of resistance to this approach.

Some useful reading:

Regarding the tagging, you'll want to maintain parity with existing OSM tagging practices. There are established tags for cuisine, for indicating that pub has a pool table, etc. There may, though, be details that you're interested in that are considered out of scope for OSM, such as individual menu items, pricing information, special promotions, government inspection scores, and, of course, the reviews and ratings themselves.

...

Whenever I hear of third-party apps using OSM for business reviews, the biggest problem that comes to mind is that there is no standard method to ensure that an individual business has a persistent unique ID in OSM. Eg, one mapper might add a restaurant as a node, then another mapper might remap it as a building, which will be a different element in the OSM database. Then another mapper might decide it shouldn't be the whole building because it's a multi story building and the restaurant is only on the ground floor, so it gets moved to a brand new node inside the building.

Then the restaurant moves into a new building across the street. A mapper might choose to move the node from the old building to the new one... or to create a new node in the new building, and change the tags on the old node so it's reused for the new business that's moved into the old space.

Meanwhile, the name might change, eg "Greggorys"->"Greggory's"->"Gregory's"->"Gregory's Cafe". The phone number and website might change too. It would take a fair amount of work to sync a single record in a remote database with these different OSM elements and changing tag values.

This is a solvable problem, but be aware that it will happen.

Some more fun reading: https://wiki.openstreetmap.org/wiki/Persistent_Place_Identifier

Good luck with your app!

permanent link

answered 25 Jun, 16:55

jmapb's gravatar image

jmapb
2.9k72952
accept rate: 23%

edited 25 Jun, 16:57

Hi jmapb, thanks for the detailed answer.

With the editing, I wonder if there is an in between option, where we call the API for limited editing, but use a 'RevuieApp' OSM account, so the user doesn't have to create their own. This would also mean that any edits could be easily identified as coming from the app, so we could more easily tweak the process in the app based on feedback from the community. Would be great to hear any thoughts on that.

Thanks for the tip on the persistent unique ID. We hadn't accounted for that, so will read up on the links and put some thought in to it. I'm sure we'll be back with more questions on that one!

Thanks again,

John

(26 Jun, 10:34) JohnB-Revuie
2

If you are creating a new app that submits edits it should already have a created_by tag set on the changeset to make them identifiable regardless.

(26 Jun, 13:51) InsertUser

Thanks InsertUser, will have a look at that tag

(27 Jun, 19:24) JohnB-Revuie
1

On the question of using a "'RevuieApp' OSM account", I suspect that you might struggle to agree to OSM's Contributor Terms given that you don't know what users are submitting or where they've got it from. Generally speaking apps use one account per actual user. There's an OSM Licensing Working Group and they'd have more idea than me.

(27 Jun, 22:33) SomeoneElse ♦
2

@JohnB-Revuie I can't speak for anyone but myself as an OSM mapper and user, but offhand... numerous users editing the map with a shared account doesn't sound like a good idea.

By design, individual users are responsible for their own changes to the map, and other users may want to communicate with them about those changes. If I see a change I don't understand or wish to know more about, I can leave a comment on the changeset, or message the user directly. This will trigger an email to the address associated with the account.

Whoever handles your RevuieApp account would get emails intended for the users who actually made the changes, eg "Why did you call this a doctor? It looks like a deli" or "Are you sure they're open? I passed by last week and it had a For Rent sign" or "Did Gregory's close, or is this another business in the same building?" or "Why did you change this to a restaurant?" These questions might make sense to the user who made the change, but not to whoever's checking the email account for the RevuieApp OSM user.

(28 Jun, 02:19) jmapb
1

@JohnB-Revuie Also, if one of your users was suspected of copyright infringement or vandalism, OSM's Data Working Group would get complaints against the entire RevuieApp account, and might choose the block all of this account's access, which would break the app for everyone.

In short, what you're describing is different enough from the way that OSM usually works that I don't think it would go over well, and I wouldn't be surprised if it was somehow explicitly forbidden.

(28 Jun, 02:21) jmapb
1

Thanks jmapb and SomeoneElse. Some really key points for us to think about there, especially around the contributor terms and the risk to the whole account being blocked.

(28 Jun, 12:18) JohnB-Revuie
showing 5 of 7 show 2 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×900

question asked: 24 Jun, 15:11

question was seen: 529 times

last updated: 28 Jun, 12:18

powered by OSQA