Is the part of convert.py dealing with T-intersections available somewhere as a standalone program? It would be useful in many other situations!

It's not. Feel free to lift it :)

Now that we've got it imported, when will NYC be releasing new data, and how will we handle updating it?

@pnorman - we're still focused on clean up tasks, but with the next significant building or address import we should run a diff against OSM data and see whether there are worthwhile updates to go after. How exactly that's handled best I think depends a lot on the quality and the quantity of the specific changes.

Did you use any (semi)automatic tools for extracting the buildings?

All done by hand.

How have you doing the map animation? It's really cool

Take a look here: https://github.com/Rub21/osm_visualization

Phase one of the changes I described above are rolled out now with Mapbox.js 1.6.3. What's missing now is updating our infrastructure to link attribution differently and switching maps directly viewed on Mapbox.com over to the new Mapbox.js. https://www.mapbox.com/blog/mapboxjs-v163/

Rasher - let me reach out.

Thanks for comments everyone. I've posted updates here: http://www.openstreetmap.org/user/lxbarth/diary/21847

Re: "improve this map" in German - good point, take a look at this code sample, it's easy to change the language in the attribution: http://bl.ocks.org/lxbarth/9490377

I will ping the Zeit Online team.

Joost - very interested in the results. All pages linked from your OP 404:

Hasn't the ultimate form of collaboration with government already been invented?

We pay them for their work.

And we'll probably continue to do that ;-) but we can make their work more efficient and we can make citizen input more direct - especially when it comes to base level geo data. So much of how geodata is managed today is simply an inefficiency of old non-digital systems.

There's a very interesting convergence between government open data and OpenStreetMap - this is where government and citizens start to collaborate around common datasets. While the open data movement right now is very much about opening up hitherto closed datasets, its ultimate goal should be to allow citizens direct input to government datasets where possible. OpenStreetMap is one of the closest models for future citizen-government collaboration we have today.

OpenStreetMap has a lot of what it takes to be such a collaboration space even today. Exploring this question better is one of the goals we're pursuing in working with the New York City government's building footprint and address data in OpenStreetMap.

Willie - I'm working on this with the Foursquare team right now.

Naoliv - when you change to tms[17] you won't be able to use ZL's 18 and 19 where it's available. This is unfortunately a limitation of how JOSM or iD handles imagery right now. What's the area where you are missing resolution?

Yup, love that post, mikel.

As has been pointed out at least by Frederik and Tim, I am stoking a conversation we have had before. So what has changed that should make it worthwhile to rehash arguments that seem we've already had? After all this conversation isn't always fun ;-)

Here's why I see dropping share-alike becoming more and more important for OpenStreetMap:

1. There is more open data coming online by the day and we are not compatible. Especially when it comes to the type of data OpenStreetMap captures. The proliferation of non-share alike open data sources makes OpenStreetMap the open data oddball that isn't compatible. We're the selfish player importing from all kinds of open data sources while we're limited in giving back, creating zero incentives for open data set holders to engage with OpenStreetMap (the NYC gov example).
2. The world is doing more stuff with raw data. There is a growing data economy of businesses, non profits and governments exchanging data in raw formats - for money or other benefits (the Wheelmap example and the Wikipedia example)

These are trends that have been gaining momentum in the past five years and I expect them to expand. OpenStreetMap's share alike license limits our participation here. We're a silo.

This conversation is also not a rehash of the GPL versus BSD argument of the software world. OpenStreetMap's problem is that share-alike's diminishing effect on utility is more severe for data than for software. Data isn't code. In many ways, data is the application. Data in its raw form has utility in and itself. This is very different from software. It is impossible to use an emacs editor in ways that extend its GPL license to the work I create with it. Yet with OpenStreetMap data the equivalent is possible. While as Simon said, the ODbL's share alike stipulations are limited to modifications, they do very clearly exclude important use cases and they come at the price of huge complexity.

Let me restate my examples from above clearer of what specifically is not possible or unclear under the current OpenStreetMap license:

