Users' diaries

Recent diary entries

GSoC'15 Project update

Posted by sbagroy986 on 20 June 2015 in English (English)

Hey everyone!

I'm working on the Moderation Queue project as a part of GSoC'15 along with Serge Wroclawski (emacsen), my mentor.

The official starting date of this project was 25th May, about three and a half weeks back but we have been working on it for almost two months now. You can see all our work on github here.

So, over the last two months, we've made some pretty great progress!

Currently, reporting a problem on is a cumbersome. One needs to actually email an administrator with the concerned issue ( malicious edit, offensive user profiles, offensive note comments etc). Our project involves simplifying this process and allowing users to seamlessly report such problems without any hassle.

Our solution to this problem is the creation of a simple "Report" button, as can be seen in the pictures.

As we can see, users can now simply click on Report to create a complaint against the instance - in this case a Diary Entry or a Changeset.

This leads to a page where the user provides a little detail about the problem. This here is the page for reporting a Diary Entry:

All one needs to do is fill in the form, and that's it! Considerably less work than the current procedure.

We've also made a dashboard for the administrators and moderators to sort out the incoming reports and deal with them more easily than right now.

So basically, we're trying to reduce the amount of effort at both ends - to allow for faster, more efficient and less cumbersome creation and monitoring of reports against problems. We're hoping it helps everyone out.

That's it for this update!

Como nomear ruas no OpenStreetMap a partir de mapas do IBGE

Posted by vgeorge on 19 June 2015 in Brazilian Portuguese (Português do Brasil)

Um guia que fiz sobre como nomear ruas no OpenStreetMap a partir de mapas do IBGE, vejam:

Camada de ruas do IBGE

HOT Board Special Election Statement

Posted by dkunce on 19 June 2015 in English (English)

HOT is still at a pivotal time in its growth. We haven't fully put the events the past few board elections behind us. The old debates of what a 'HOT project' is versus what is HOT, the role and responsibilities of the board, and silly conflicts, still go on. HOT must grow out of this current adolescent phase if it is to become truly successful and sustainable. HOT is and will always be a mapping NGO. However, to get HOT to where it needs to be, it needs to be about more than skilled mappers and dedicated activators. HOT needs to improves its fundraising, administration, and visioning to become an accountable organization. I know that there has been some resistance to HOT growing as an organization and that there are those members that see HOT the NGO as being different from the HOT community. I understand the resistance but disagree, HOT the NGO and HOT the community should be the same thing for a variety of reasons, most importantly fundraising. More partners are counting on our work both during activations and normal times.

In my day-to-day professional life as the GIS lead for the American Red Cross, I work a lot with HOT, local OSM communities, governments, other NGOs, and private corporations to strengthen and build OSM communities. I've lead Red Cross GIS teams during several responses over the last couple of years including, Typhoon Haiyan, West Africa Ebola Outbreak, Malawi Floods, Typhoon Pam, and the recent Nepal Earthquake. When I asked the British Red Cross, HOT, and Medicine Sans Frontiers to come together to create the Missing Maps project, all jumped at the chance because of how much they like and support HOT. Missing Maps is a huge accomplishment for HOT. It allows HOT to engage with new stakeholders, local communities, and donors to accomplish HOT's work. I've worked hard since joining the non-profit sector to lend my hand at strengthening HOT: founding Missing Maps, building technology to enable our work (Tasking Manager v2, OpenMapKit, OSM-Meta-API), fundraising for various projects, helping host and plan the first ever HOT Summit, representing HOT and Missing Maps to the media and at conferences, and working behind the scenes in the humanitarian sector to lead the adoption and use of OSM by humanitarian organizations.

My vision for HOT is a continuation and evolution of its current path. I want HOT to have a solid financial foundation that supports both technology and field projects, HOT helps guide other humanitarian organizations to adopt and use OSM, and the old animosities are replaced with a renewed passion and dedication to help HOT grow.

