mikelmaron has commented on the following diary entries

Post When Comment
OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike over 2 years ago

"require time, good lawyers and programmers" ... that's key to me. Where to invest our time and effort to reach OSM's best potential.

I agree with a lot of the intention @lxbarth lines up, especially making it easier for governments that have made Open Data open to benefit in kind.

But as we can see from the discussion kicked off here, there's not really anything with more opinions in OSM than the license. Moving from cc-by-sa to ODbL was a lengthy, frankly painful, process, and while we learned a lot, I unfortunately couldn't say that any further license change wouldn't take just as long, or longer. Is this a place to invest time again?

Yet, I think we may be able to get a long way with the ODbL. I think it at least worthwhile to share more details on possible legal interpretations. I remember at SotM-US last year, a productive BoF about licensing. Seemed to me like one question, geocoding into 3rd party databases, seemed close to a workable and widely supported realization. There was a lawyer who was interested and seemed to have some ideas about how it could work.

I know lawyers aren't really able to share opinions into the commons themselves, just to their clients. I wonder how we could build up a more collaborative, commons of solid interpretations of the ODbL, which would be clear, and make it easier to answer questions without IANAL. This seems doable to me, but I'm not sure how.

Likewise with the workarounds of using OSM in various. Which while not ideal, I think are also solvable. Can we build up a collection of guidance and recipes by people have built real projects using OSM data in license compatible ways?

A Social Without Groups almost 3 years ago


Just came back here after some time, this post was referenced on another thread. And see, there's some replies. Wish I had a notification!

Alex: Sure, that kind of flexibility on posting permissions/subscription/joining make sense to me. This is how github works, and works well. But earlier you said "Do away with joining groups.", and I disagree. You should be able to join a group, be listed as interested, and tailor your notifications (email or not for all posts, or just in your "news feed").

Tom: That's absolutely what I have in mind, to make all the plethora of OSM activity and tools tailored and convenient to that place/topic. Afaik, hasn't been approached yet in the groups code. Question on my mind is how to make integration of other tools flexible enough, but not too bespoke. What's the easiest way to get started on this?

Now, I think we're close to common ground. Good moment to boil down the discussion here, and pull out the agreed points into design guidance and issues on the groups tree, and do a coding push to get these features out into the wild.

UN Collaborates on Zaatari Camp Data in OSM almost 3 years ago

Update, on October 3, UNOSAT released a new analysis. The officially released Shapefile version did not contain the objectid, so asked for another extract, posted at Had to adjust the conflation script slightly for changes in columns. Ran without issue, except for one warning "ERROR Deleted feature missing in past import: 63911". This feature was both detected and deleted on the same day. Otherwise, all stats match up with reported changes from UNOSAT. Import is here

There's some concern about the tags, unosat:acquisition_date, unosat:event_code and unosat:objectid, to be discussed on imports list.

GeoGit and GitHub Geo about 3 years ago

@tmcw: separate from the implementation (and I understand your misgivings) curious your thoughts about concept of versioning a graph database, structured as some kind of "OSM JSON". I don't see why topological data couldn't fit in a Git model, with additional checks for consistency when features refer to each other. It's not Git's responsibility to ensure your code compiles, nor would it be data consistency.

A Social Without Groups about 3 years ago

Ok, interesting thoughts. Resonates with what @migurski hacked on before the Birthday Sprint, gathering of changesets by hashtag. Overall, seems like we're just disagreeing on what these features are called, not the features themselves.

In my mind, social features, whatever you call them, gather relevant OSM "objects" together in one place, like diary entries and changesets, and also most definitely mappers. Whether you call it "subscribe" or "join", "group" or "topic" is only a semantic matter. In any case you do want to see a listing of users who had opt-ed in / contributed to what or where you are interested. Functionally, I don't only want (selective) emails, but also a summarized listing of activity on, in everything I'm interested in.

Now, places are where this concept gets interesting, and challenging. How is a place defined? It needs to be pretty intentional. By contributing to that place, by editing there, does not mean you have necessarily joined the place? No. We need to see some notion of intentionality and commitment.

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. You're suggesting some semantic changes (which might be ok, would be curious to hear others thoughts), and perhaps interaction changes (once you post, you have joined), but no changes to the underlying Model.

