[OSM-dev] Hello World

[Michal Migurski]

Hi everyone,

I've been following the OSM Wishlist thread via the list archives on the web and thought I'd pop in to join the discussion. I feel of two minds about the suggestion: on the one hand, I'm thrilled to see energy from Tom, Alex and the Mapbox team. On the other, I feel like the OSM community is about to experience a full-court press and needs to build up some structure to match. I'm excited to see what Mapbox comes up with hear, but I think it would be a misuse of the Knight grant to develop a bucket of tools without the admin time to support their long-term use.

My wishlist:

* Create a new map style intended to be the default face of OSM, but leave the current OSM.org Mapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at.

* Improved relation + data model support in a editors, either a new one or a retrofit onto Potlatch. Things like route relations or addressing schemas are important, for example, and should see the same kind of first-class support in an editor that the primary/secondary/etc. road schema does. It's time for these higher-order features to come out of the lab.

* Better time-awareness in planet dumps. I want to see a "days since last edit" or similar attribute on all entities in the planet file, which will make it possible to create downstream displays and styles that address hot, contentious information. We're starting to see two tiers of OSM data consumers, those who want the latest-newness and those who want to treat OSM like a slower-moving data source.

* Social OSM: feh, don't care.

Stepping back, the story of OSM *is* that things happen in other tools, so I'm in agreement with Paweł Paprota that Mapbox should "build something that needs JSON support, filtering and tag API" before those features get fed into the core infrastructure. The minute diffs support the ability to develop real, working systems in an offboard manner, and I think we should take advantage of that.

I'm also in agreement with Tom Hughes on the issue of bug trackers: "issue trackers that are acquiring things at a faster rate than things are being closed have an unfortunate effect," sapping energy through administrative overhead. I use Trac and Github for issue tracking on sparingly, when issues have a clear boundary and release target.

-mike.

----------------------------------------------------------------
michal migurski- mike at stamen.com
                 415.558.1610