The key areas that I will focus on if elected to the board include:

  • Governance: Build upon the momentum created by existing HOT staff and working groups to manage and maintain the governance structures within HOT. This especially includes strengthening the rules around conflicts of interests and holding members and board members accountable or their actions.
  • Overhaul Board Terms of Reference: The existing HOT Board is required to oversee the daily management of HOT and does not have enough time to focus on creating and implementing a longer term vision. I will work to empower HOT staff to take a more active part in the daily decision-making process in line with how other NGOs function.
  • Partnerships: It is imperative that HOT build better partnerships before disasters. One of the main reasons the American Red Cross uses OpenStreetMap is due to the relationship built prior to, rather than during, a disaster. Pre-established relationships can strengthen the broader applications of HOT to other actors. I will develop and strengthen partnerships with humanitarian relief organizations so that OSM and HOT are embedded into their business operations.
  • Fundraising: HOT needs to secure unrestricted funding to support long term projects, technical infrastructure, and increased staff. Many organizations depend on HOT during times of crisis and even during normal operations.
  • OSMF: HOT should work to strengthen OSM Foundation to support the underlying infrastructure that it relies on. This includes helping OSMF establish more OSM chapters around the world.

During the normal election last year it was pointed out that I will have some Conflicts of Interest in my role as the GIS Lead for American Red Cross and as a potential board member. First let me state that I will be the first one to acknowledge those conflicts and excuse myself from those conversations. Yes my work overlaps a lot with HOT's day to day. That is a good thing. It shows that partners such as the Red Cross value and care for the HOT community. While ARC has given HOT money in the past for a few small projects the real value of our contribution to HOT is in staff time. I have given tons of personal and work time to supporting HOT. The folks at ARC are very proud to be HOTties, we enjoy making things possible that would otherwise been very difficult such as the HOT Summit. As I have stated before I will recuse myself from any discussions concerning financial matters with HOT and ARC or Missing Maps. This follows not only good board practices but existing ARC and HOT rules.

I will be available on Mumble Monday (7/22 11am-12pm), Wednesday (7/24 10am-12pm), and Thursday (7/25 10am-12pm) USA Eastern Time Zone if you would like to stop by and ask me any questions. I encourage Pierre to be available during the same time so you can ask us both any questions you might have.

This election asks you to make a difficult choice. HOT could remain a small volunteer organization, run by individuals whose work with donors and international agencies—while well meaning—will be around small projects. It could remain mired in the politics of similar small NGOs, where debates over small issues keep the organization from focusing on growing. Or HOT could blossom into its full potential, with a board composed of professional mappers, humanitarians, fund-raisers, and leaders. HOT could scale to offer far more communities a wider range of services than we can now perform with our small base of trainers. I want to help HOT grow. I have the background, network, and management skills to contribute to that vision. It’s your choice. More debates or more impact.

Suburbs or villages?

Posted by TuanIfan on 19 June 2015 in English (English)

I've added admin boundaries and titles for eastern suburbs of Bundaberg. That's fairly easy for urban suburbs since they're usually smaller in size. However, country suburbs like Rubyanna and Qunaba require more consideration.

I was wondering if i should tag them as place=suburb or place=village, as they have less than 500 in population.

Bundaberg eastern suburbs

Обозначил на карте дом Яблочная 25

Posted by apkhome on 18 June 2015 in Russian (Русский)

Информация достоверная, там живет мой друг

Revisão, Atualização e Correções em Porto das Caixas

Posted by Filipe Fonseca on 18 June 2015 in Brazilian Portuguese (Português do Brasil)

Na última semana, venho realizando correções na região de Porto das Caixas, bairro do 2° distrito de Itaboraí/RJ. A localidade estava muito desorganizada, com falta de ruas e ruas sem nome, sendo feitos as seguintes atividades:


  • Redefinição de traçados;
  • Inserção de nomenclatura nas ruas, sendo o nome oficial e o nome local (mais conhecido) entre parênteses.

Áreas de Interesse

  • Praças, Campos, Igrejas e o Cemitério do Bairro;
  • Pontos de Ônibus;
  • Escolas;
  • Estabelecimentos Comerciais.

