Recent diary entries
One of the on-going initiatives by the local OSM Philippine volunteers is to go to local communities to assist in training the local population to update and use OSM for disaster risk reduction.
One partnership we are nurturing with is the DRR mapping work by the Philippine and Swiss Red Cross in small island communities in Busuanga, Palawan. Last April 2015, mappers GOwin, feyeandal and dichapabe, went to Busuanga to start the mapping community with the local government and Red Cross volunteers. After the training the online mapping community lead by GOwin continues to assist the Busuanga mappers in updating the maps.
This work was featured in an article in Channel News Asia.
By combining local knowledge and OSM tools, we hope to continue building the local mapping capacity and data that will empower communities to respond to any crisis.
A release candidate of 0.9.6 is available https://drive.google.com/folderview?id=0B9pKLmh8s1h8bFI5bGd4VnhYWkk&usp=sharing Note the "signed" APK is signed using the same key as used for the play store and should not need an uninstall if you are replacing a 0.9.5 install.
The only change that is forseen for release, outside off resolving any last minute issues, is inlcuding the release notes.
The project I'm contributing to through the Outreachy program is Usability Testing for the Tasking Manager User Interface. The kickoff for the internship was very powerful, yet loaded. Working remotely with someone I've never met has come to be – as opposed to my initial assumptions – quite easygoing and the community has been very welcoming and helpful in the first steps.
During the first two weeks of the internship I got introduced to the community and the workflow. The issues on github were reviewed and the label UI was added to those that were related to the user interface. There has been sorting of the issues in terms of primary (User UI, Admin UI etc) and sub-sorting (Frontpage, Instructions, Feedback etc). Additionally vague issues and those already dealt with have been asked to be clarified in order to either categorise them or close them.
The aim for sorting the issues was that when someone that wants to contribute for a specific issue, they can filter and see other closely related reported issues or feature requests. This also means that when we want to focus on a specific area in the Tasking Manager, for example the Frontpage, then again all we would have to do is filter out the issues that have been filed.
This week we will be working on identifying places that people have trouble with as end users of the Tasking Manager and we will gather ideas for forming a questionnaire for testing the user interface.
Just a quick note to say well done to everyone who contributed to Missing Maps task #1068.
Data contributed by you in Nyarugusu Refugee Camp is now being used by NGOs within the camp. The image below is a map of the camp, made by MSF and featured on reliefweb.
I am having a lovely week on the Island of Malta and as part of the ENERGIC summer school we were asked to undertake a mapping party of the University and learn to download GPS data and digitise our dataset, in the hope to improve the location information.
Let's see how it goes ...
Learnt a great deal, but did not save the data as there were many duplications across the class.
Until next time.
Been mapping Darjeeling District since May 2015. mapped most of Salbari, meethi bari.
I've finished adding NY waterways. Lakes and ponds came from a NYS shapefile. I threw away everything but the latitude and longitude, and used it as an index to trace bodies of water. I got the name off the USGS Topographic map. Streams and rivers came from Wikipedia's list of New York State Rivers and Streams. All it has is the name and watershed. I used that to locate the waterway, and traced it off Bing.
Also fixed up the Hudson River bank, which was a bit under-digitized. Too few clicks. Much better now.
After almost three years I started my PhD I will finally handle a case using OSM data! Back on track, I will enjoy mapping monce more! London here I am
Here is my second report on my Outreacy project.
#Week No: Two
##Target Milestone: Improve UI of the mockup and prepare questionnaire for survey.
###Summary: Last week's UI was revised and improved along the lines of the existing web pages. A questionnaire was prepared to survey the community members.
I am still trying the quirks of mapping on OSM by means of taking photos of interests using my smartphone and tablet with geotagging enabled.
Today I went on mapping the stretch of Lilac Street in Marikina, which is fast becoming a "Restaurant Alley" for more and more restaurants are plopping up on this street in the past years.
The restaurants there had not been mapped before to OSM.
Just what I am concerned, it seems that in some cases the GPS data saved on each of my photos are not accurate enough, with error up to 50 meters. Sometimes I had to use my reckoning in an attempt to plop points in the map correctly. I still haven't installed yet any OSM editors on my smartphone, and I am too reluctant to edit OSM data on-the-spot, given how bad is theft situation in the Philippines. Imagine busy mapping a Manila alleyway when someone suddenly grabs your phone.
I am using a Korean variant of Samsung Galaxy SIII. Priming up geotagging in my device takes a minute or so, and I realized this halfway through my mission. I also have minor accuracy issues on the GPS of my smartphone; I am noticing some discrepancies of up to 20 meters when I reviewed my cycling track on a route-plotting map on my phone.
I may still well experiment with this method and refine it if needed. Aside from the security concerns which i mentioned above, currently, the best OSM editors on the market still have bugs on offline editing, so I am reluctant on using those apps. I may well have to refine my current method and use my computer in mapping based on the geotags of the photos which I took.
I seem to be going around in circles in discussion of changeset 31269952 with a professional GIS user. He's added on purpose, a node for a hardware store for which there is already a closed-Way polygon for the same hardware store.
Maybe someone can weigh in on the changeset discussion and add clarity to the discussion.
Hallo! My name is Martin Dittus, and I'm a PhD student at the ICRI Cities at University College London. I research community engagement in the Humanitarian OpenStreetMap Team (HOT), a volunteer initiative with thousands of contributors. At its core this is quantitative work, and my main outputs are statistics and data visualisations. I also spend a lot of time with the HOT community, am a contributor myself, and have spent much of the last decade with a range of similar community organisations.
I like that my job allows me to combine my experience in large-scale data analysis with my personal interest in community organisations. I spend a lot of time exploring data sets, producing things like this:
A big part of my work is about developing means to reason about HOT as a social phenomenon. I make use of "hard" evidence of data sources like the OSM edit history, but also the "soft" evidence of knowing the practices and motivations of the community. Together they allow me to develop conceptual models that help us reason about HOT. (I strongly believe you need both.)
In conversations with other community members and HOT organisers I realised that a lot of the data explorations I produce can be of interest to a wider audience. In early May 2015 I gave a talk at the HOT Summit under the title "Contributor Engagement in Humanitarian Mapping". The feedback I received was overwhelmingly positive, and there was quite a lot of debate afterwards. Then Alyssa Wright approached me and strongly suggested to find more public forms of sharing my findings. I shall aspire to do so! I can't promise a regular schedule, but I'm keen to share my observations.
In particular, I noticed that many people have a lot of experience about how to make HOT work, but also that people's perspectives tend to be local: they are focused on particular aspects or initiatives. This is in the nature of the practice, which is highly distributed across dozens of interest groups and concerns. As a result few people have a good global overview of what HOT is and how it works. In addition to these local experiences I think there is also an opportunity to develop a broader understanding of HOT, and I think I can contribute to that.
This may take different forms:
- Analytics and visualisations that highlight key contribution patterns.
- Contextualising the data: what do the numbers mean?
- Conceptual models, for example reasoning about coordination tactics.
- Evidence to substantiate design choices: currently, HOT planning decisions are often intuitive rather than evidence-based.
- Critical thinking about community and coordination activity.
You can follow me at @dekstop where I will also announce any future posts.
We now have a considerable proportion of the body of Epworth Field Papers, and we are hoping to start inputting as soon as possible.
We ran into some interesting issues in Epworth, to do with security, permissions and consent. We are working on the Wiki page for the job, and on which administrative levels to use. Rather than using, or 'imposing' external frameworks onto the randomised address system, it was important to have datasets which reflected the 'oral/institutional' memory of those on the ground delivering or directing help. Epworth's way of locating people for patient tracing (HIV and other ongoing treatments) is locked and protected in the memories of our workers on the ground.
This set of data has been carefully thought-out in order only to add to, and not to compromise, the well-being and resilience of this massively under-censussed and under-represented population.
Join us on 16th to get the data into JOSM and online.
Zimbabwe Blog: http://rupertallan.com/2015/05/23/harare/
We shall be playing with GPX traces, mapillary and Water Surveys on the night, and are still looking for the venue.
Is there a way to link to a list of all the changesets that I have made comments on?
Sometimes I make a comment on a changeset that a user never responds to. It would be helpful to be able to follow up on those, but it's hard to track them down because I don't get an email notification if I don't get a response.
The OSM Blog Entry on Changeset Discussions alludes to an API that will be described on the wiki, but I can't seem to find it.
Today the OSM community can use several tools to add items on the map.
But if you want to just change the tags of a single already mapped item do you really need to load an entire program (like Josm, iD, Potlatch)?
Some days ago I discovered the incredible online tool Level0 that permit to directly add/change/remove tags.
This got me thinking about why there is not an integrated system in osm.org to make such a thing too.
We already can select an element (in the nominatim results list, from data-layer, or by "?" button on the map) and see its tags, but why can not a logged-in user directly edit them?
Actual state: What I mean:
PS: the last image above is not a mock-up or an ongoing project, I done it only to explain what I mean better than my English.
The world is messy and human languages moreso. Recently the talk@ mailing list erupted in discussion over a proposal to shunt the vast majority of
name:* tags over to Wikidata. But most of the discussion has centered around rather eurocentric examples and concerns. I worry that the discussion will lead to a policy change based on overgeneralizations. Having done a fair amount of multilingual name-tagging in the past, I want to point out just a few of the complications that monolingual mappers may be unaware of.
Translation versus transliteration
The top 20 languages are each natively spoken by about one percent of the world’s population. Twelve of them are in scripts other than Latin, and at least three are in non-alphabetic scripts, requiring transliteration just to produce a name that monolingual English speakers can recognize as text, let alone type.
Some have argued that translations are preferable to transliterations. Others have argued that transliterations should be omitted entirely from OSM, as an exercise to the reader or a job for third-party services. But what’s the difference between translation and transliteration? The wiki offers this simplistic explanation:
Transliteration is the process of taking a name in one language, and simply changing letters from one script to another.
This definition is a gross oversimplification, downplaying what it takes to adapt a foreign word to something you can use in your own language. There are three ways to go about it:
- Transcription from another language gets you the original word’s pronunciation respelled in a very literal phonetic alphabet (or a language-neutral alphabet like the IPA), without regard for etymology. Except for cases involving ideographic scripts, as we’ll see below, pure transcription is almost never the right answer for a
- Transliteration from another script to a Roman alphabet gets you the original word, but respelled as if English had borrowed the word, often taking liberties with the pronunciation in order to look “native” or respect the original etymology. Transliteration is the most reliable method for producing a usable name in your language.
- Translation from another language to English gets you a word that refers to the same thing in English but may have a completely different pronunciation and etymology. Translation is only appropriate in a limited number of cases for historical reasons. Words like “north” and “city” are often translated while the rest of the name is transliterated.
I don’t speak Russian; perhaps one can get Абергавенни from “Abergavenny” by performing a simple one-to-one mapping from Cyrillic letters to Latin letters. But Russian has varying transliteration schemes, each with their own exceptions, and that’s a relatively easy task considering that the Roman and Cyrillic scripts share a common ancestor.
A counterexample: transliterating Chinese to Vietnamese
Shanghai has a Vietnamese name. You’ll never see it on signage in Shanghai, but no Vietnamese speaker refers to the city by its Chinese name. (Photo: Immanuel Giel / CC BY-SA 4.0)
Over the last seven years, I’ve added tens of thousands of
name:vi tags by hand, the vast majority of them to
place POIs and relations in mainland China. One of these POIs is Shanghai, called 上海 in Chinese. English-language literature calls it “Shanghai”, after the Pinyin transcription Shànghǎi. Shanghai is just a name to English speakers; it retains the pronunciation, more or less, but not the meaning. A literal translation would be “High Sea” or, more poetically, “Upon the Sea”. You’d never put “Upon the Sea” into OpenStreetMap because no one has ever called it that. You’d set
name:en=Shanghai because English has no special name for the city.
Vietnamese is very different when it comes to Chinese names. Vietnam has had millennia of intense contact with China (much of it adversarial). As a result, every Chinese character has a Sino-Vietnamese reading: a word that was borrowed from Middle Chinese into Old Vietnamese, retaining the meaning but not the pronunciation (owing to changes in both spoken Vietnamese and spoken Chinese over the centuries). For Shanghai, I set
name:vi=Thượng Hải, using Sino-Vietnamese for 上海. It literally means “high sea”, but in words that are only used for terms and names borrowed from Chinese.
As it happens, 上 has multiple readings corresponding to different meanings: thưởng (award), thượng (high), thướng (rise). Choosing between them is the task of a translator, not a SQL transform. So how does a translator like me know choose the right Sino-Vietnamese words? Sometimes the answer is obvious: I simply learned long ago that Shanghai is called Thượng Hải in the course of learning Vietnamese, and most Vietnamese learn that just by living in Vietnam for a time. For more obscure names, there are plenty of places to look up individual characters. My sources have included an out-of-copyright dictionary and a Sino-Vietnamese database that comes with no restrictions according to its author. (For the record, Unihan is TIGER bad when it comes to Vietnamese.) When I’m on the fence about a transliteration, I double-check it against sites like the Vietnamese Wikipedia. And when a character really has me stumped, I leave the POI alone.
If I were to actually translate “Shanghai” into “plain” Vietnamese, the result would be either Trên Biển if I transliterate at the same time or something like 𨕭𣛟 if I don’t. (The Vietnamese language also used ideographic characters until the 20th century, just a different set of characters than Chinese.) No one would ever use the “plain” Vietnamese name, though; Thượng Hải is the only correct way to render this particular city’s name in Vietnamese.
This is just one language out of many that have rich histories of dealing with multiple writing systems. You can imagine that other languages have their own unique considerations.
Machine transliteration is impractical
If we rely on software to localize place names for us, some languages can hope for no better than hack jobs, akin to this humorous map in “English”. (Illustration: imkharn)
There has been plenty of handwaving about renderers and geocoders that are smart enough to transliterate between different writing systems. But consider that Google Translate, with all its NLP might and a corpus the size of the Internet, fares poorly at interpreting Chinese place names. It doesn’t know that 红寺堡 is Hồng Tự Bảo in Vietnamese or “Hongsibao” in English. Your average mapmaker can’t afford that kind of technology anyways.
Software developers have much more experience converting between metric and imperial units than between human languages. Even though Sino-Vietnamese words aren’t “plain”, modern Vietnamese words, their meanings are often not lost on Vietnamese speakers today. Any schoolchild could tell you that thượng hải means trên biển (upon the sea), an apt name for a major port city. But a multilingual software client, burdened with the knowledge that thượng could also mean 㐀 = “hill”, or 㠪 = “five”, or 尙 = “yet”, would need a lot of resources to make a decision:
- Natural language processing (NLP), a form of artificial intelligence
- Context about the city and common naming practices
- A decent, machine-readable, suitably licensed dictionary for that particular language pair
- Possibly even dedicated logic for each character, multiplied by the number of transliteration schemes
Then there are suggestions that IPA transcriptions could be tagged as an intermediate step. But IPA comes with its own headaches, like whether to transcribe broadly or narrowly. Consider the number of valid English pronunciations of “north”, then consider that the same Chinese script is used by a host of mutually-unintelligible language varieties.
It wouldn’t be possible to derive the Sino-Vietnamese name from an IPA or Pinyin transcription, anyways, because they have different many-to-many mappings between characters and words. Shàng (Pinyin) doesn’t just correspond to 上; it also corresponds to the following characters, as would an IPA transcription based on Mandarin: 上姠尙尚蠰銄鑜. On the other hand, thượng (Sino-Vietnamese) corresponds to a very different set of Chinese characters: 㐀㠪丄仩上鞜妴尙尚鞝躺𠄞. Spoken Mandarin and Vietnamese have evolved so much over the centuries that, if a system like Sino-Vietnamese were invented today based on modern Mandarin pronunciation instead of Middle Chinese, it would employ a completely different set of words for each character.
There is a consensus at least that automatic transliteration does not belong in OSM, because it cannot be verified for accuracy. But excluding handcrafted transliterations from OSM forces data consumers to foist those same automatic, unverified algorithms upon their users. The result is the worst of both worlds: poor support due to the effort required and poor quality due to a lack of context.
This is a test Diary post about upcoming camping trip in Yosemite
Recently I stumbled over the key "lines". According to taginfo there exist about 6500 objects with this key, a number that has been decreasing the last days as I deleted quite a lot of them (the keys, not the objects). From what I see there are 3 different usages of this key:
to tag which public transport lines are serviced here, so this may be a lines=U1 on a railway=subway or even on a railway=platform. Whereever I found that and the object was already part of a proper type=route route=(some public transport thing) for all of the lines keys, I simply deleted them. Given the relatively small number of these object noone can create any reasonable public transport information from these tags. public_transport relations do a far better job for them, and they are much more popular. Given the age of almost every instance of these keys on the objects they clearly predate the public_transport relations, and simply had not been removed when the relations were introduced. So whenever you care for public transport tagging anywhere please check if there are lines keys in the objects you edit, and if their information is contained in a proper relation, then just remove the lines keys.
to tag something that has a different key. I clicked a bit around in the OverPass queries linked from the taginfo page and any instance I found highway=* lines=* it should have been "lanes" instead. There are also some instances of railway=* lines=*, where I guess tracks would be the right key (at least for lines=1 and lines=2). In case you want to touch any of them: prefer to tag every track as it's own way and not use the "tracks" key. I assume that almost any combination of lines with either highway or railway is wrong and should be fixed.
to tag something entirely different. There is one instance of lines=1 in North America where this gives the number of power lines between poles. There are some instances of lines=phone where this tells you that there are telephone wires. There are some instances of lines=no or yes which tell you that this is a basketball court that may or may not have markings. I personally would not touch these taggings as it is clear to a human what they mean, and deleting them without replacing it with a proper tagging would destroy information (how relevant or not they may be).
From my point of view it would be great if all instances of #1 and #2 would be removed from the database. But simply deleting them is not the way forward, one should do it with care. The way to get rid of the greatest numbers of them is to introduce proper public_transport relations where they are missing, e.g. for some of the S-Bahn lines in Hamburg or U-Bahn in Stuttgart. In case you are bored and any of these tags are in an area you care about: check what is the proper tagging, and let's get rid of lines.
Basic project setup
- Use qtcreator for GUI layout/development and for defining most of the common signals/slots for the GUI components
- Do not change any generated code directly but create a subclass and then override/extend it, to keep our code and the automatically generated code separated
- Use QgisPluginCreator that has some basics setup (eg. internationalzation support)
- Package any external python modules as part of the plugin
OpenAerialMap (OAM) is an open service that will provide storage and search within a collection of openly licensed satellite and unmanned aerial vehicle (UAV) imagery. OAM will facilitate the processing and provision of imagery for humanitarian response and disaster preparedness, making it easier to determine what imagery is available and where it is. OAM Catalog will be used for indexing and OAM Browser for searching.
The Open Imagery Network (OIN) is a consortium and specification of imagery providers led by HOT and Planet . Imagery indexes from all participating providers will be merged into the main OIN index through a GitHub repository. Providers will host an index of all their dataset and add the URI to the main OIN index in GitHub.
The OAM Server will be responsible for processing data directly from providers of aerial imagery or from existing Open Imagery Network (OIN) nodes . Once a new imagery is uploaded, the Server will trigger a tile engine instance to create a tiled map service and save it to a specific storage (eg. S3 bucket). It will also create the needed metadata and submit it to the OAM catalog to be indexed and easily searcheable. Check specifications for OAM metadata and OIN metadata for more details. Each stored image will carry such metadata.
The development of the OAM server is schedule for the period between June 15h and August 15th 2015 . Gitter chat is used as the main channel of communication with weekly meetings on Thursdays at 18h00 UTC.
There are so many new terms involved in this work that having a list of acronyms will give a hand to our lazy memory.
Just wanted to share some thoughts from the mapping party at Imperial College in London last night.
The London mapathons have always been a place of excellent collaboration and idea exchange and for that reason this is where we try to meet anyone who wants to collaborate with us. I just wanted to share some of the conversations I had or overheard.
Imperial College students in the iD room (different rooms for iD and JOSM users this month) were discussing how they thought they could help Missing Maps and HOT automate some our processes.
Matt from Accenture, who had volunteered at the Accenture corporate mapathon, dropped by to discuss how he and his colleagues might be able to collaborate on helping us quantify the contribution of our mappers, to better plan our tasking and develop tools.
Ny came down from Loughborough, where he is doing a masters, to discuss Missing Maps collaboration on his thesis.
Carmen from MSF recruited some of our JOSM users to support her remotely when she goes field mapping in Bangladesh in July.
Joseph from Reuters was there talking to the HOTties for a story he is planning to write on Missing Maps.
These are just some examples, but it was clear last night that the Missing Maps London mapping parties are becoming so much more than a group of people mapping. The project is coming alive and growing legs and wings (and possibly other bits).
It's beautiful to see and a privilege to be a part of (and we did loads of mapping!)