GeoGit and GitHub Geo about 3 years ago

@robert, good point about number of users ... can you really have a single Git/GitHub project with 100k contributors? Or a single project with pull requests from 100k forks? Yea, probably not. But that's not the structure I would expect to see develop. I'd expect to see a bounded number of forks emerge, with admin level merges, and individual users working as collaborators within a repository.

For an individual user, they'd rarely encounter a merge. How often do we encounter edit conflicts in OSM? More than we want clearly! Thankfully rare. It's not something our tools handle well at all (or any tools really).

So yea, essentially, I would think that the emergent structure wouldn't necessarily increase the number of merges over what we have to deal with now.

A Social Without Groups about 3 years ago

Alex, I guess you won't be surprised I disagree, and sorry, I'm going to respond strongly.

I don't disagree with some of the points you've made, some of which are wise, but with the overall thrust and timing of the argument, which I just don't understand. You're trying to inject stop energy into something that people are excited and interested to work on; active work and discussion which really started up again at SOTM US, but during which you chose to remain silent with your opinions. While you now have a couple practical suggestions, you are not personally or as a team working to provide solutions to issues. Worth remembering that MapBox's priorities are not necessarily OSM's priorities, and just because you guys evidently don't have bandwidth to get involved now, doesn't mean it can't be done well.

Your first points are totally contradictory. You say that groups are not necessary for discussion, but then say they are happening all over, but they are also never done right (explored in this post on finding communities). Fact is, mappers organize using lots of groups, but as a newcomer or even oldtimer, it's still too hard to reach other mappers in an area. Groups generally seem to work, they don't all suck ... why not contribute some ideas on what makes other groups work well? Or review the work done so far, and offer specific recommendations on the sketch?

A couple things to consider of which you may not be aware. Place based groups are not implemented yet, and this is what I imagine is the primary mode of groups organizing, and monitoring activity. It's straightforward to sort groups based on level of activity, to bring out the ones worth connecting on (certainly you've been able to judge the vibrancy of a github project based on its activity level). Groups shouldn't replace other means of organizing necessarily, but groups should be encouraged to gather a list of resources of importance to that group (including key mailing lists, facebook groups, wiki projects, etc).

