1 Realtor in Austin Texas - Rima Bhavsar. Archomzz.com is her company name where she lists properties of Austin, Leander, Cedar Park, Lakeway and nearby areas.

This is part of a series of blogs about my journey working on a collaborative Field Mapping tool, now called FieldTM:

pt1 here.

pt2 here.

pt3 here.

pt4 here.

Field Mapping: The Past

Paper Era

• People actually used to have to write things down on paper, remember information in their heads, and talk to one another - damn! However ever did they manage?

• In all seriousness, coordinating a mapping campaign before the 1990’s was probably a logistical nightmare. Paper maps, scrawled notes by field teams that had to be coordinated at the start of the day, then sent on their way.

• No doubt, labour intensive and prone to error.

Digital Transition

• With the advent of handheld GPS devices in the 1990s and early 2000s, digital coordinates could be logged in the field.

• Paired with rugged PDAs or laptops running early GIS software like ArcPad, fieldwork became more accurate and geospatially aligned - but the workflow was still often clunky and required post-field data syncing.

  

Open Source Innovation

The open-source movement brought in new players.

• Tools like OpenMapKit (OMK) allowed for tagging OpenStreetMap (OSM) features in the field using smartphones (built on ODK - more on this later).

• Portable OpenStreetMap (POSM) enabled completely offline OSM editing and syncing using OMK, ideal for humanitarian deployments without internet access.

• These were excellent technical advancements for the open mapping sector. Using open-source tools such as OpenDataKit underneath, they were probably the first good solution for field mobile data collection.

• However, OMK and POSM did have a number of issues and were quite difficult to maintain, meaning the projects failed somewhere between 2014-2017.

  

Field Mapping: The Present

Field Mapping Today

• Now we have excellent tools on the scene like QField for grass-roots field mapping of new features and StreetComplete / EveryDoor / Vespucci to verify and enrich data through on-the-ground tagging.

• We also have the most awesome community-lead open-data geo repository the world has ever seen: OpenStreetMap.

• OpenDataKit (now ODK) has also gone from strength to strength, as the best tool for structured mobile survey data collection in the field.

• A small breakdown of available tools has been written here

The Field Mapping Tasking Manager

Field mapping has always been messy: tools are fragmented, offline workflows are fragile, and coordination is hard. HOT’s FieldTM attempts to solve all of that in one tool.

The full timeline of development can be found here, along with the info in the linked previous blogs in the series.

The short summary is:

• FieldTM development started as a prototype in late 2022.

• It was already clear to us that ODK had nailed the mobile form data collection part. What was missing was a coordination layer, to assist teams keep track of large mapping campaigns.

• We wanted to merge the successful concept of ‘tasking’ users, from the Tasking Manager, with the actual data collection part being outsourced to ODK.

• A big development push was made in 2023 to produce a usable tool.

• Since then, FieldTM has come on leaps and bounds, with many successful large scale mapping campaigns under it’s belt.

  

FieldTM Case Studies

Slum Mapping In East & West Africa

• We had many projects mapping informal settlements in Sierra Leone, Tanzania, Ghana.
• The common denominator of these projects was long-form survey questions, developed in order to collect detailed information about informal settlements in and around cities.
• These projects involved partnering with Slum Dwellers International and various other local partners for the work, with teams of mappers being deployed into the local communities.
• Goals ranged from the empowerment of marginalized young people – particularly young women – from slums and informal settlements, to household surveys to generate high-quality geospatial data aiding humanitarian action.

Municipal Settlement Mapping in Nepal

• This was a huge project in the Tokha municipality, Nepal, alongside our closest software collaborator NAXA.
• The goal was to map around 30,000 buildings and associated roads in the region, as part of a large government data collection program.
• An overarching aim is to use this data to assist in the creation of an addressing system for the recorded households.
• As of 07/04/2025 over 20,000 buildings have been mapped by mapping teams as large as 50 people.
• This project was an overall success, and can be seen as a great example of FieldTM’s efficacy as a large-scale census data collection platform.
• Many new requirements were added to FieldTM as a result of this program, and lessons learnt, significantly improving user experience as a result.