Brevemente seguirei para alterações em Visconde de Itaboraí.

Location: Porto das Caixas, Itaboraí, Microrregião Rio de Janeiro, Região Metropolitana do Rio de Janeiro, Rio de Janeiro, Região Sudeste, Brasil


Posted by musznik on 18 June 2015 in Polish (Polski)

ciągłe szlifowanie witnicy

Недельное задание 14: статистика

Posted by edward17 on 18 June 2015 in Russian (Русский)

На прошедшей неделе, по предложению Larry0ua, заданием было нанесение использования железных дорог (тег usage=*).

Результаты недели представлены на диаграмме:


Я каждый день выкачивал тайлы 10-го зума OpenRailwayMap для того, чтобы в конце недели показать изменения в виде анимированной картинки. Но готовые картинки получились с разрешением примерно 13000 * 10000 px и... Я не знаю, что с ними делать. Есть идеи? :)

Вместо этого - небольшой интерактив: на странице вы можете самостоятельно сравнить состояние железнодорожной сети в определённом месте в разный момент времени.

Небольшое пояснение:

  1. Чтобы увидеть слой OpenRailwayMap, нужно включить один из слоёв справа вверху.
  2. Просматривать можно только 10-й зум, потому что это первый зум, на котором OpenRailwayMap показывает все ж/д пути.
  3. К сожалению, у меня не получилось нормально скачать тайлы с результатами первого дня. Насколько я понимаю, не все они успели перерендириться, когда я их скачивал. Из-за этого в некоторых местах в первом дне может быть устаревшая информация. С другими днями всё хорошо.
  4. Из-за глюков в OpenRailwayMap на карте иногда возникают непонятные линии, как, например, на этой картинке: orm_bugs Ничего не могу с этим поделать.

В этот раз 4 участника сделали 25 пакетов правок, в которых было около 3 700 изменений.

На этой неделе: домики в Запорожье.

Don't know what to think of it of this research

Posted by escada on 18 June 2015 in English (English)

Somewhere in April, I bought a smartphone and installed OsmAnd on it. During my first ride with it, I discovered that someone tagged a stretch of an highway with maxspeed=50. I noticed it, because OsmAnd suddenly warned my that I was speeding.

The same day I changed it back to the normal 120 and I left a changeset comment. Today I got a reply to that comment (in Dutch):

"Deze werd in OSM geplaatst voor een onderzoek naar de temporele kwaliteit van OpenStreetMap. Alle gemaakte fouten, die nog niet verbeterd werden door de gemeenschap, worden vandaag verbeterd."

The translation is something like

"Those errors were placed into OSM for a research in the temporal quality of OpenStreetMap. All deliberately made mistakes, that are not yet corrected by the community, will be corrected today"

Any thoughts ?

MapBox and MapQuest ... the bit the tech pundits are missing

Posted by SimonPoole on 18 June 2015 in English (English)

In all the noise about MapBox's Series B offering and their successful bid to replace MapQuest's in house map rendering capability, it seems that our dear trade rags missed something.

Likely the most important medium term aspect of the successful bid is that it removed funding and support for a competing vector tile rendering stack that MQ was developing internally.

Anybody that has been following the developments knows that while open source and in principle freely available, the MapBox vector tile stack doesn't work "out of the box" in any reasonable meaning of the words. It follows the trend of the bits and pieces of MapBox's technology becoming increasingly more difficult to use in practice by the community. The other well known example is MapBox studio, the follow up to the widely independently used TileMill.

A recent article actually points to parts that are closed source, a not completly unexpected change of direction.

Now I think we all realize that it is just a matter of time till the open source community catches up on the vector tile front. This will address some of the issues the OSM community has been having with its map rendering and even the playing field a bit. But MapBox has clearly bought themselves some more breathing space for now.

Mapathon 16th June Epworth Field Papers

Posted by rupertmaesglas on 17 June 2015 in English (English)