Honestly, it would be more helpful if you created some issues or pull requests on github for those usability points for the current OSM features (some of which are quite easy and not controversial), and explain a practical solution for some of the trickier ones (how do you make it easier to see who's mapping in an area)?

Local Chapters v2.0 - A standardised starting point for new contributors about 3 years ago


Great thinking, I've been exploring some of these questions too ... was the topic of my SOTM US talk

and this blog post

We have started implementing a few of the ideas around Groups in It's actually not too far off.

Finally, Local Chapters group is due to restart with a call in 1 weeks time. I expect the focus will be more legal, as you say.

Quality Assurance Feeds about 3 years ago

Handy! Can imagine this being straightforward to integrate into too.

UN Collaborates on Zaatari Camp Data in OSM about 3 years ago

Some feedback and suggestions from taking a look at all our data-work together in the map.


The flexibility of tags are what make OSM work, when you don't find a representation existing, you're free to make your own. Then over time, others start mapping similar things, and eventually make connections, and then work towards consensus. I think we're seeing a lot of that here in Zaatari, with work from other humanitarian mapping, mapping informal settlements, and general work in OSM. So that's my first point, to look at tags, and see if we can broaden the discussion into new community consensus if needed, and do some clean up on the Zaatari data.

For example, toilets have been getting a look by the general OSM community; HOT has worked on mapping humanitarian attributes; and Map Kibera did a lot of work on different toilet types.

For a toilet like, I'd suggest adding a new value to "toilets:disposal", instead of new tag "latrine_type"; and then use "disused", rather than "status", only when there's a problem with the facility. Also, for "source", if you use a new value, good idea to document it here:

For a water point like, "type" is typically already used as part of relations, and doesn't specifically deal with water points; might have "tank_type", split up into, and keys in the "watsan:" namespace or such to capture the kind of tank and volume.

Also, for the kitchens, they're tagged as "drinking_water", but since the primary function is kitchen, we might just consider using a new tag "amenity=kitchen" (you don't find commons kitchens many places.

Anyway, could go on and on about tags. There's certainly a lot to figure out.

Linking data

With multiple sources of data, we're starting to (I think) see the same things represented twice. This structure from UNOSAT, and this kitchen from UNHCR are very near each other, and I guess the same. We could catch more of these through analysis. I wonder, how can we design a process to catch these, and merge features during imports and updates.

Similarly, is tagged as a shelter, but right near a water point and toilet ... is this perhaps actually an administrative structure?

Skill Share: Map Photos Using OpenStreetMap and TileMill about 3 years ago

@stephan75 I've incorporated your suggestion to use templates, and mentioned TagInfo.

Skill Share: Map Photos Using OpenStreetMap and TileMill about 3 years ago

Hi, I just updated the tutorial to include the GeoJSON Flickr Groomer, No longer necessary to store preview images as tags in OSM.

@dieterdreist: indeed, this can work with other photo image sharing sites. It would be cool to incorporate as well ... what will it take to add support to, in terms of the 23hq API?

Skill Share: Map Photos Using OpenStreetMap and TileMill about 3 years ago

@stephan75 nice! I will look to incorporate this when I revise. One issue though ... when loading layers in TileMill, each layer can only contain one geometry type, so the key template doesn't work. The key-type template does, so could construct something like

and mention this one, in case they want to branch off into other geometries.

New contributor experience about 3 years ago

Great notes on the new experience. I think that feedback about tile rendering delay should be noted in the iD walkthrough, or on commit (at least the first couple times). And lots of other useful ideas. Welcome to OSM!

Is the OpenStreetMap Rails App Appropriate for Other Data Sets? over 3 years ago

@JimmyRocks There probably won't be much that's useful for OSM, but perhaps. For certain data layers, we can choose the license, but other imports might be restricted by source.

Maybe I'm not too concerned about the data model, perhaps I'm just used to it. Certainly it will be weird for importers, who will want OGC standards I expect. Editing, well I think iD is one of the best out there for straightforward editing.

@migurski Good point. We could relax those zoom level restrictions in iD, dependent on the data layer being edited. What do you mean by "tools assume street-scale and enforce that in high-precision data output"?

If anything, I'm most concerned about defining some notion of layers in OSM, and in adding permissions.

Is the OpenStreetMap Rails App Appropriate for Other Data Sets? over 3 years ago

@ebwolf: Machine tags, a good idea. I'm also thinking it could help with attribute level focus/access; much of the enhanced data is not going to fit in standard tags, and can organize group focus around that. Definitely permissions/roles are going to be something to add, so that's something to investigate ... is it relatively straightforward to add to the current app, or is the notion of open so deep, that it would become a sink.

@wonderchook: I've been thinking a lot about enhancing the social functions directly in the rails app, we started hacking on it during the SOTM US sprint day. So possibly, this project provides some support to really advance on those features. Question is, how much of what's needed for Moabi is also needed for OSM.

The other platforms I'm thinking about are Cartaro and GeoNode. There you have GeoServer on the back end, and then Drupal or Django for presentation. Just GeoDjango might be good enough too, to start from. Interested to hear more opinions on other options definitely.

What a fantastic State of the Map US over 3 years ago

thanks Ian, Martijn. great to see you both too. and all this was only from my perspective!

(Not) Finding Communities over 3 years ago

Another nice way to keep track of changes

A new way of fast browsing of latest changes over 3 years ago

Nice! Seems obvious in retrospect.

Issue is that it only works efficiently at high zoom level, and that also varies depending on data density ... DC is having trouble loading at same zoom levels at Witchita. How do you design reasonable fall throughs to traditional history?

overpass turbo now with MapCSS support over 3 years ago

awesome. hey, when can we get a simple link from export tab to overpass turbo?