Favela Mapping In Brazil

• This project is in its early stages, due for kick-off with the mapping around June 2025.
• We gathered a large list of requirements from the Mapa da Periferias team in Brazil for this one.
• Amongst the many new features developed and under development, we have the introduction of API tokens, private projects, user invites, and integration of ODK Web Forms: a very large shift in how FieldTM will be used.
• Instead of requiring two apps (both FieldTM and ODK Collect), from the user perspective, this change will allow for the seamless data collection all within the FieldTM application, with a web-based survey embedded into FieldTM.

Field Mapping: The Future

Based on our positive experiences, we really believe FieldTM to be the future of coordinated field mapping.

This is particularly true for the main use cases we have seen so more: governmental regional-level dwelling and infrastructure surveys.

Going forward we would love to go back to our roots and really optimise the OpenStreetMap workflows. FieldTM was originally envisioned as an OpenStreetMap-centric tool, but with user demand, we quickly saw the scope expanding.

FieldTM Future Developments: Sneak Peek

You can get a general idea for where the tool is going via our roadmap

However, as a higher level description of some awesome features incoming would be:

• Heavily leaning into the local-first development paradigm. This means optimising the offline-first and local experience first above all else. Data on your device is owned by the user, with much less reliance on cloud servers and loading spinners.

• Real-time collaboration via live mapping updates. How cool would it be to see an avatar of your colleagues walking around the map on your device, while you are coordinating with them? Plus features changing colour as soon as they are mapped. We could make that a reality, given time.

  Note

  We already have a partial implementation of this in place, where features turn green once mapped. Real-time updates of mapping events are sent to each users device, with a particular focus on the mobile (mapper) view.

• OpenStreetMap optimised workflows, including pre-defined forms that match available OSM tagging rules. Your next mapathon or mapping social could revolve around field mapping in your local area.

Want To Help Us?

To help us achieve all of this, we rely heavily on the expertise of our parners, and the community of users, developers, technical writers, testers, and supporters!

If you feel you could be one of those, please don’t hesitate to reach out to a member of our tech team at HOT - we are a friendly bunch 😊

We also have a huge slack community to engage with, and many contribution guidelines and documentation that could help you decide where to start.

Tools for the community, by the community 👩‍👩‍👧‍👦🤗🌍🤝

Jo White MP Worksop Office

Kirtlington is not very well mapped Nor is weston on green business park - depends how much detail, e.g. compare to iSlip

Você já parou pra pensar no que essa imagem representa na vida de quem tenta encontrar um endereço e não consegue?

Você já parou pra pensar no que essa imagem representa na vida de quem tenta encontrar um endereço e não consegue?

Pra quem mora em um bairro onde a rua sequer tem nome no mapa? Pra quem chama um Uber ou 99 e o motorista não encontra o local? Ou pra um estudante que precisa fazer um trabalho de faculdade, mas as ruas da sua comunidade nem aparecem direito no mapa? Isso tem um nome: dignidade.

Dignidade é poder dizer onde você mora. É receber suas compras online.

É chamar um carro de aplicativo sem preocupação. É poder passar seu endereço pra um amigo, pra um parente, pra um vizinho. As prefeituras, o governo estadual e federal deveriam olhar com mais seriedade para o registro de ruas, bairros, vilas e distritos. Se isso fosse feito de forma justa e abrangente, o Brasil não seria esse imenso vazio cartográfico, onde tantas ruas seguem sem nome.

Felizmente, estamos aqui pra mudar isso. Estamos mapeando ruas, bairros, vilas e distritos no OpenStreetMap, com o objetivo de dar nome ao que existe — e dar dignidade a quem vive nesses lugares.

Porque todo mundo merece dignidade. Fica aqui o meu pedido: que todos os órgãos públicos e empresas que possam colaborar com esse projeto de mapeamento colaborativo se unam a nós.

