Hey Paul, thanks for posting. Are you asking because you’re curious, or because you’re trying to communicate to me that permission from the board is required for doing board-related work on paid time? I have permission and support from my employer to participate in the board, and I intend to follow any conflict of interest rules that apply.

Thanks for this feedback, Frederick!

Pure separation of personal, community, and participant goals is not in OSM’s best interests: the map has always had a job to do in the world beyond just existing and commercial use is a part of that. I’d like to see a future more like that of Linux: a healthy, stable organization and a range of diverse participants acting in concert without privileging narrow forms of participation over others. I imagine this is also important to you as an owner of a company similarly reliant on OpenStreetMap data.

You linked to my Talk@ post but I’ll mention it again: I’ve set up a short series of open office hours in a wide range of time zones to answer any community questions that might come up. There are three left: tomorrow, Sunday, and Tuesday. So far I’ve had one very excellent and wide-ranging conversation about communication venues in OSM which reminded me that forum.openstreetmap.org exists as an interesting potential place for the OSMF board to make itself available for community feedback and conversation. Since you’re still a prominent member of the board, would you be open to using some of your remaining time to make communications channels between leadership and the community more explicit?

Hey Ben, thanks for this detailed response to my post!

I’ll just write a few words because I’m about to get on a plane. I think you’re pretty close to the point I am hoping to convey, but maybe coming at it from a different angle? I don’t believe OSM is irrelevant now (as evidenced by attendance at conferences like SOTM and the interest of the robot and crisis communities), but I think its leadership and the Foundation are stuck in a holding pattern that I trace back through the history of the project. Briefly, because the OSMF has been unable to adapt to the emerging needs of new members which I connect to CoC’s and improved license communication, those new members find reasons to limit their involvement in OSM and ultimately hesitate to buy in.

Money and all that it represents is a shorthand for this. The companies and consortiums who could conceivably provide this money find OSM unapproachable for the reasons I’ve described, and so they either get lightly involved or steer clear entirely. I’ve spoken about OSM with numerous people from large businesses and funding organizations who either muse about creating their own less-hostile alternatives, or dip their toes in tentatively before drawing them back. OSM’s unwillingness to open the door to participation on unfamiliar terms blocks the project from access to the kinds of funding you describe.

I understand that a number of people have taken offense at the term “craft”, and I am also aware that I’m making a disprovable prediction regarding project doom. I think it has been necessary to shake the tree enough to flush these topics into the open.

Also, BushmanK, I’d love to hear more about the proven fact that HOT involvement has not succeeded in sustaining the map!

It’s a less important point, but the XML output uses seven digits of precision after the decimal point, and for data sets like land use it might be more appropriate to use 3-4. Less important, though.

One interesting outcome will be to gauge the suitability of the OSM tool chain for data at a different scale, like forest outlines vs. roads. How many of the tools assume street-scale in all things, and enforce that in minimum zoom levels for editing (iD) or high-precision data output (planet XML)?

On further thought, it's probably worth noting that Mapnik's processing pipeline, the way that styles must be specified before geometry is passed through, is a major constraint here. I could imagine a future modification to Mapnik where it behaves more like HTML + CSS and applies the rules in-flight as they are needed, and removes the need to prepare all possible combinations. I expect this is many versions off, though.

Hi asciiphil,

Cascadenik is my project, thanks for your comments. The combinatorial explosion issue is very much something I've run into when developing stylesheets, and like you I've found myself pushing a lot of logic in SQL to fix the problem. Here, for example, is a SELECT statement from one recent project: http://dpaste.com/hold/190143/

The "is_tunnel" and "is_bridge" parts help handle the various different ways of saying "yes", and the "kind" result column groups together many different types of roads. There's also a subselect in there you might have noticed: it groups the lines from each layer into single MULTILINE geometries, which helps deal with certain casing issues. Ultimately this is the way I've made stylesheets workable for myself - keep the ability to separate line casings and widths and colors and zoom levels, and use the expressiveness of SQL to munge the planet database into something more directly applicable to rendering. I know that Cloudmade have done similar things, including I believe downsampling the detail level of the road vectors for certain rendered zoom levels.