• If the NYC government wanted to copy buildings that have changed from OpenStreetMap to the NYC building dataset they couldn't as their data needs to remain in the public domain.
• If Wheelmap wanted to offer wheelchair accessibility attributes it collects in OpenStreetMap to commercial data providers this a) severely questions on whether this would lead to existing POIs infected by share-alike (Simon's narrow interpretation of the ODbL might offer a solution here, but is by no means clear from the license text itself) and b) while the commercial data provider could create maps from the composite dataset, it would be impossible to relicense this data to others.
• Similar limitations exist for Wikipedia using OpenStreetMap data. As it stands, Wikipedia can only copy OpenStreetMap data where it is able to guarantee to make it available under the ODbL, cleanly separated from all other content available under different licenses (o the irony that OpenStreetMap gets to use simple facts off of Wikipedia as CC-BY-SA 3.0 is not effective on data).

In the light of a growing raw data space I am seeing these examples not as fringe cases but as a vanguard of future use cases that we should support as OpenStreetMap in a straightforward and unambiguous way. We'll want to support these use cases just like we want to allow everyone to create their own tiles from OpenStreetMap data without worrying about the license. I just don't see how we'll do this with the ODbL.

I am clear that while dropping share-alike would be a huge leap in the right direction, it might not be possible to solve all compatibility problems with a single license. What matters is taking steps forward. In this context, I do like the idea that SK53 brought up of special data sharing agreements with particular partners. What if the OSMF could grant the NYC government permission to extract any building and address data at no licensing restriction, essentially compatible with New York City's Local Law 11 of 2012?

OpenStreetMap's license is a strategic decision taken by the community, and we shouldn't take it lightly. More than anything, with this blog post I want to send a signal to anyone trying to do something today with OpenStreetMap that is not possible under the current license, to bring it up and explain their situation. I want to encourage everyone to not think about the OpenStreetMap license as something's that is set in stone. There is a mechanism to change the license and there are also good reasons why we should be open to do so. Participate in OpenStreetMap and say what you need it to be. OpenStreetMap's license does matter, even if our graphs look good. While they point to the top and to the right like Steve said they are not exponential with the exception of user registrations and shutting out applications of OpenStreetMap data does mean shutting out incentives to contribute.

Now to the flip side of the coin: the supposed protective function of share-alike. As opponents and proponents of share-alike have stated, the actual power of OpenStreetMap is its community. Today's data isn't worth a thing, the real power of OpenStreetMap comes in being able to create the map of tomorrow. If you're taking OpenStreetMap's data, close it and have your own paid army of surveyors, street view cars and digitizers maintain it, you've not hurt the project but made an incredibly dumb business decision: You couldn't do this without cutting the dataset off its stream of updates and thus the most valuable part of OpenStreetMap - the community.

Similarly, OpenStreetMap doesn't have to fear a thing from better contribution tools that somehow would entice a significant part of the OpenStreetMap community to defect to a closed source "enemy". In the end only an open data project with direct access to raw data can provide the basis on which a communal effort like OpenStreetMap can flourish.

What's more, in contrast to even large scale software projects, OpenStreetMap's community has a particularly strong position as mapping the world is a task of huge inertia and growing a community around this is an organic, slow process.

Let me also talk about my motivation for starting this conversation as some have questioned the integrity of my argument. I work at Mapbox where one of our key products, Mapbox Streets is based on the awesome OpenStreetMap. As company and individuals we've been involved in OpenStreetMap as mappers, designers and developers for years contributing or improving key projects like Mapnik, Carto CSS, the iD editor, most recently Leaflet.js and more. None of which based on the need to comply with a license, but because of individuals' passions and an understanding that in an open source project like OpenStreetMap, contributing yields huge positive externalities that help us as a business. We have a deep open source culture at Mapbox and that's not just because we may or may not be nice people, it's because it makes business sense.

Merely looking at our products, Mapbox is just fine with OpenStreetMap's license as-is, also in our days now as a venture backed company since October last year. We can cover the applications we're offering or planning to build out all under the ODbL. We're fine precisely because we're not competing on data, we're competing on the services on top of it, the legos we build for others to create location based applications. There is zero gain for us in owning data, it's a commodity and it is most efficiently managed in true open source commons like OpenStreetMap. Just look at how "well" some of the commercial data providers are doing.

Now would a better OpenStreetMap with more possible applications and thus better incentives to contribute and grow community and data benefit Mapbox? Of course it would. But wouldn't this also benefit everyone else involved, isn't this exactly what we have in common? The interest for OpenStreetMap to grow, to be successful and to matter?

It seems that this has been the understanding in the OpenStreetMap community all along. The past license change is a case in point. I am not proposing a change of course, I am pointing out that share alike is becoming an impediment to the project while it affords no particular benefit.

A much bigger effort is needed. I will continue to work on some of these issue.

David - how do you see this effort structured? Would rendering a map from current OCTO data and then trace from it be a good idea? Should we dump all street names of DC and compare them to a dump of street names in OCTO data? Is just using the TIGER 2012 layer a good approach?

Great summary. I wanted to highlight that the TIGER tracing layer Eric Fischer blogged about on Mapbox.com and that you mentioned here is highly actionable and available in OSM's iD editor plus you can add it to JOSM as described in the blog post.

Hey Pieren -

I'm not improving the Mapbox map data, the "your" map data

Of course you're not. You're improving everybody's map data ;-)

Just clarified that line, no offense intended.

https://www.mapbox.com/about/maps/

Hey there - you can easily install your own tasking manager from here https://github.com/hotosm/osm-tasking-manager

Mikel:

So in summary, I think good and well linked notifications management is a good idea. But there's really no significant technical changes, because if you posted to a group, you should also definitely be subscribed in some way.

Not quite. On a technical level I'm proposing to allow posting to a group (topic) that you're not subscribed to and to not automatically subscribe someone to a group (topic) that he/she posted to.

I do think we should automatically subscribe people to comments on entries they wrote and comments on entries they commented on (very similar to how it works today). There should always be an opt-out obviously.

Thanks for taking time to respond everyone. I really appreciate it.

My point here was less about no social on OSM, but about the merit of groups specifically. I think that was by and large clear but I wanted to reiterate this.

Now, this argument here from Richard is compelling to me and I'm starting to understand what we're really missing on OSM:

I see your point, Alex, that "today OpenStreetMap enthusiasts gather in spaces on mailing lists, Meetup.com, Twitter, Facebook, forums, and Google Groups"... but honestly, I don't think they do. Not over here, anyway. Super-connected guys in metropolitan areas are doing so, I guess, but that fixes London and NYC and SF - not the rest of the world.

With this in mind I took another look at the groups PR. Specifically, here's what I like about it:

1. Groups expand on Diaries
2. You can comment on a post in a group you're not member of

However, I still need to join a group in order to be able to post a new post to that group, I assume also email notifications will be tied to group membership. Could this be more open? Also: we'll likely wind up where we'll want to offer opt out email notifications of groups for the ones who read online.

I'd like to suggest a small modification to the group concept that I think makes the approach tighter:

• Do away with joining groups.
• Call groups 'topics'. Once there's no joining, the 'group' branding is misleading.
• Introduce an email notifications management page that allows for opt-in emails. Make this look great and prominent: "Subscribe to topics you're interested in".

This move, while technically a fairly small change, would bring significant improvements:

• allow us to conceptually tie what's called groups right now even tighter to diary entries
• not have a group join page and a notifications management page
• emphasize topics over people, "groups" rings always a bit exclusive "what makes me a worthy 'member'?"

Thoughts?

Thank you for taking your time to write this up:

My biggest confusion at first was that my edits didn't show up right away, and the interface provided no hint about why that was happening (so I wondered if I was doing something wrong).

https://github.com/systemed/iD/issues/1660

Any specific POI's you couldn't find in iD that make you switch back to Potlatch? iD is the intended successor to Potlatch so any suggestions to improve iD are more than welcome. Feel free to file requests directly to the GitHub repository for iD: https://github.com/systemed/iD/issues