Juntos, podemos construir um mapa mais justo, mais completo e mais humano.

hashtag#Vem se juntar a nós, entre em contato conosco! E-mail: contato@umbraosm.com.br

Grupo Telegram: https://t.me/grupoumbraosm

Instagram: https://www.instagram.com/umbraosmbrasil

Site: www.umbraosm.com.br

Canal Youtube: https://www.youtube.com/@umbraosm

筆者は、この表示の存在を当たり前のものと認識していたのだが、実際は日本固有のものらしい。
設置は航空法施行規則第79条十七（e-Gov）に定められており、日本国内のほぼすべての空港にあるようです。この規定について、上位存在となる国際条約などは確認できませんでした。また、AIPドキュメントでも当該表示について言及を確認できませんでした。

タグ利用による地物の明示

aeroway=navigationaid
navigationaid=id
inscription=(実際の表示文字列)
colour=(文字色)

この組み合わせでのエリアタグ付けとしました。 navigationaidがVisual航行向け支援の要素が強いということ、
AIPドキュメントで id = 識別・標識 という訳語が充てられていること、
から決定しました。

マッピング

脳内の日本国内飛行場一覧をたどりながら北から南へ、鹿児島県までをプロットしました。
一部空港では設置が確認できなかったこと、および、低木植樹による表現をしていると思われる地物についてはいったん見送りました（長崎など）
また、日本国外になりますが、韓国の済州島および仁川でそれぞれ表示が航空写真で確認できたため同様マッピングしました
変更セットは #164596461 と #164600841 になります

了

Am the community leader. I participate different meetings organized by unique mapper network. E.g organized orientation for new babies. And I also joined with the meeting today.

เครือข่ายมือถือ

Ich habe versucht den Möhnetalradweg einzutragen: osm.org/relation/18945126 und dann festgestellt, daß jemand anders das an anderen Stellen auch schon begonnen hat: osm.org/relation/12548746 Wie fügt man das Ganze zu einer einzigen Relation zusammen, ohne daß alles einzeln als Handarbeit erledigt wird?

On the 28 of March, I just discovered that our Village is not well represented in the wikipedia map, as well as the article about our community on wikipedia is not comprehensive, as i was researching further about my local community online.

That was the beginning of my journey on openstreetmap, as I’ve decided to become a contributor to help improve the visibility of our community on the world map.

Though I’m starting as a novice as at today been the 4th of April, 2025, I’m determined to walk myself through the process of learning how to edit on open street map. As I’ve started on a self learning steps, I look forward to maybe joining a community of mappers, finding someone as a guide and becoming a full member of openstreetmap community.

Геоинформационный портал Калужской области - набор электронных картографических сервисов, обеспечивающих открытый доступ заинтересованным пользователям к массиву пространственных данных нашего региона посредством глобальной сети Интернет. Сссылка

Реестр парковок г. Калуги

Реестр сведений о парковках общего пользования, расположенных на территории муниципального образования “Город Калуга”.

Ссылка

Комплексная схема организации дорожного движения города Калуги

Содержит перечень дорог с их категорийностью и другими характеристиками (см. файл Отчет КСОДД).

Ссылка

АО “УКОН”

Информация о городских ярмарках и банях.

Ссылка

This blog post is part of a series of blog posts about the new OSM file format “OMA”. This is the fifth post. At the end of the article you’ll find links to the other blog entries.

 

When relations where introduced (in 2008, if I remember correctly) I was a big fan of them. They sounded great and promising. Meanwhile I think, it was a mistake to add relations, and if I where to decide I would probably remove them from OSM and replace them with something better.

Let’s have a closer look: Nodes and ways (and areas) are simple: A geometry with some properties. Relations do not share this simplicity. They share the properties, but they do not have their own geometry. Instead, they contain references to some elements. This makes things complicated.

I could write several articles about relations and why I think they are a bad idea, but this article is about relations in Oma files, so I’ll leave it at that for now.

 