What an interesting Mapathon. A real brainstorm for policy on how to deal with how Neighbourhoods which cross wards will be mapped. Rob Scott showed us how to share 'ways/relations/boundaries' by using Overpass Turbo to export the admin levels into JOSM. Sarah Wise and Tom Hills took up the batten, which was not easy. Rob insisted that we work out these ways of tagging 'Parcels' of land with shared boundaries, and it was true that although little was inputted, we now have clear strategy. Below is a summary from email correspondence:

Hey Tom and Sarah.

Hope the following fits with what Sarah has down from last night here:

I will double-check once my emails are answered, but please feed back.

Great that you're getting time to do stuff, Tom. This is indeed the issue that we came up against, and which led to that slightly esoteric venture into Ways, Relations and Boundaries. I am adjusting the levels a bit from yesterday. Also, I think it may be good to let those who want to just tag the houses and leave the boundaries. Better for the newbies like me. I'll ask for feedback on this, tooo, from the community.

Sometimes, the away to find and address consists in upper levels, sometimes in lower.

In these cases, indeed the whole case of Epworth, we need to 'live with' gaps in the Address Chain at certain levels. Sometimes occupied by qualifiers, sometimes blank, because admin levels are not consistent in the addressing system. So let them be pushed and let's create the space. Rule of thumb is to 'shunt' the values up or down to line-up and leave gaps in the value fields which become empty. This would be a true rendering. I think my team-mate Kieran would concur. (I will post and hope for confirmation.) So yes, option 3. Create a new level: 'subdistrict'.

So the address chain is: Ward=2, Neighbourhood=Makomo(to be tagged in 'ways/relations' as 'Metropole' level 0), Area=Makomo Extension (to be tagged at 'Metropole' Level 1), Subdistrict/Cell= for example 'M' - a qualifier for the part of the neighbourhood, which is present on some field papers (to be tagged Met. Level 2) Street/Hamlet (to be tagged at Met.Level 3) - for example '=Chinamo', 'Parcel' or Block which is the Proper Name/Number/Identity of the parcel of land. If there is a name, consent has been sought and given, and this is the equivalent of a 'community head', to be included in the 'name'. I will try to link you up with the trello page. Also I will try to post this on there and the HOT mailing list.

Hope this helps.


On 17/06/2015 12:56, Thomas Hills wrote:

Hi Rupert, I hope you're well. Sorry to pester you so soon after yesterday with questions about Missing Maps! I don't have anyone else's email addresses so if you could pass this around everyone else that would be brilliant. I've had a look at my field papers and there seems to be an overlap between Neighbourhood and Area. Roughly half my papers use Makomo Extension as a neighbourhood (i.e. addr:neighbourhood) and half as an area (i.e. addr:hamlet). This wouldn't be such a problem but it then pushes the other designations out of defined categories. An example: Our categories are area\neighbourhood\name. In some papers, I have Makomo\Makomo Ext\name. (e.g. NW M6) In others, I have Makomo Ext\neighbourhood\name. (e.g. NW M9) So we need to determine how to work this out. I think there are three options: 1) Makomo Ext, etc are neighbourhoods. The extra info can be put in as, e.g. "addr:neighbourhood = Makomo Extension/Chinamano." 2) Makomo Ext etc are areas. The extra info can be put in as, e.g. "addr:hamlet = Makomo/Makomo Ext" 3) We create a new level (addr:subdistrict perhaps). Any 'extensions' go in here, and this way all info has a category. I don't mind which method we use - I don't use the maps and I'm not an experiences OSMmer so I'd be reticent to give an opinion, Cheers, Tom

С миру по нитке

Posted by Otnow on 17 June 2015 in Russian (Русский)

В данный момент проходит сбор средств на новое железо для нашего проекта. Уже собрано £36,540 из £56,000 запланированных.

Support OpenStreetMap

В общем, как говорится: "С миру по нитке — голому рубаха".

Many a little makes a mickle

Поможем рублем по мере сил!


Posted by Zww on 17 June 2015 in Chinese (China) (‪中文(中国大陆)‬)


Location: Michaelshoven, Rodenkirchen, 科隆, Köln, Regierungsbezirk Köln, 北莱茵-威斯特法伦, 50667-51149, 德国


