There’s long been a desire & incoming wish for iD to be modular. Modular is a pretty general term, so I’ll narrow it down into three general goals:

1. Modules as a way of building a system. Using rollup, browserify, etc., in order to structure code and separate internal components in a nice, predictable way.
2. Modules as a way of letting other systems include yours. Generally, in JavaScript-land, means publishing to npm.
3. Modules as ways to include new code in your project. This is more in the vein of iD plugins. Supporting plugins would let us support contentious or rare needs without bikeshedding their inclusion to the main project.

With the help of Bryan, Kushan, David, Beau and Martin, we’ve made significant progress toward the first goal and are nearly at the finish line. iD will be switching from a system where we concatenate source files and use GNU make as a build process - to one that uses rollupjs to build a bundle from JavaScript modules. The expected benefits are big, for maintainers:

• iD no longer relies on the global namespace for dependencies like d3, so there’s less chance for conflict.
• misnamed requires or invalid requires will be caught early
• we can use npm modules for our dependencies, rather than keeping them in the project’s source tree
• we’ll be able to build a faster and more reliable environment for development
• we’re upgrading d3 to v4, keeping it in line with the changing software world.

This doesn’t immediately win us (2) and (3) but it pulls them closer. Soon, a new editor could reuse iD’s data model, and iD could load new functionality from a plugin.

And there likely won’t be any user-facing change as part of this port. This is the stage where the developers throw tens of hours into the low-level guts so that plugins can be possible and long-term maintenance can be less painful.

Bryan and I are working on the final steps of this modularization. I’ll take some time to land: this is a major refactoring of a large project with a lot of functionality, so it involves a huge amount of work and has many opportunities to introduce regressions. We ask for your patience and/or support during this time.

Once we’ve ensured that the refactored iD is just as good, then it’ll be the future, and we’ll be excited to keep moving toward a more interchangeable stack of tools for OSM.

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?
• PBRDEX
• Bridge height entries
• Opening-hours-only editor

COFFEEDEX.

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!

iD alpha3 just got released - huge work by ansis, saman, and jfire.

Try it out!

New post by John Firebaugh on the MapBox OSM Dev blog!

A new post on the MapBox OSM Dev blog about iD’s data architecture, by John!

A new update from the iD osm editor project (earlier updates here) - Ansis Brahmmanis implemented labeling in Javascript with RTree and d3 and wrote about the technique. It’s quite a feat, and a bit improvement in iD’s usability from alpha1 to alpha2.

Some updates from the iD project:

• iD on PBS MediaShift Lab
• iD’s OAuth implementation
• Some love for Taginfo

We’re nearing an alpha1 release with many bugfixes and improvements!

I’ve been working on the iD editor: here are the notes so far:

• First steps
• iD updates
• SVG tweaks

Thanks to Stu Hamilton and the Center for Geospatial Analysis at The College of William and Mary (my proud alma mater), I've been able to really build out the maps in the Williamsburg area and especially regarding W&M itself. There's still more to come, dependent on transforming some polygon data to lines and making a few more imports.

It was a long, long upload but it appears that all of the Africover-provided data for the Democratic Republic of Congo is uploaded to OSM and is just waiting to be rendered in all its glory. This dataset should be a really huge improvement for the country - the .osm file is 45MB.