While I don’t think that Alyssa set out to make an offensive statement, the statement was nonetheless offensive.

This is it, Serge. If you can say both of you were speaking from painful life experience, and are both fallible - but at the end of the day are people worthy of respect - it would do a lot here.

For those lacking context: the thread, the 60 day ban. I’ve added the mailing list to the wiki.

Our first effort, the CoC, was very close to acceptance right around the time everything went south, partially due to Serge’s helpful input.

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 :)

If anyone has a particular validation in mind they want to see in iD, I’d recommend checking out the existing validations and adding one: it’s an open source project and we’re happy to help integrate improvements from the community.

Great post, definitely highlights the core problem here: beyond rules and validation and so on, there’s a social question and a question of onboarding.

I’m optimistic about comments on changesets. If they’re friendly, then experienced users could, for instance, review some percentage of new edits and create & explain their corrections in the same sense as the editor of a book or how code reviews work in programming.

If some voluntary review process, like a checkbox to say “I’m not sure about this, can someone check my work”, were technically feasible, it could be a good thing. I’m not sure that is technically feasible at the moment, because of the infrastructure required and the increased chance of conflicts. But, it would be a fun thing for someone with time and energy to experiment with.

Good real-world systems are error-correcting and human.

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?

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.

To be clear: we’d be happy to accept a pull request that adds support to iD, as stated in June of 2013. Nobody has stepped forward with code to do that, so it hasn’t happened. Anyone who can write it and submit a pull request can make it happen today.

Do any of the editors warn you if you try to upload a change that includes a lot of deletions?

The answer is yes. Here’s iD’s implementation.

Fwiw, I’m pretty bearish on GeoGit, for a number of reasons.

Java is a poor choice of basis - your contributor base is small and userbase has to deal with Java-isms. The ‘multiple backends’ concept makes performance and potential hard to pin down. The military-fund-for-open-source model of project management often produces incomprehensible software (see: GeoPackage). The GeoGit model is, like Git, more or less a glorified hash table whereas OSM is at its core not a list of features but a graph database, and the graph-ness of this graph database makes the idea of versioning it fundamentally different than a shapefile or PostGIS database. The lack of opinion in terms of datatype means that operations will be lossy and non-pure for quite a few datatypes, unless GeoGit’s internal format is a superset of all geospatial data formats. And there’s no real solid answer for how GeoGit will scale to OSM, even if the bottleneck of database throughput is removed.

That’s not to say that I disagree with the intent - nearly everyone agrees with the intent, and wants something-of-this-sort.

Awesome! Nice work

Hey all,

From the iD side:

We currently have a brainstorming ticket about presets. It’ll be one of the main objectives after we tag an alpha1 release.

Some prior art here: JOSM & Potlatch both have formats for exactly this: JOSM and Potlatch implementations.

We’re also making strong use of Taginfo, which through its API can provide recommendations about related tags. This also provides an API for wiki-sourced documentation of tag combinations, including thumbnail images.

When we do implement presets, it’s likely to be in a simple JSON format: XML parsing in Javascript is not very efficient or simple.

Tom

Last iteration was by the very talented samanbb!

Very cool, this does a great job of highlighting where we need to focus outreach. Thanks for doing this.

As butrus_butrus said, this isn’t a very reasonable solution - my account was idle for more than two years, and now I’m rather deeply involved in OSM.

If the problem you’re trying to fix is misleading ‘users numbers’, the solution is to publish ‘active users’ numbers alongside.

There’s also the hosted demo version which updates every 10 minutes if you want to test without having to clone/view locally!