Posted by the-z on 16 June 2015 in Japanese (日本語)


ひとまず、建物だけでもと思いながら追加をしているが、なかなか数を増やすことができない。 また、作業が単調になってしまうのですぐに中断してしまう。



Primeira vez no openstreetmap

Posted by José Carlos Aires on 16 June 2015 in Brazilian Portuguese (Português do Brasil)

Hoje pela primeira vez, resolvi editar algumas ruas em meu bairro, sendo que é a primeira vez que faço isso. Acredito que estou contribuindo com as correções dos lugares que conheço com detalhes e que estavam com informações ausentes (sem nome nas ruas) ou erradas (ruas com escadas não informadas e rua com nome errado). Também acrescentei mão correta das vias que não tinham estas informações. Espero que este material não se perca e seja incorporado ao mapa de forma definitiva.

Location: Encantado, Rio de Janeiro, Microrregião Rio de Janeiro, Região Metropolitana do Rio de Janeiro, Rio de Janeiro, Região Sudeste, Brasil


Posted by etu on 16 June 2015 in English (English)

Finalized. Additionally, missing areas finalized around Järvenpääntie down to Hyrylä traffic circle. No obvious missing areas in Rantatie, Kirkonkylä or Hyökkälä any more.

Location: Tuusulan pappila, Kirkonkylä, Tuusula, Helsingin seutukunta, Uusimaa, Southern Finland, 04310, Finland

Colorindo rodovias

Posted by naoliv on 15 June 2015 in Brazilian Portuguese (Português do Brasil)

Mais uma da série "Formas diferentes de visualizar o mapa"

Não sei se todos conhecem, mas existe um tipo de relação específica para rotas de rodovias/estradas.

Todas as relações, de modo geral, servem para agrupar objetos com uma mesma característica ou para compartilhar elementos (evitando assim objetos desnecessários ou duplicados no mapa).

No caso das relações de rota, é algo muito útil para associar as várias partes de uma mesma rodovia, para representar diferentes trechos compartilhados¹, rotas turísticas (a Estrada Real é um bom exemplo que poderia ser mapeado no OSM), verificar continuidade, entre outras coisas.

¹ O que seria um "trecho compartilhado"?

Peguemos um trecho qualquer da SP-330, a Rodovia Anhanguera:

Este mesmo trecho faz parte de "duas" rodovias (ou de outra forma, possui duas denominações):

Este pedaço poderia fazer parte de tantas outras rodovias ou rotas (turísticas, de ônibus, etc) quanto for necessário, sempre utilizando relações para isso.

Mas bem, quem trabalha com relações de rota já deve ter tido dificuldade de visualizá-las no JOSM. Ou a minha ignorância é grande e não consegui achar como fazer isso no JOSM ou ele realmente não tem uma opção de destacar todos os trechos que fazem parte de uma relação (e manter o destaque, mesmo selecionando e editando outros objetos).

Só que isso é muito fácil com, é claro, mágica!

Para os exemplos vamos trabalhar com essa pequena área: Área de exemplo

Quem abre o local no JOSM não enxerga em um primeiro momento o que compõe a SP-330 ou outra rodovia qualquer: Visualização padrão

Tudo é representado da mesma forma.

No JOSM até é possível selecionar a relação, dando para ver os objetos que a compõem: Relação selecionada

Mas se selecionar ou for trabalhar com outro objeto, o destaque some.

No entanto podemos sempre destacar todos os caminhos que fazem parte da relação da SP-330, independente dela estar selecionada ou não: Destaque relação

Na cor roxa temos todos os caminhos que possuem highway e que são elementos de uma relação de rota com ref=SP-330:

