Recent diary entries
Mapper since: December 01, 2006. two more years and it'll be 10 years. I will probably forget, so congratulating myself in advance.
Greetings, this is a brief recap of my contributions to the Humanitarian OpenStreetMap Team (HOT) in 2014.
In February 2014 I was nominated and accepted as a Voting Member of HOT and in March I was elected as the Chairperson for the Voting Members.
At the end of March, as some of you well know, we began an Activation to assist Médecins Sans Frontières (MSF), aka Doctors Without Borders, with the Ebola crisis in West Africa, see https://wiki.openstreetmap.org/wiki/2014_West_Africa_Ebola_Response for details. I assisted the Activation Coordinators at the beginning of the Activation by updating that wiki page for about the first month, as well as completing a handful of mapping tasks. I also remotely contributed to the Map Lesotho Mapathon in July.
As Chairperson, my focus was less on the mapping, and more on the ‘behind-the-scenes’ operations of HOT. I attempted to assemble the Voting Members for an ‘annual meeting’ twice, but was unable to get a quorum (at the time a majority) of our members. This was obviously a problem and after many meetings and conversations it became fairly clear that with a worldwide membership, even meeting electronically, would be difficult.
So I shifted my efforts to helping re-ignite the HOT Working Groups, especially the Governance WG. Although I also participated in the Activation WG, Training WG, Community WG, Communication WG, and attended a few Technical WG meetings; I’m going to focus on the achievements of the Governance WG here. Our first priority was to address the issue(s) of assembling our membership to hold legitimate meetings in order to conduct business. We decided our best course of action would be to ease the quorum requirement; the alternative would have been to start removing members (which would have been an extremely difficult and much longer process). In order to do so, we needed to get a majority of members to assemble in order to ratify a change to the bylaws. So first, we drafted and proposed Proxy Rules which were approved by the Board of Directors to use for a Special Meeting of the Voting Members to adopt an amendment to our Bylaws changing the quorum to ¼ of our members – which the Gov WG also drafted.
This culminated in our first ever meeting of the Voting Members, on October 16th, where a majority of us were present or represented by a proxy; i.e. able to conduct business. The meeting was specific to ratifying the quorum clause of the Bylaws and that was approved. Although I had high hopes to accomplish more in my first year as Chair, I am pleased with the progress we made as this should make future meetings of the membership much easier to conduct. Now the Governance WG will set its sights on the (quickly) approaching new member nominations and HOT election cycle.
As a side note, I also had to address an issue with several members regarding how we speak to and respect each other and hope I brought enough of a resolution that no further disciplinary action is required. Also throughout the year I continued to support our OSM community in Mongolia, see http://hot.openstreetmap.org/projects/mongolia_mapping_ulaanbaatar for the backstory and spoke at the University of Colorado on the subject in February.
Chairperson for the Voting Members
I did a little writeup on what the NYC OSM community it up to.
I've been mapping for a while now. I have some issues with the way OSM currently works.
The current tagging/import approval process is silly. To get a new tag approved formally, you are supposed to post about it on tagging-l. Then you are supposed to write a wiki page, then have comments on the wiki page, then have an RfC on the wiki talk page, then announce the RfC on the mailing list. If someone says "yeah, I'm not wild about this idea", that's pretty much a blocker for it happening at all. The alternative to this process is to simply start putting tags on things when you edit them and create an informal convention. Because the former process is so ludicrously painful and slow, it is much easier to tell people who you meet who say "I'd really like to start putting X on OSM" to just go ahead and do it quietly without telling anyone, and then it probably won't be a problem.
The wiki doesn't match reality. The RfC process is so ludicrously over-complicated partly because nobody is sure whether the wiki exists to document existing behaviour or to specify what ought to be done. That is, nobody is sure if the wiki is descriptive or normative. It has thus ended up being both and neither.
There doesn't seem to be a process for ever tidying the wiki, and no feeling that we should ever bring discussions to an actual consensus. Over on Wikipedia, for all its faults, admins do at some point close discussions and say "here's the rough consensus: X". On OSM, the discussions just rumble on forever.
The culmination of this slow and silly process for approving proposed tags or imports is that now when friends come to me and say "I've got this really awesome idea for using OSM and we could contribute data back", I now say "yeah, good luck with that: the community process is so slow and bureaucratic, it often isn't worth bothering with". That's toxic. It's absolutely ghastly that smart, informed programmer types come to me and say "we've potentially got some amazing data we could contribute to OSM" and my answer is "that sounds awesome but the process is so broken that you shouldn't bother doing it officially, just do it quietly and unofficially".
There's some simple things we could do to fix this.
Close most mailing lists. Mailing lists suck. Over at microformats.org we eliminated all our mailing lists and just use a wiki instead. See wiki is better than email.
Get rid of most of the RfC process. It doesn't work.
Switch to a default of "let's allow things to happen, then fix them when they break" rather than the current "let's have long, pointless mailing list discussions and then say no".
Develop a process that is based around evidence collection. When I proposed the dress code feature, I provided comprehensive examples of different types of dress code that people were actually publishing on the web. The point is that when deciding on a new tag or feature proposal, we should be guided by the evidence of what people are already trying to express in other settings. The alternative process to this is called "making shit up out of whole cloth". It has a proud and noble tradition in standards-making. Alas, that tradition is also accompanied by a history of complete failure.
If we want enthusiastic contributors to work on making OSM fill all sorts of interesting and unpredictable new use cases, we should welcome those people in rather than keep around processes that are slow, bureaucratic and alienating.
COFFEEDEX is a thing I made to track coffee prices worldwide.
Late in the iD Editor sprint, I wrote osm-auth to make the OAuth dance easier for potential future editors, thinking that a lot of common editing tasks would require super-focused UIs. COFFEEDEX is more or less the first attempt at doing that: it edits a single tag on a single type of node,
amenity=cafe, and only on local nodes.
Does this bloat the database? My back of napkin math says that if we tagged all 150,000 cafes with 32 chars of
<tag k='coffee:price' v='$10' /> we'd end up with a grand total of 38.4MB of bloat, on a database that weighs 38GB, so we're talking a tenth of one percentage of an increase.
Which brings me to the idea: what other things can we conquer in a single tag? Wheelmap is the great-grandaddy and most awesome example of this. How about:
- An editor that asks you how many stories the building you're currently standing in has. Or what color?
- Bridge height entries
- Opening-hours-only editor
See a bug? If you have a GitHub account and want to be super nice to me, please file a bug in the GitHub issue tracker!
November is at an end. The efforts of the Peace Corps make their mark on the map but many others have contributed to the map.
In December we hope to publish a tool to help show the mapping status of settlements. Stay tuned!
Not a conclusive list of updated places:
- Chobe National Park
- Groote Laagte
- Tati Siding
- Thamaga Tlokweng Tobane Tutume
Before I went to visit Carroll County in North Central Ohio for a weekend in July, its state in OSM was really poor. It consisted mostly of TIGER-imported ways that hadn't been whose geometry hadn't been changed since the original TIGER Import in 2008. In many cases, the roads' geometry didn't make up with reality. Some roads were 30 meters off of where they really are; small townships of 10-20 streets on the map were like jigsaw puzzle pieces that needed to be rotated; random roads were in the middle of grassy fields. One exception to it was Carrollton, the largest city in the county, which was improved very well by OSM user Evan Edwards.
After that weekend, I corrected some road geometries and added a dozen or so POIs. and wondered how long it will take me to fix all of the roads in the county and what would it reveal about editing TIGER data.
Answer: a lot longer than I thought! (~30 hours over a couple months). Near the end, it honestly became a chore. But I want to see how it would like visually, I didn't want to do that work for nothing...
How I did it (very briefly): I was able to more quickly improve the ways by using where I'd copy the geometry from a TIGER2013 file; verify that the TIGER13 matches the aerial imagery better than the existing way.
This a great strategy and I'd advise anyone who is interested in improving TIGER-imported ways in the future.
Watch a quick example of this workflow in the GIF.
If you're interested in a detailed workflow, skip to the end...
Here's a first draft of my visualization: - http://skorasaurus.github.io/carroll.html
Now, I'm trying to visualize the improvements that I made by displaying the distance between 2 linestrings (before I edited with OSM data from spring 2014 - which a postgis table named old_line, and OSM data from Nov. 2014 which is a postgis table named new_line))
How I'm planning to do this.
A] select each point in the every linestring from old_line as oldpointdump
SELECT ST_DumpPoints(way) FROM old_line as oldpointdump
B] FOR each point in oldpointdump, find the closet linestring in new_line; measure this distance
C] create a new column for this distance (as distfromtiger)
F] then in every line string in old_table between 2 points (let's call these points J and K), add a column and assign that column a value that is (.5 * (distfromtiger for J) + (distfromtiger of K))
G] style the linestring in mapbox/cartodb using the value that I derived in F
A much more thorough workflow follows:
I used ogr2osm to convert 2013 TIGER Shapefile (then tiger2014 once they became available) into an OSM file and then loaded that file in josm and deleted all of the unnecessary tags that were created in it, except the fullname field; to ensure that the name was matching up with the correct road, and saved on my computer for my workflow.
Then, I went to editing. I downloaded some OSM data from JOSM, opened the TIGER osm file, and checked out a particular area with bing imagery. For a particular street, go over the entire street to see if the 2013 road is in fact closer to matching the aerial bing imagery than the existing road is. I'd also load up the history for the road to see if any nodes were changed. (Cntrl+H). Many roads were changed to proper highway type (tertiary) but didn't have any of the geometry modified since the original tiger import.
If the 2013 is more closely aligned than the existing road, delete the name tag in the TIGER 2013 way you're about to select; copy (cntrl+c the highway as it is in a separate layer with the separate layer selected in josm); switch to your osm data layer, and then paste into your data layer of OSM data. Then select the two ways, the new way and the way you're replacing; and hit cntrl+shift+g. CNTRL+shift+g is the 'replace geometry' shortcut that keeps the history of the original way and relations that the way belongs to.
I looked over each way that I imported. In some cases the imported way was about 5-10 meters from the center of the road in the bing imagery but still better than before and within the general margin of error that we have in OSM.
After you finish all of the ways in your area; hit the JOSM validation, first fix all of the errors marked highway duplicate nodes; then hit the josm validation button again; and go to the ways ended near other nodes, right click on each one in the list which brings me to the location of the node, hit 'N' for each. At this point, I'd go back to the ways I modified, and simplify them (cntrl+y) because TIGER with deletes any excess nodes without deleting the nature of the geometry.
Here an interesting blog post from Jordi Inglada/CESBIO about the incoming imagery from the ESA/EU-Copernicus satellites Sentinel-2 (or here) which will be published with an open license compatible for OSM tracing. The program is designated for global land-cover mapping (4 bands at 10 m resolution).
Our challenge will be to retrieve this data in a usable form for us (e.g. georeferenced, rectified and cloudless, TMS served). Also Jordi Inglada says one word about open source softwares from CNES which could be used to convert pixels into landuse polygons.
As quoted from his blog: "This means that we have free data and free tools. Therefore, the complete pipeline is available for projects like OSM. OSM contributors could start right now getting familiar with these data and these tools."
It was never more stylish to search for key-value-pairs...
Nunca foi tao estiloso procurar pelo key-value-pairs...
Problems mapping the HOLLYWOOD sign: http://gizmodo.com/why-people-keep-trying-to-erase-the-hollywood-sign-from-1658084644
The last unmapped places on Earth (with a namecheck to HOT towards the end): http://www.bbc.com/future/story/20141127-the-last-unmapped-places
Zip Code: 02203 City: Boston State: MA County: Suffolk County
State: DC City: Washington County:District of Columbia
Do everyone know the way from NY to SF. it didn't appear on the map
The energy at the first OpenStreetMap class in Ayacucho, Peru was amazing. We had about 40+ students come out to learn how to map. This is all part of our effort to build local community in this city of 150,000 in the Andes where Development Seed, (the company that launched Mapbox) was founded and where today we have a growing team of OpenStreetMap data analysts.
OpenStreetMap class at the University of Ayacucho.
I had a fantastic week in Bengaluru the amazing tech hub in India's south with Shiv and Eric connecting with startups, NGOs, data geeks and geo community. We were part of an OpenStreetMap Geo BLR meetup and the #osmegeoweek mapping party and the turnout for both events was great. We had fun rigging rickshaws with Mapillary and we met inspiring mappers like PlaneMad and NGOs like Kalike mapping rural areas on OpenStreetMap.
Geohacker presenting how the Moabi project uses OpenStreetMap software to track forest health in the Democratic Republic of Congo.
Great crowd at the GeoBLR meetup hosted at the Centre for Internet and Society.
Getting hands on with OpenStreetMap tools.
Intros at the OpenStreetMap mapping party.
Rickshaw mapping with Mapillary - here's the track.
Ordnance Survey have recently released their November 2014 version of OS Locator, the comprehensive gazetteer for GB. According to my calculations there are 12,201 new or changed entries and 10,203 removed entries since the last release in May.
I've updated my comparison tool Musical Chairs with the new data. New entries tend to show up prominently in the "recent relevant updates" view mode for a week or so after an update, so this is a good way of taking a look at what's changed in your area.
I'd suggest GB mappers take a look at their area, even if not for the purpose of mapping - new releases of Locator often reveal some interesting things about new building projects and developments.
Additionally, I've recently added RSS feeds to musical chairs to make it even easier to monitor your area for possibly problematic changes.
This is story is based on real stories. It is not my story as a newbie, but I decided to write in the first person to avoid she/he discussions. Also, since English is not my native language, so I apologise upfront for mistakes.
I love to ride by bicycle and for plannng my trips I found those great free maps offered by OpenFietsMap. I used them during my vacation in The Netherlands and now I want to improve the map for cyclists in my hometown in Belgium.
I created an account on OpenStreetMap and quickly found out how I could launch the iD-editor. It seems pretty simple to add a separate cycleway, just as I saw on the map in The Netherlands. I think it is important to see the difference between street with and without those separate cycleways. So let's try to add them.
O great, there are arial images that I can use, so I do not have to upload tracks that I recorded with my GPS. OK, let's see, the cycleway starts here, in front of those houses. So I start drawing the line there and continue here, cross the street and it ends here in front of this parking lot. Now add some tags to it...mmm .. a name... mmm maybe "fietspad" (Cycleway in Dutch).
Ok, now the other side. Mmm, the houses that the previous mapper placed are on top of the cycleway. I'll move them so I can draw the cycleway in the correct place.
Hey, that was easy, let's save this so the others can enjoy my work. O, do I need to add a comment... mmm ... "Fietspad" will be ok I hope.
So far the first editing session from an newbie user as I see it. The user honestly tried to improve the map. But could you spot some mistakes ? Here are some
- the cycleway is not connected at start or end
- The cycleway has no intersection with the street that it crosses
- It's tagged with a name that indicates its function
- the user did not put bicycle=use_sidepath on the main street
- the user did not remove any cycleway= from the main street
- the user is unaware of relations for cycle routes on the main street that have to be placed (and splitted for the different directions) on the cycleways
- the user did not add oneway=yes on the cycleway
- using Bing images which have an offset, in Flandres we can use AGIV, much better
Not all of those mistakes are made by all newbies and maybe they make some I forgot to mention here. But that is not important for the message I want to bring. One can make many mistakes and none of the editors protect you from making no errors. Some editors protect you from some of the above errors, but many mistakes pass unnoticed.
But now dear experienced mapper,
How do you react when this happens in your neighborhood ?
- yell "vandalism" ?
- contact the DWG ?
- start complaining on a local maling list about this user that destroys all this hard work ?
- send a angry private message or changeset comment ?
- do you ally with your friends to send multiple scaring changeset comments ?
or do you take a deep breath, relax and try to write a friendly, polite message to help this newbie navigate through all the pitfalls and unwritten rules from which the editors do not protect you ? Even if you have to do this for the tenth time ?
So think for a moment how it feels to be a newbie and receive a message from some stranger about something you honestly thought was a good addition to OpenStreetMap, next time you write a comment about someone else work. Heck, even when that person is a more advanced mapper.
Happy mapping & communicating
p.s. I fear that the real story that was the basis for this one does not have an happy ending
Just discovered this POI, someone offering lessons in mathematics and accepts bitcoin. Apparently he is living in the middle of the street: http://www.openstreetmap.org/node/3197308571
Will I have to use a frakkin' G00gle m*ps kml export to get those shops into OsmAnd ?!!!
Editted Portonovo, Add All the Roads :),