Recent diary entries
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:
- 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.
- 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.
- 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.
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!
Some updates from the iD project:
We're nearing an alpha1 release with many bugfixes and improvements!
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.