tmcw has commented on the following diary entries
|The diversity-talk list||7 days ago||
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.
|COFFEEDEX & the single-tag revolution||15 days ago||
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 :)
|We can no longer go on like this||20 days ago||
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.
|Being a newbie||20 days ago||
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.
|COFFEEDEX & the single-tag revolution||21 days ago||
Did "wanting to contribute to OpenStreetmap" not come to mind?
|COFFEEDEX & the single-tag revolution||21 days ago||
Good question - this has already been addressed in the FAQ, but up for debate if someone sees a way to make it clearer:
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.
|A year with imagery offset database||6 months ago||
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.
|New users shouldn't be allowed to delete a lot of data||8 months ago||
The answer is yes. Here's iD's implementation.
|GeoGit and GitHub Geo||about 1 year ago||
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.
|overpass turbo goes geojson.io – translators seeked||about 1 year ago||
Awesome! Nice work
|Guided Tagging by an interpreter of XML-formated rules||almost 2 years ago||
From the iD side:
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.
|New Look||almost 2 years ago||
Last iteration was by the very talented samanbb!
|Animated dataviz of OpenStreetMap edits per year||almost 2 years ago||
Very cool, this does a great job of highlighting where we need to focus outreach. Thanks for doing this.
|1 Million Mappers Soon ... No, Not Really||about 2 years ago||
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.
|Test driving iD||about 2 years ago||
There's also the hosted demo version which updates every 10 minutes if you want to test without having to clone/view locally!