relation[type=route][ref=SP-330] > way[highway] {
        color: purple;

Mas que uso prático alguém poderia ter com isso, além visualizar a rodovia?
É possível enxergar rapidamente alguns trechos que deveriam fazer parte da relação.
Por exemplo, faz de conta que esqueceram de adicionar um dos lados da rodovia na relação. Teríamos uma das mãos sem destaque em roxo: Faltando na relação

Essa faixa da direita precisaria ser adicionada à relação.

Ou então para achar trechos errados, que não deveriam fazer parte da relação: Trechos errados

O trecho em roxo à esquerda claramente não deveria estar incluído nessa relação, já que é outra rodovia (a Washington Luís, SP-310).

Outra coisa que podemos fazer, ainda trabalhando nas rodovias, é destacar os trechos que possuem pedágio.

Trechos que pagam pedágio são representados por toll=yes no OSM, e devem ser utilizados apenas nas partes onde só é possível trafegar com o pagamento de pedágio.
Ou seja, o trecho anterior ao pedágio onde não existe alternativa a não ser seguir em frente e pagar a tarifa, e o trecho após o pedágio, onde só é possível trafegar tendo passado necessariamente pelo pedágio (são os trechos onde não tem como escapar do pedágio, portanto). Não é para se utilizar em toda a extensão da rodovia para indicar que ela possui concessão ou pedágio em alguns trechos.

É muito importante entender isso para representar de forma correta os pedágios na rodovia. Isso influencia diretamente o cálculo de roteadores que possuem a opção "evitar pedágios".

Ainda utilizando o mesmo local, podemos ver os trechos que estão marcados com toll=yes, em verde limão:


way[highway][toll=yes] {
        color: lime;

Se for analisar este trecho é possível ver que não está correto o uso de toll=yes (praticamente a rodovia inteira está com a tag, mesmo onde é possível dirigir sem pagar pedágio).

O correto nesse caso deve ser: Pedágios corretos

Dá para ver que quem for entrar na Rodovia Washington Luís, vindo do norte, não vai pagar pedágio. Quem for ficar rodando que nem bobo no trevo também não vai pagar pedágio. Mas obrigatoriamente quem veio do sul e está chegando neste trevo, teve que pagar pedágio, assim como quem está indo na direção sul também pagará.

Misturar vários parâmetros e cores também é possível.
Por exemplo, caminhos que fazem parte da SP-330 e que possuem a tag de pedágio:

relation[type=route][ref=SP-330] > way[highway][toll=yes] {
        color: purple;
        casing-color: yellow;
        casing-width: 2;

Para diferenciar dos outros exemplos, este utiliza um caminho roxo com bordas em amarelo: Pedágio e SP

Já temos aqui então outro uso prático para as cores: ver classificações ou marcações erradas. Todo mundo já pode começar a arrumar as relações quebradas e todos os pedágios das rodovias ;-)

Quem for mexer nessa parte de verificação e controle de qualidade das rodovias também pode, em algum momento, querer saber os trechos que algum usuário modificou por último (talvez para verificar locais que foram incorretamente reclassificados, adicionado pedágios, etc).

Não dá para fazer diretamente com MapCSS, mas dá para acessar a função de busca do JOSM através do MapCSS, com JOSM_search().
A busca de objetos de um usuário no JOSM é feita com user:NomeDoUsuário. Por exemplo, para ver o que eu modifiquei por último, basta buscar no JOSM por user:naoliv.
Essa busca só funciona nos objetos abertos no JOSM e apenas retorna a última pessoa que modificou os dados.

Unindo então a busca do JOSM por objetos modificados com algum parâmetro de seleção do MapCSS, podemos ver todas as rodovias que alguém modificou em alguma área.

Utilizando Ribeirão Preto como exemplo: Ribeirão Preto

/* destaca tudo o que fui o último a modificar */
way[highway][eval(JOSM_search("user:naoliv"))] {
        color: fuchsia;
        z-index: 1;

/* escurece todo o resto */
*[eval(JOSM_search("-user:naoliv"))] {
        color: #313131;
        fill-color: #313131;
        symbol-size: 1;
        icon-opacity: 0;
        symbol-stroke-color: #313131;
        text: "";

Os destaques em rosa (em homenagem ao nosso amigo leitoso) são as ruas onde a última modificação é minha.

Entendendo isso dá para aplicar mais estilos para várias outras situações ou necessidades.
Pode-se dar destaque em ruas que não possuem superfície, número de faixas, velocidade máxima, nome, etc.
É o que muitos dos estilos do JOSM fazem.

Location: Rodovia Anhanguera, Cordeirópolis, Microrregião de Limeira, Mesorregião de Piracicaba, São Paulo, Região Sudeste, Brasil

Użyłem śladu GPS.

Posted by Poprawiacz on 15 June 2015 in Polish (Polski)

Mam pierwszy własny ślad GPS. Użyłem go dla edycji wyglądu Rynku w Dęblinie na mapie.

Nie jest na liscie, ale w trakcie tymczasowego ładowania kliknąłem edytuj, dzięki czemu poprawiłem wygląd Rynku w Dęblinie.

Łącznie użyłem już 5 tymczasowych, ale pomocnych śladów GPS.

Czech LPIS landuse import finished

Posted by xkomczax on 15 June 2015 in English (English)

As Pavel Kwiecien informed, the import of landuse from LPIS, czech farmland registry, is finished. It means whole (except for small gapes) country have now landuse with corresponding value on it. Many thanks to everyone involved! :-)

This is not the first import in the country's history: there was import of forests, waterways (and other water-related objects), not very long ago the import of addresses was finished (updated by bot) and the buildings import is work-in-progress as we are waiting for cadastral office to digitize the rest of data).

The question is: "What next?". As the summer is calling, there will be a lot of outside mapping during next few months but it is always handy to have plan B for forthcoming fall. What are the ideas from abroad?

Tasking manager for field data

Posted by pedrito1414 on 15 June 2015 in English (English)

Just a musing on a tasking manager software, but for field data instead of tracing.

With the amount of data we are expecting to come back from the Soputh Kivu mapping, we need better tools and processes for getting it into OSM

If this rings bells with anyone, please feel free to get in touch...

Field data tasking manager concept

The need:

So far Missing Maps field data editing and uploading is fairly randomly done, using a combination of wiki pages, data in dropbox folders, scanned field papers.

On a small scale, this can be effective (and has been). However, as we start to get more and more data back from the field, and as field data becomes a normal part of mapathons / armchair mapping, this model doesn’t scale well.

It relies far too much on the person managing the project being present to explain the data and the system for uploading it. It also relies on individuals to carefully document how much of the data they took responsibility for they actually edited / uploaded.

The / One solution:

The HOT tasking manager is a great example of how software can solve problems in a crowdsourcing / microtasking environment. Whilst there is always room for improvement, its fundamental raison d’etre means that large tasks can be worked on collaboratively by many individuals at the same time.

One solution to the scaling of editing of field data is a task manager for field data that chunks up geographical areas and then presents data relevant to that area, whilst providing instructions on purpose and process.

What would this look like?

The user signs in and elects a task. The task displays with instructions and purpose. The user chooses a square from a grid. The TM displays the types of data availabkle in that square. The user then confirms their choice and locks it or chooses an alternative square.

One the square is confirmed the current OSM data for that area is displayed on the screen.

Also displayed are the types of data that are available for that square (this could be gpx, odk shapes, field papers, OpenMapKit). The user chooses the data type and it displays as a layer. The user then begins to add the data that he/she has been instructed to add.

If the user finds the object to be added (ie a building) is already in the OSM data set, he/she adds the relevant tags and saves. If the building does not exist already, the user uses imagery to try to locate it. If successful he/she adds the object and tags and saves. If the object still cannot be found, the user flags the object for further investigation, filling out a short comment. This comment is then communicated to the manager of that task.

If the user finds/creates the object but has problems tagging, s/he flags the object for further investigation, filling out a short comment. This comment is then communicated to the manager of that task.

Possible workflow for a field data tasking manager

If the user finishes editing / uploading a particular data set (eg gpx), then s/he can mark this as done. Then, the user can either move on to a different set of data or unlock the square. If s/he finishes all the data for the square, then s/he marks the square done. If the user finishes their session without completing a data set, they unlock and add a comment.

Older Entries | Newer Entries