mikelmaron has commented on the following diary entries

Post When Comment
HOT Voting Member Nomination 11 days ago

Love the focus on validation ... there are connections to HOT's documentation, activation protocol, and technical developments.

Missing Maps Workshop at Mapbox-BLR 19 days ago

Great wisdom Maning!

Some things we put together over the last year on organizing an event, from MapGive

OSM-PH tagging suggestion about 1 month ago

Just seeing this now @maning and it is awesome. I don't think I've seen anything like this before, except in my mind after too much mapping! Super useful perspective, illustrates the process of observation and data creation in the real world.

How we apply map feedback 8 months ago

There should be and are many levels to contribute to OSM, so this is a good concept, and thanks for the transparency. To pull out a productive idea, offering a path to users giving feedback (and notes), to get more involved in OSM, is a useful idea.

HOT 2014 Review 11 months ago

Thanks for your sharing this Sam. I encourage you to open your ears a bit more to what's happening in HOT community and organizationally the last six months. You're already doing this a bit, since you answered the call to document HOT activities in 2014. I see things as substantially improved. Eager to hear more ideas on how we all can be more constructive, together.

Vision? about 1 year ago

Non-editable requests from HOT? You must be confused. Reference please.

Moabi at State of the Map US about 1 year ago

@butrus_butrus: Some data might be appropriate for sharing in OSM, or even being based in OSM. No specific plans at the moment, but something we are continually looking at.

Moabi at State of the Map US over 1 year ago

Yes, definitely maning. We're gearing up for that, will let you know.

You can't do this with any other map but OpenStreetMap over 1 year ago

Thanks @lxbarth. I like the idea of highlighting what you can only do with OpenStreetMap, we should collect these. Here's a few more:

Is the OpenStreetMap Rails App Appropriate for Other Data Sets? over 1 year ago

@nfgusedautoparts: they may work. but since our use is outside of properly, we have more latitude in implementing new features.

OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike over 1 year 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 about 2 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 about 2 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 2 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 2 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 2 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 2 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 2 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 2 years ago

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

UN Collaborates on Zaatari Camp Data in OSM about 2 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?