COFFEEDEX & the single-tag revolution

Posted by tmcw on 1 December 2014 in English (English)

COFFEEDEX is a thing I made to track coffee prices worldwide.

Late in the iD Editor sprint, I wrote osm-auth to make the OAuth dance easier for potential future editors, thinking that a lot of common editing tasks would require super-focused UIs. COFFEEDEX is more or less the first attempt at doing that: it edits a single tag on a single type of node, amenity=cafe, and only on local nodes.

It's also made to be a pretty decent example for people who want to write their own editors: it's ~500 lines of terse JavaScript, pretty well-organized with React & the latest goodies.

Does this bloat the database? My back of napkin math says that if we tagged all 150,000 cafes with 32 chars of <tag k='coffee:price' v='$10' /> we'd end up with a grand total of 38.4MB of bloat, on a database that weighs 38GB, so we're talking a tenth of one percentage of an increase.

Which brings me to the idea: what other things can we conquer in a single tag? Wheelmap is the great-grandaddy and most awesome example of this. How about:

  • An editor that asks you how many stories the building you're currently standing in has. Or what color?
  • Bridge height entries
  • Opening-hours-only editor


See a bug? If you have a GitHub account and want to be super nice to me, please file a bug in the GitHub issue tracker!

Location: Chester, Morris County, New Jersey, United States of America

Comment from jutezak on 1 December 2014 at 06:54

Hmm even though I like the idea of adding data, this data is not really geographical.

It is also subject to change. The price would also need an asociated date.

Actually this kind of data would be very useful in separate-but-linked-to OSM data.

Think traffic information: that data is too fast changing to put on the map, but when you plan a route, you need to know which parts of which ways are free to move on. Finding these from OSM to whateverservice is similar to finding a coffee shop in OSM and looking up the price in service B.

If you see the 'coffee price' as an indicator of 'general price level', things change a bit. But even this is not really geo data.

Comment from Zverik on 1 December 2014 at 07:52

But there are ten kinds of coffee in our cafes, which one should I tag?

Comment from Sanderd17 on 1 December 2014 at 09:40

It's geographic data "the price of a coffee on a certain place", but I agree it will be outdated way too soon (I wouldn't be able to maintain the pubs in my village).