Multipolygons

Instead, I’m going to take a closer look at what is currently done with relations. According to taginfo, more than half of all relations are multipolygons, that is, a collection of areas. Since we’ve already got areas in Oma files, this is easy to handle: All multipolygons are converted to one or more areas.

You may be wondering why I didn’t add a multipolygon (or multiarea) data type. Well, in the case of nodes and ways, OSM does not have a multi variant. So I do not see why we should treat areas differently. (Please note that areas in Oma files can contain holes, while in OSM the ways that form areas cannot.) All in all: For me it is much more straight forward to omit multi-variations everywhere.

 

Restrictions

Coming back to taginfo, the second place are restrictions. They make up about 16% of all relations. Typically, restrictions contain two ways (called from and to) connected by one or more elements (called via). Restrictions tell users whether or not they can continue their journey in a particular direction.

After thinking for a long time about how to fit them into Oma files, I realised, that the from and to ways are not completely needed. Only the last segment of the from element is used and only the first segment of the to element is used. Once I realised this, it’s obvious, that restrictions are just ways, with the first and last segments playing a special role. And so I decided to convert restrictions to ways.¹

 

Routes

Next on the taginfo list are routes. They are difficult to convert, and for a long time I didn’t know what to do with them. Unlike multipolygons and restrictions, they are not just a geometric replacement for another type: In the case of routes, the tags of the members can be important. In other words: They are real reference types.

Until now, the Oma file format was a reference-free format. I reluctantly accepted that I had to add some references here. In OSM files the references point from the relation to the members. This is problematic in Oma files, because some elements have been split, so the IDs wouldn’t be unique any more. And anyway, IDs were not needed at all up to here.

So I turned the references around: For this type of relation, they now point from the members to the relation, or collection as I call it in Oma files.² This is better, because now only the collections need to have an id. This saves space and the ugliness is at the place, where the ugly elements are.

The drawback of this approach is obvious: when you’ve got a collection, you do not know the location of the members, so you need to search the whole file for them. To avoid this, I have added a slice description list to each collection. This list tells you, which slices contain the members of the collection and thus can speed up the search.

Development of this part is still ongoing. The current implementation of the converter does not compute this list, and so searching the whole file cannot be avoided at the moment. The problem is that calculating these lists is not easy and probably needs a fourth step in the converter. I hope to find the time to implement this in the near future.

 

Boundaries

On with the show: Next are the boundaries in taginfo. Boundaries are almost the same as multipolygons. The only difference is a few small additional elements, in most cases just the admin centre.

Once collections are set up, the solution here is simple: Convert all members that resemble multipolygons to areas and make a collection of them and all other elements.

 

Public Transport, Destination Signs and other Relations

There are two other types of relations left: public_transport and destination_sign. Public transport relations are quite new, and if I were to predict the future, I’d say they’re going to cause some trouble. However they are here and I have decided to treat them similar to routes as a collection.

Destination signs, on the other hand, are quite similar to restrictions, except that they can contain the location of the sign. So I created some ways from the restriction like members and made a collection out of them together with the sign position.

I didn’t look more closely at the other relations. They are not used much anyway. The converter converts them to collections.

See also

• A New File Format for OSM Data
• Using the Oma Library
• Getting Files in OMA File Format
• The OMA File Format

---

1. It’s possible for restrictions to contain more than one from or to ways. In this case more than one way is created in Oma files. ↩

2. Some months ago Netzwolf suggested this for OSM data. I don’t know if he invented it or someone else. ↩

مراعي ابل

مراعي حيوانات

مراعي

En el contexto de una clase de Cartografía Digital que estoy dictando en una institución de educación superior, les mostré OSM a mis alumnos para que sepan de este interesante proyecto que yo conocí el 2019. No me había interesado mapear hasta ahora que vi que falta mucha información y además que la existente contiene muchos errores.

طرق

سيارة قديمة

مياه امطار