lxbarth has commented on the following diary entries
Post | When | Comment |
---|---|---|
The trouble with the ODbL - summarized | over 3 years ago | Imagico:
2, 4, 5 are clearly issues of the ODbL. 6 is an exacerbating factor when having a high maintenance license. True, could be an issue for other (open) licenses too.
This is a rather technical argument. Sure, some of the issues in the ODbL go back to the European Database directive.
NASA is placing OSM labels on top of their imagery which is a very straight forward use case even under the ODbL. NPS would like to maintain some of their data as part of OSM, which makes share alike a show stopper.
Exactly the point of the paper. The ODbL is so complex that we're losing people based on misconceptions. If you were a lawyer and magically gave away free, concise and fast legal advice every time such questions crop up, the penalty we're paying for the complexity of such a license would be smaller.
See above. It doesn't matter whether the concerns are actually valid. It matters whether people have them and they do. Every week I hear of legal departments saying no to OpenStreetMap because of its license.
I'm very grateful for the LWG's work and I agree with you which is why I am hoping to get to a clarification on geocoding https://lists.openstreetmap.org/pipermail/legal-talk/2014-October/008003.html ==== giggls:
We talked about this on Twitter https://twitter.com/lxbarth/status/527121888024465408 . I don't want anyone to dismiss the points of the paper based on who I work for. Please go get in touch with every one of the captured case studies and make yourself a picture. ==== Cquest:
The ODbL just doesn't have any issues except where it has issues ;-) ====
This implies that share alike has a benefit for contributors which no-one has been able to explain to me. ==== mcld:
Fair. The paper itself uses more nuanced language, namely that the definition of what's Substantial by the OSMF guidelines is far off from what's case law so far. |
Importing 1 million New York City buildings and addresses | over 3 years ago |
It's not. Feel free to lift it :) |
Importing 1 million New York City buildings and addresses | over 3 years ago |
@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. |
San Francisco building footprint data completed | almost 4 years ago |
All done by hand.
Take a look here: https://github.com/Rub21/osm_visualization |
Connecting Communities With Improved OpenStreetMap Credits on Mapbox Maps | almost 4 years ago | 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/ |
Connecting Communities With Improved OpenStreetMap Credits on Mapbox Maps | almost 4 years ago | Rasher - let me reach out. |
Attributing OpenStreetMap | almost 4 years ago | 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. |
First steps in historical OSM analysis | almost 4 years ago | Joost - very interested in the results. All pages linked from your OP 404: |
OpenStreetMap and the Open Data Movement | almost 4 years ago |
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. |
OpenStreetMap and the Open Data Movement | almost 4 years ago | 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. |
Attributing OpenStreetMap | almost 4 years ago | Willie - I'm working on this with the Foursquare team right now. |
High res DigitalGlobe imagery open for tracing through Mapbox Satellite | about 4 years ago | 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? |
You can't do this with any other map but OpenStreetMap | about 4 years ago | Yup, love that post, mikel. |
OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike | about 4 years ago | 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:
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:
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. |
DC Street Names | about 4 years ago |
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? |
Fixing Tiger Deserts : The Progress So Far ... | about 4 years ago | 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. |
I didn't know I worked for Mapbox | over 4 years ago | Hey Pieren -
Of course you're not. You're improving everybody's map data ;-) Just clarified that line, no offense intended. |
First buildings and addresses in New York City | over 4 years ago | Hey there - you can easily install your own tasking manager from here https://github.com/hotosm/osm-tasking-manager |
A Social OpenStreetMap.org Without Groups | over 4 years ago | Mikel:
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. |
A Social OpenStreetMap.org Without Groups | over 4 years ago | 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:
With this in mind I took another look at the groups PR. Specifically, here's what I like about it:
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:
This move, while technically a fairly small change, would bring significant improvements:
Thoughts? |