Next to that, there seems to be no standard currency notation. I've seen

  • coffee:price = EUR3 (strange notation, I'd expect "3 EUR" in this case)
  • coffee:price = £ 1.00 (ok, the app should read special signs. What sort of symbols are used?)
  • coffee:price = $1.84 (now, it reads special signs, but there are many dollars. Which one is meant?)
  • coffee:price = 1.10 (I should just guess the currency here?)

And Zverik is also right of course. What's the price of a coffee at Starbucks?

Comment from Andy Street on 1 December 2014 at 10:59

The trouble with defining prices as geographic on the basis of it being "the price of something at a certain place" is that it doesn't scale (your average supermarket carries thousands of products) and can often change very rapidly. That said, I am guilty of tagging prices of car parks so I'm not against tagging prices completely. Perhaps we need to make the distinction between price comparison (i.e. choosing the destination based on price) and routing (i.e. I want to go to destination x for duration y by car, which car park do I need?).

When it comes to currency I use ISO 4217.

Comment from tmcw on 1 December 2014 at 13:11

But there are ten kinds of coffee in our cafes, which one should I tag?

Good question - this has already been addressed in the FAQ, but up for debate if someone sees a way to make it clearer:

Which coffee? This site tracks the price of house coffee for here. In many cases, that means a 12oz drip, but if all coffees are pour-overs or your country uses different standard size, the overriding rule is cheapest-here.

I'm interested in a clearer idea of what 'non-geographical' means in itself, separating the issue of 'it changes too often', or is it the same, and should just say the latter and not treat them as two issues. Shapes are obviously geographical, and classifications - amenity, highway, etc., are as well, but OSM has always stored much more than that, and much more than is represented on the map.

I think there is some 'geographical enough' criteria that's valid, but I'm drawing blanks on what it is and how we could explain it in some way other than the "know it when I see it" criteria.

It's my personal feeling is that things that are "on a map, factual, and current" should be welcome on OpenStreetMap but not necessarily endorsed or rendered.

Sanderd17 - good points about notation and Andy, thanks for the ISO link - I'll check that out and see if I can implement it in COFFEEDEX.

Comment from Alan Trick on 1 December 2014 at 17:46

It's my personal feeling is that things that are "on a map, factual, and current" should be welcome on OpenStreetMap but not necessarily endorsed or rendered.

This is a bit of an extreme, but something like "the location of the President of the United States" is "on a map, factual, and current". It might even be something you might make a map of, but it's obviously not something you want in OSM.

For a less absurd example, how about "Elvis Presley" sightings, or "UFO sightings". These are semi-geographical bits of data, but still not things that I think belong in OSM.

I think here are some better guidelines of what belongs in the main OSM db.

  1. Is it likely to be used in more than one map?
  2. Is it possible to keep the data up-to-date without regular imports?

If the answer to either of these is no, than there is a good chance your data is better off as a separate data source.

Comment from Nakaner on 1 December 2014 at 18:35

I think that OSM is the wrong location for prices of goods. OSM is a geographical database. I suspect that you just do not want to (1) run a separate database and (2) do not want to care about linking objects between OSM and your database.

You might say that coffee prices comply with "We map what's on the ground.". I agree with you at this point. But one of the main problem is that coffee prices are hard to maintain (keep up to date).

If someone maps coffee prices, what will be the next good whose prices is being stored at OSM? Decaffeinated coffee? Hot chocolate?

I know that some prices are mapped at OSM. Those prices usually are services like parking fees, fees to store luggage at a locker or going to toilet. But all these prices are paid for services which are often offered for free. Most car parkings are free (your town may be an exception), most toilets can be used without paying 1 Euro (you might have to buy something if it is a shop's customer toilet). Coffee at a cafe usually is not for free.

There are a couple of partially-geographic information at OSM, e.g. opening hours, phone numbers, websites etc.

Just a word about Wheelmap: Wheelmap is an editor about wheelchair related information (and some other POI tags). Wheelchair accessibility is a physical feature.

Comment from tmcw on 1 December 2014 at 18:38

I suspect that you just do not want to (1) run a separate database and (2) do not want to care about linking objects between OSM and your database.

Did "wanting to contribute to OpenStreetmap" not come to mind?

Comment from joost schouppe on 1 December 2014 at 20:40

Absolutely love the concept. Would like to see an application to add WiFi availability this easily.

Comment from vtcraghead on 2 December 2014 at 03:44

Obviously geographic data is ephemeral; especially roads, with their constant condition changes and expanding networks. I don't think the minutia of "appropriate time scale" is really the point, and I love the point:

This is a proof of concept for contributing value-add information to OSM; it perfectly compliments the data model and expands the project's capabilities.

Comment from DaCor on 2 December 2014 at 20:19

When I saw this I had the same thought as Joost, something like this for wifi would be a good idea

This could be expanded to many different uses e.g. Bus stops (rtpi, shelter, recessed etc) fast food (cuisine), parking (free or not), schools (level, mixed, ethos, etc)

Heck the toilet map recently reported on would benefit massively from something like this

As a proof of concept I think it's fantastic and a great example of what can now be done because the groundwork is done

Props to you Tom

Comment from drewda on 4 December 2014 at 02:16

Nice work, Tom. Whether or not coffee price turns out to be interesting to have in OSM in the long run, I completely agree that topic-specific editors are a useful addition to the OSM toolkit. Thanks for creating and sharing this.

Comment from dieterdreist on 4 December 2014 at 14:26

@joost_schouppe "Absolutely love the concept. Would like to see an application to add WiFi availability this easily."

You can! And

Comment from rorym 🏳️‍🌈 on 4 December 2014 at 14:44

I think this is wonderful, and love the idea of topic-specific editors. I think OSM needs to "go deeper", and these sort of tools can make that possible.

Now to figure out what "12oz" "drip" and "house coffee" mean. :)

Comment from Sam Wilson on 5 December 2014 at 03:02

Now to figure out what "12oz" "drip" and "house coffee" mean. :)

Ha! Yes, exactly! :)

Comment from joost schouppe on 5 December 2014 at 15:16

@Dietrdreist, I've been adding that tag on the road with Osmand. It's easy! If you're a mapping nerd! But with a dedicated editor it might be easy for any old nerd.

Comment from joost schouppe on 7 December 2014 at 20:22

Now that I've actually tried the thing: - the "world map" only shows café's that already have the info? I'd like to be able to browse the map to check for places I know, not just places closest to me. - the rendering doesn't seem to show plaza's clearly, good points of reference when it comes to café's - the little map for a café isn't always very clear. It would be nice if you could zoom in/out there as well

Comment from tmcw on 7 December 2014 at 23:27

Selecting places via a map is definitely in the plans, but probably not as part of the World Map feature - there are over 150k total cafes in the world, so it'd be a brutal Overpass API call :)

Comment from joost schouppe on 8 December 2014 at 23:17

Please don't kill overpass :)

Just only make the call after a certain zoomlevel is reached?

Comment from richlv on 9 December 2014 at 22:18

hopefully this is an attempt at specialised editors and starting a discussion, not a serious intent :)

otherwise i'd like to map beer prices. and bread prices in supermarkets. and availability or alcoholic drinks. and room prices in hotels. oh, and their availability, too...

Login to leave a comment