prince of university

Cette entrée a pour but de répondre à une question posée sur le forum, mais rédigée pour donner plus une vue d’ensemble de l’activité qu’une simple description des méthodes.

Appréciant particulièrement la micro-cartographie, les cheminements des piétons ont naturellement fait partie de mes préoccupation depuis presque les débuts de ma contribution. Mais la tâche était immense (surtout pour une agglomération de la taille de celle où je résidais alors) et je ne passe pas tant de temps que ça dehors avec un ordiphone à la main…

Groupe local et évolutions techniques

Mais depuis, plusieurs choses ont évolué.

J’ai découvert StreetComplete, qui contient plusieurs quêtes sur les trottoirs et passages piétons (en particulier l’accessibilité de la bordure entre l’un et l’autre). Plusieurs utilisateurs au sein du groupe local angevin utilisent StreetComplete — notamment Sébastien Chopin, qui sillonne littéralement l’agglomération.

En particulier, ces utilisateurs qualifiaient le filaire là où il existait déjà et ne pas avoir cette possibilité partout en fonction des filaires créés ou non était dommage.

D’autre part, la qualité des orthophotographies disponibles s’est nettement améliorée, les trottoirs et passages piétons étant généralement parfaitement visibles.

Et enfin, le groupe angevin est plutôt intéressé dans l’ensemble aux questions d’accessibilité. Sébastien Chopin — toujours lui — entreprend même des démarches d’acquisition de matériel spécifique.

Débroussailler

Dans ce contexte, la cartographie à grande échelle des cheminements piétons est redevenue un de mes sujets d’intérêt.

J’ai donc commencé à planifier une modification d’envergure sur la commune d’Angers pour ajouter autant de filaires de trottoirs et de passages piétons que possible à partir des imageries disponibles.

J’ai décidé de travailler rue par rue, en regroupant plusieurs rues proches (pour éviter les bounding box englobant toute l’agglomération) dans un unique changeset. Un petit script tout bugué les a regroupées comme il a pu et me permettait ensuite de charger l’ensemble d’un groupe d’un coup dans JOSM via la télécommande.

Après un petit ajout de tous les segments dans la liste de travail et en activant le style « Sidewalks and footways (with knobs on) » pour bien voir les données, il ne restait plus qu’à les modifier.

Un des objectifs étant de pouvoir faire progresser les données d’accessibilité et appréciant la micro-cartographie, j’ai naturellement utilisé le modèle où un petit bout de footway=sidewalk va jusqu’à la bordure pour chaque footway=crossing, qui permet de décrire la bordure séparément pour chaque passage piéton et au bon emplacement. Certains trottoirs existant déjà (principalement en centre ville), je les ai normalisés vers ce schéma lorsqu’ils ne l’utilisaient pas.

Pour éviter des chemins trop courts (du centre du trottoir à la bordure, parfois difficile à interpréter dans des interfaces comme celle de StreetComplete) ou trop longs (tout le tour d’un pâté de maisons, nécessitant un redécoupage ou un tour complet à pied pour certaines quêtes avec StreetComplete), j’ai également pris l’habitude de couper le chemin du milieu de trottoir à chaque passage piéton, le faisant bifurquer vers la bordure et commençant un nouveau chemin de milieu à la bifurcation.

Comme ces modifications ont couvert quasiment l’ensemble du territoire de la commune, elles ont souvent ont également été l’occasion de détecter et corriger d’autres soucis : bâtiments mal découpés lors de l’import du Cadastre, élément nouvellement construits ou détruits, etc.

Voici un exemple de modification que ça a pu donner : 150591361.

Enfin, à certains endroits trop difficiles à cerner depuis une photographie aérienne, j’ai laissé une note afin de passer sur place voir ce à quoi ça ressemble. Je crois en avoir traité la majorité — au moins à Angers — depuis.

Jardiner

Après ce travail initial, il reste tout le travail de terrain pour améliorer la donnée : passage sur place avec StreetComplete ou autre pour compléter les données manquantes et détecter les erreurs. Je dois avouer que je laisse largement cette partie à d’autres, faisant confiance à l’action collective.

Ce travail a largement commencé, en témoigne la quantité de bordures déjà renseignées et quelques notes indiquant des erreurs, mais est également loin d’être terminé. Il suffit de voir le nombre de bordures qui ne sont pas encore renseignées ou les notes où je procrastine…

Et ensuite

La cartographie de fauteuil a l’inconvénient de produire plus d’erreurs qu’en partant du terrain. La couverture Panoramax d’Angers, qui aurait pu aider, bien qu’en discussion depuis un certain temps au sein du groupe local, est malheureusement encore loin d’être réalisée.

Et en effet, plusieurs notes créées après coup montrent que j’ai pu pêcher par excès de confiance dans certains cas. Je devrais probablement ajuster mon sentiment concernant les endroits trop difficiles à cerner pour l’avenir.

Cependant, cette méthode a permis de jeter les bases — pas trop erronées — d’une amélioration progressive que je crois en mesure de produire d’excellentes données d’ici peu. Ce qui semble être confirmé par le récent premier retour de la part de SonarVision.

En dehors du jardinage déjà évoqué, le travail sur l’agglomération ne fait que commencer : l’ajout de filaire initial concernait Angers même, mais les autres communes pourraient également bénéficier de ce traitement. J’ai déjà commencé sur certaines, mais il reste quantité de travail.

Whenever I use files containing OSM data, I’m faced with two major problems. These problems are inherent in the OSM data model and inherited by the common file formats (.osm, .o5m, .pbf).

The first of these problems is about accessing the data: As a result of the data model users are forced to use either huge amounts of memory or a lot of time. Often even both.

The second problem is even worse: Quite often you have to guess properties of the data, which means using heuristics. But by their very nature, they can lead to wrong results. The most prominent example is probably the question, if a closed way element represents a linear object or an area.

To overcome these problems I invented a new file format. The main idea: Convert the data once (accepting the drawbacks caused by the two problems) and end up with data that can be processed fast, using only little memory. I also tried to keep the file size small and the file format simple.

I called the new format “OMA format” like “Open MAp”. It’s accompanied by a human readable version called “OPA format” like “Open PAper”. (Oma and Opa are the German words for grandma and grandpa).

It took me about a year to design the Oma file format, and write a converter and a library for querying the new file format. I still consider it in experimental state, as I would like to get some feedback before releasing a stable version. Hence this post.

All this is a lot of stuff and I can’t go into all the details in just one blog post. For this reason I’ve decided to keep this article brief and base it on a single example. In the coming weeks, I will be writing more articles about the new file format, which will provide more in-depth information.

 

Scattered Data in OSM Files: The Viktorstraße in Wuppertal

For explanation I set up a simple example: I want to know everything about the street Viktorstraße in the city of Wuppertal. All I’ve got, is a dump of the extract of Germany (germany.osm.xml from 1st of January 2025¹) and the knowledge that the street is saved as a couple of way elements, each of them containing a highway tag (with unknown value) and a name tag with value “Viktorstraße”. And of course I know the name of the city it belongs to.

To get started, lets peek into germany.osm.xml:

The file is split into three parts: The first two thirds of the file are occupied by nodes, almost all of the rest is used for ways, and a tiny fraction at the end contains relations.

The Viktorstraße consists of 5 way elements, which refer to 10 different node elements. The places where these elements can be found in germany.osm.xml are marked with red lines. As you can see, they are scattered throughout the file.

In principle scattering data throughout a file doesn’t do much harm, as long as there are means for fast (that is direct) access. Unfortunately, this doesn’t apply for OSM files: In almost all cases, you have to read the entire file from the very beginning without being able to skip any parts.²

Even worse, the data in the ways section references data in the nodes section that has already been read, when the references are read. This means that you don’t know, which part of the information read in the nodes section you will need later.

Basically, this can be handled in two ways:

1. Keep the first part of the file completely in main memory (you need gigantic amounts of memory).

2. Read the file a second time (takes a lot of time). In this case, a new problem arises: You have to keep the references of the way part in memory while you retrieve the nodes they reference from the nodes part. In the case of the Viktorstraße it’s only 10 references, but a lot of use cases consist of millions (or even billions) of references and again you need huge amounts of memory.

 

A First Step Towards a Solution: Resolving the Node References.

OSM ways consist of a series of node references (that is, a list of node IDs). The first thing the converter does is to replace these references with the coordinates of the nodes to which they refer. This leaves a lot of nodes in the nodes section without any further use. Therefore these useless nodes are discarded.

The same is true for some relations, where not only the node references are replaced by nodes, but also the way references are replaced by ways. (There are more changes to the relations section, but I won’t go into that in this article.)

The result can be seen in the following diagram:

The data of the Viktorstaße is now completely contained in the ways section. This makes it possible to retrieve the data with a single pass using only a small amount of memory. However, the data could be anywhere in the ways section and you still don’t know where this section starts, so almost the whole file has still to be read in.

 

Second Step: Dividing into Chunks

If you look more closely at the data in the ways section, you will notice that completely unrelated way elements are located directly beside each other. For example, next to a street in Wuppertal there could be a park in Munich and then a construction area in Pulsnitz.

A better approach would be to sort the data geographically: Things that are close together in the real world should also be close together in the file. Unfortunately the world is not one-dimensional, but the file is.

One solution to this problem is to divide the data into regions and store all the data in one region together. The Oma file format uses chunks for this purpose: The data in a chunk is bounded by a rectangle on the earth’s surface (better known as a bounding box). Only data that is completely within this bounding box is saved in the chunk.³ A chunk table allowing direct lookup of the chunks is added to the file.

If you now want to find the Viktorstraße, you only need to search for chunks that overlap with the bounding box of Wuppertal. With the default bounding boxes there are three of them: A large one (actually the largest chunk in the file, containing Wuppertal, Cologne and the whole Ruhr area) and two small ones at the end of the ways section which are barely visible in the following diagram:

In this diagram, the boundaries of the chunks are marked by black lines, chunks that could contain data of the Viktorstraße are coloured pink. At the end of the file, there is a small chunk table, not visible in the diagram (because it is very small). All in all: Now only about 9% of the file needs to be searched.

 

Third Step: Dividing into Blocks and Separating Areas and Ways

Within a chunk, the data is still unordered. This means that next to a highway there might be a power line or a shop or whatever. Accessing the data could be speed up again if all the highways were put together, and so on. And this is the next step, what Oma files do: Within a chunk all elements of the same type are put into one block.

Unfortunately the OSM data model does not provide information about the type of an element. So we have to guess. This can be done by scanning a list of keys for a match – if the element contains a highway key it’s a highway, and so on.

But sometimes, there is no match, and sometimes there is more than one match. This is how the Oma file format deals with this:

If there is no match, the solution is simple: Oma files put all elements without a type in an extra (typeless) block.

Dealing with several matches is trickier: You could decide to take only the first matching key as the type or you could repeat the element and put it in several blocks. Since there are pros and cons to both versions, the Oma file format leaves this decision to the user. The default is to add elements to several blocks, which we use in the diagram below.

But before we look at the diagram, we need to discuss an other topic: The question of whether a way element represents a linear element or an area. With the help of the type information this can be decided in most cases, but it is still some guesswork. Since ways and areas are something completely different, Oma files put them into different chunks.

Now we are ready for the diagram:

The way chunks from the last diagram have been split up in area and way chunks (area chunks are coloured blue, way chunks are coloured yellow). At the bottom of the diagram, the largest of the three way chunks that could contain the Viktorstraße has been enlarged to show the block structure.

As the Viktorstraße is made up of ways only, the search for it can be narrowed down to three smaller (way) chunks. In these chunks only the highway blocks need to be searched. That reduces the search to about 1.8% of the file.

 

Fourth Step: Dividing into Slices

There is one last thing to do: Again, the data inside of a block is not sorted, and we could do this by looking at the value of the key, which defines the type of the element: All highways of type service are put into one slice, all highways of type track are put into the next slice, and so on.

This works well as long as the slices created are large enough. Since the OSM data modell is open for new inventions, there are a lot of values that are only used a few times. If we were to put them all into separate slices, this would create a lot of overhead. Therefore, only values which are known to be used frequently are put into separate slices and all other values are put into a special slice with no fixed value.

Our example doesn’t benefit from this additional sorting, because we don’t know, what type of highway the ViktorstraÃe is. But if we had known, that it is a residential highway, we could have narrowed our search again.

The following diagram shows the slices in the highway block from the previous diagram:

 

Finally: Some numbers

That’s basically all about the Oma file format. You may wonder how long it takes to convert OSM files into Oma files, how much space they use and how long it takes to query the Viktorstraße. Well, I have collected these numbers for you.

I used germany_internal.osm.pbf taken from Geofabrik from 1st of January 2025 (contains full meta information) and converted it into Oma files three times.

For the first conversion I used the default, which means, that no meta data was saved (not even the ID) and elements with multiple types have been saved multiple times.

For the second conversion I used the command line parameter -p all, which means that all meta data was included and elements with multiple types have been saved multiple times. This results in the largest possible Oma file.⁴

For the third conversion I used the command line parameter -1, which means that no meta data was saved (not even the ID) and elements with multiple types were saved only once. This results in the smallest possible Oma file.

The conversion times are the times required on my computer.⁵ If done with a faster CPU and more main memory, the times would decrease significantly. For comparison I added germany.osm.pbf, the publically available version which contains restricted meta information.

File	Size	Conversion time
germany_internal.osm.pbf	4.9 GB	—
germany.osm.pbf	4.1 GB	—
germany.oma	2.9 GB	0:57:14
germany.largest.oma	3.8 GB	1:20:44
germany.smallest.oma	2.7 GB	0:51:47

Querying the Oma file for the Viktorstraße took 5.3 seconds with germany.largest.oma and 4.6 seconds with germany.smallest.oma, including the time to extract the boundaries of Wuppertal from the same file.

Now I’m curious to read your comments.

See also

• Using the Oma Library

---

1. The use of germany.o5m or germany.pbf will basically lead to the same result. They differ from germany.osm.xml mainly in the way they compress the data. ↩

2. With the help of something resembling a binary search algorithm it might be possible to access parts of the file in logarithmic time. Unfortunately, these algorithms are prone to mistakes or even complete failure. ↩

3. If you wonder, what happens with elements that do not fit completely into a chunk: They will be saved in a larger chunk, if necessary in the last chunk which spans the whole world. ↩

4. Well, that’s not completely true: I used compressed slices in all versions. Without compression, Oma files get much larger. ↩

5. 4 GB of main memory, Intel(R) Core(TM) i3-7100T CPU @ 3.40GHz. I used only 3 GB of main memory for the Java Virtual Machine. With more memory, the operating system starts swapping, slowing things down considerably. ↩

My personal enemy that I take so serious, is someone who edits an area on a map as “under construction” and then it SITS for longer than 6 months in that stage. In some cases people have been living in that neighborhood for 3 years…and it’s been marked as “under construction.” Here I am today fixing areas that are fully developed now, fully established- and the average of the construction edits were made 2 years ago. Here’s hoping doordash, my personal use favorite Strava, or even pokemon go run an update for those poor folks.

This is purely a diary rant about residential areas and their roads not being updated. I almost wish there was a way to make “under construction” just be something for an existing thing being updated/fixed, not something being built. We’re mapping what’s there to be mapped. I’d rather new developments or roads have like a “coming soon” tag of some sorts that wouldn’t block in app access.

We can use strava as an example, i’ll set a route and it’ll make me avoid an entire neighborhood because “Deleted User” 3 years ago marked these 7 streets near the lake trail as “under construction.” Took me a sad amount of time, admittedly, to realize what was happening. Another example is Niantic not having in game spawns (pikmin, pokemon, ingress) if an area is marked “under construction” because the game labels the area as dangerous, so why would they give server room to RNG spawn their in game items there? Reality though is Ash can and SHOULD be able to catch his Pikachu there because he’s been living there for 3 years- Niantic just doesn’t think it’s safe.

So, here’s my little rant about the amount if neighborhoods i fixed today that i have personally been to, biked through, walked my dog through, that have been “under construction” the last 28 months.

I finally got back to mapping, after about 6 months of being inactive. I’m really happy!

Hoy desarrollamos nuestro evento Open Data Day 2025: Escuelas en el mapa, un camino a la resiliencia en la Institución Educativa Ciudadela de La Paz, en Pasto, Nariño. Por segundo año consecutivo, desde el capítulo YouthMappers SAGEMA, apoyamos el diseño metodológico de la participación de la comunidad OSM Colombia en el Open Data Day, esta vez con un enfoque en el uso de datos abiertos en entornos educativos.

Junto a los estudiantes de grado 9, recorrimos la institución utilizando Mapillary, demostrando su importancia como herramienta para capturar imágenes inmersivas y mejorar la visibilidad de la infraestructura escolar. También empleamos Field Papers para mapear la distribución de espacios clave como baños, laboratorios, oficinas, salones, caminos, el restaurante escolar y la tienda.

Uno de los momentos más significativos del taller fue la participación de Yireh, una estudiante con capacidades físicas y cognitivas diversas, quien mapeó el bloque administrativo de la escuela. Su atención a los detalles, especialmente en la señalización de las gradas, me reafirmó la importancia de los mapas no solo para comprender nuestro entorno, sino también para identificar barreras y oportunidades de inclusión.

Este año, aplicamos el mapeo participativo con niños, adolescentes y jóvenes en seis ciudades de Colombia, siendo Pasto una de las ciudades participantes. Toda esta información quedará disponible en OpenStreetMap (OSM), permitiendo que los estudiantes accedan y actualicen continuamente los datos. Democratizar el conocimiento y fortalecer la resiliencia de las comunidades ante la policrisis es el motor que impulsa este proyecto. La metodología utilizada y la información recopilada en otras ciudades estarán disponibles en nuestra wiki: Wiki ODD 2025

Agradezco a la Asociación de Cartografía Colaborativa de Colombia por permitirme liderar este proceso, a TOMTOM por su aporte económico, y especialmente a Adriana y Yovani por hacer posible este espacio en la Ciudadela de La Paz. Como YouthMapper, seguiré empoderando a las juventudes e infancias en el uso y la apropiación de las tecnologías geoespaciales de uso abierto.

💚 El voluntariado no llena el bolsillo, pero llena el alma.

– In English

Mapeamento de árvores no OpenStreetMap e palestras especiais

---

O evento será realizado em 31 de março de 2025, com atividades presenciais e remotas, pensadas para despertar para a importância dos dados abertos na dimensão ecológica, para fins de colaboração para a conservação ambiental e a melhoria da qualidade de vida dos habitantes, frente às consequências evidentes da crise climática, que têm piorado as condições ambientais nas cidades e levado ao aumento da pressão por recursos, especialmente, os energéticos.

🌳🌳🌳🌳🌳

Serão concedidos dois certificados independentes (manhã/noite)

Inscreva-se até 30 de março de 2025, 23h59 (UTC-3). Vagas limitadas (20) para a atividade presencial (manhã). Para a atividade da noite, sem limite de vagas. LINK DE INSCRIÇÃO – Página do evento

🌳🌳🌳🌳🌳

Apresentação

O evento Green Open Data Day 2025 (ou Dia Verde dos Dados Abertos 2025) é uma realização do Instituto Virtual para o Desenvolvimento Sustentável – IVIDES.org, em parceria com a Open Knowledge Foundation, os capítulos YouthMappers UFRJ, UFRRJ e UFF Campos (Campos dos Goytacazes), grupos de jovens mapeadores(as) de universidades públicas do estado do Rio de Janeiro, afiliados ao projeto internacional YouthMappers. O evento insere-se no âmbito das atividades do HUB YouthMappers Rio de Janeiro, que conta ainda com os grupos YouthMappers UERJ e UFF Niterói.

Sessão diurna: trabalho de campo para mapeamento de árvores, utilizando APPs para OpenStreetMap

Nessa via, o evento tem inicialmente seu foco em um treinamento presencial, a ser ofertado no campus da Universidade Federal Rural do Rio de Janeiro (UFRRJ), em Seropédica (RJ), na parte da manhã, de 9 às 11h40 (UTC-3, Horário de Brasília). Os detalhes serão oferecidos aos(às) inscritos(as). A prática será conduzida pela Profa. Dra. Raquel Dezidério Souto, em estágio pós-doutoral na UFRJ, presidenta do capítulo YouthMappers UFRJ e proprietária da empresa IVIDES DATA.

A finalidade será o mapeamento de espécies arbóreas em parte do campus da UFRRJ, em Seropédica, município da região metropolitana do Rio de Janeiro. Para tanto, será realizada uma atividade com o MapComplete, para mapear os indivíduos (árvores) diretamente na base cartográfica do OpenStreetMap (OSM).

Consideramos firmemente que a conscientização acerca do ambiente passa pela experiência prática de todos os indivíduos e a inclusão de estudantes da UFRJ, UFRRJ e UFF Campos, além dos demais capítulos do HUB YouthMappers Rio de Janeiro, promove capacitação adicional aos(às) formandos(as).

Sessão noturna: palestras especiais de temáticas relacionadas

Na noite do dia 31 de março de 2025, de 19 às 20h (UTC-3, Horário de Brasília), será realizada uma sessão remota, com pesquisadores convidados, para mostrar os resultados de suas pesquisas, em temáticas relacionadas aos dados abertos e à dimensão ambiental e socioeconômica. O evento remoto será transmitido ao vivo no canal do IVIDES.org no YouTube.

Esta atividade tem fins a sedimentar na audiência, a relevância da conservação da vegetação, de modo a ajudar na promoção dos serviços ecossistêmicos relacionados, como a diminuição da temperatura em superfície, a preservação dos aquíferos, a provisão de habitat para muitas espécies, que encontram local para pouso, alimentação e reprodução, dentre outros.

Disponibilização dos resultados da oficina

Posteriormente, à realização do evento, o material audiovisual será disponibilizado na Wikimedia Commons, para que os resultados fiquem disponíveis publicamente e com licença aberta.

Caráter educacional e inclusivo do evento

A inclusão de grupos minoritários e o caráter educacional do projeto O público alvo do evento consiste em estudantes e professores de universidades públicas e outras instituições de ensino do Rio de Janeiro, além de profissionais que trabalham com a gestão ambiental, planejamento urbano, ciência da informação, cartografia etc. Muitos dos estudantes destas universidades são de classes economicamente menos privilegiadas e, especialmente no Rio de Janeiro, por integrantes de grupos denominados minoritários (quanto à representatividade, não em relação à quantidade), como quilombolas, negros e pardos, e residentes na Baixada Fluminense, na Região Metropolitana do Rio de Janeiro, que, historicamente, apresenta piores condições de vida e indicadores de desenvolvimento humano com menores índices, se comparados com regiões com maior renda per capita, como as áreas nobres da capital, Rio de Janeiro.

Assim, o evento configura-se como uma iniciativa, não apenas para valorizar a conservação ambiental, como também para oportunizar a estes grupos, o acesso a métodos e técnicas que consistem no estado da arte em mapeamentos participativos e colaborativos, utilizando aplicativos, sistemas de informações e dados abertos, despertando para a sua relevância e utilidade, no enfrentamento das consequências da crise climática.

–
IVIDES.orgⓇ é uma marca registrada. ivides@ivides.org | https://ivides.org/

---

Since the end of 2019, the OpenArdenneMap map style has been updated on ~~a six-monthly cycle~~ from time to time. OpenArdenneMap is an open-source cartographic style for topographic maps based on OpenStreetMap data. The ‘winter 2024-25’ release has just been published.

That’s mainly small improvements in the QGIS-style that have been made. OpenArdenneMap is available for Mapnik (a software used mainly to create map tile servers) and QGIS (a more general GIS software).

In particular, there has been the addition of the ‘marked trails’ layer, which was still missing in the QGIS style. To add the marker to the map (the equivalent of the shield in Mapnik), we use a combination of 2 ‘Marker Lines’, with the superimposition of an SVG marker for the marker and a character (Font Marker) for the number often inscribed in the marker.

I have also added a map layout to the QGIS project file, which allowed to update an existing map on hiking.osm.be, for the map of Herbeumont.

Compare the version made with Mapnik a few years ago, and this one made with QGIS.

More maps coming soon at https://hiking.osm.be/!

– Em Português

Fieldwork for mapping trees with OpenStreetMap and special lectures

---

The event will be held on March 31, 2025, in Portuguese, with fieldwork and remote activities designed to raise awareness of the importance of open data in the ecological dimension, in order to collaborate in environmental conservation and improve the quality of life of inhabitants, in the face of the obvious consequences of the climate crisis, which have worsened environmental conditions in cities and led to increased pressure on resources, especially energy.

🌳🌳🌳🌳🌳

Two independent certificates will be awarded (morning/evening)

Register by March 30, 2025, 23:59 (UTC-3). Limited places (20) for the fieldwork activity (morning). Unlimited places for the evening activity. REGISTRATION LINK – Event page

🌳🌳🌳🌳🌳

Presentation

The Green Open Data Day 2025 event is organized by the Virtual Institute for Sustainable Development - IVIDES.org, in partnership with the Open Knowledge Foundation, the YouthMappers UFRJ, UFRRJ and UFF Campos (Campos dos Goytacazes), groups of mappers from public universities in the state of Rio de Janeiro, affiliated to the international YouthMappers project. The event is part of the activities of HUB YouthMappers Rio de Janeiro, which also includes groups from the universities of YouthMappers UERJ and UFF Niterói.

Fieldwork session: mapping trees using OpenStreetMap APPs

The event will initially focus on a fieldwork, to be offered on the campus of the Federal Rural University of Rio de Janeiro (UFRRJ), in Seropédica (RJ), in the morning, from 9:00 to 11:40 (UTC-3, Brasilia Time). Details will be given to those who register. The workshop will be led by Prof. Dr. Raquel Dezidério Souto, a post-doctoral fellow at UFRJ, president of the YouthMappers UFRJ chapter and owner of the IVIDES DATA company.

The aim will be to map tree species on part of the UFRRJ campus in Seropédica, a municipality in the metropolitan region of Rio de Janeiro. To this end, an activity will be carried out using MapComplete to map the individuals (trees) directly into the OpenStreetMap (OSM).

Evening session: special lectures on related topics

On the evening of March 31, 2025, from 19:00 to 20:00 (UTC-3, Brasília Time), a remote session will be held with invited doctors to show the results of their research on topics related to open data and the environmental and socio-economic dimension. The remote event will be broadcast live on the IVIDES.org YouTube channel.

The aim of this activity is to highlight the importance of conserving vegetation, in order to help promote related ecosystem services, such as lowering surface temperatures, preserving aquifers, providing habitat for many species, which find a place to roost, feed and reproduce, among others.

Making the results freely available

After the event, the audiovisual material will be made available on Wikimedia Commons, so the results will be publicly available and openly licensed.

Educational and inclusive nature of the event

The inclusion of minority groups and the educational nature of the project are clear. The event’s target audience consists of students and teachers from public universities and other educational institutions in Rio de Janeiro, as well as professionals working in environmental management, urban planning, information science, cartography et al.

Many of the students at these universities are from economically underprivileged backgrounds and, especially in Rio de Janeiro, are members of so-called minority groups (in terms of representation, not quantity), such as quilombolas, black and brown people, and residents of the Baixada Fluminense, in the Metropolitan Region of Rio de Janeiro, which historically has worse living conditions and lower human development indicators compared to regions with higher per capita income, such as the southern areas of the capital, Rio de Janeiro.

–
IVIDES.orgⓇ is a registered trademark. ivides@ivides.org | https://ivides.org/

Translated with DeepL.com (free version). Many thanks.

---

Goedendag, Sinds een tijdje verneem ik grote witte lijnen op de plattegrond. Kan iemand mij zeggen hoe dit komt en of het weer weg kan?

I’ve just rolled out some updates for waymarkedtrails, the website for browsing route relations. The most notable improvement is that waymarkedtrails is finally able to understand member roles in route relations. This post gives a quick overview of what works and what doesn’t and what has changed with in the route views.

Forward/backward roles

The first group of roles handled specially are forward and backward roles which indicate that the route follows the given way only in the direction of the way or in counterflow. These oneway sections are now shown when details of a route are displayed:

Waymarkedtrails will internally merge forward and backward sections into split sections and count them only once when computing the length of the route. However, this only works, when all ways of such a spilt section appear together in the relation and follow the order of the route. (See also the notes on ordering below.)

Roundabouts

Roundabouts are a special form of split section. They may be mapped as a single closed way with a special junction=roundabout tag and then put into a route relation as a whole without any further role. waymarkedtrails can detect these roundabouts and will automatically split them. This works correctly, even when the roundabout has an approach that has been split into oneways, like here:

However, it works only as long as the roundabout remains in one piece. If, for whatever reason, you split the roundabout way, then you must add each section with the appropriate forward/backward role or waymarkedtrails will signal an error.

Other roles

The split sections and ways without a role (or role main) together make up the main route of the route relation. All other ways are considered appendixes of one form of another. These are split into two groups: ways with an alternative role are shown with a dashed line in the route view:

All other role types are shown with a dotted line:

You can also see in the screenshots that the display of the ‘mapped length’ has changed slightly. The number now refers to the main route only. Any appendixes are listed separately by their function. This should give you a very quick overview over what kind of roles are used in the relation.

Note: waymarkedtrails still ignores all node members of the relation and makes the blanket assumption that all ways in the relation are part of the route. No exceptions for special roles are made.

Route Order

Some functions of waymarkedtrails need the route to be properly ordered. This affects in particular the elevation profile and the GPX export. Waymarkedtrails has a long-standing policy that it will only sort a route if it can be made strictly linear. Otherwise it will leave the route in the order in which it finds the members in the relation. This policy remains largely in place with two changes that make it more likely that waymarkedtrails can sort a route:

• appendix ways (those with roles other than forward, backward and main) are no longer considered for ordering
• forward and backward sections no longer destroy linearity provided that waymarkedtrails can create a proper split section for them (see above)

Rule of thumb: if JOSM shows a route is whole, then waymarkedtrails will be happy with the route as well.

Gardening your route relations

To make it easier for you to keep your relations whole and healthy, the route list gives you now a hint about the order state of a route:

A green check mark means the route is sorted and linear, all is well. The red double arrow signals that the route is perfectly linear but the route members themselves are not sorted. If member order doesn’t matter to you, then just leave it. The red cross signals a problem with the route. To learn more about where exactly the issues are, click on the route and then open the ‘Analyze relation’ tab at the bottom of the window. waymarkedtrails will add red dots where there are gaps in the relation:

Zoom into the points to find the issue. It usually is a little gap or extruding section. Cycling routes in particular have often issues with the role assignment, especially with forward and backward roles.

Where to go from here

Having fully annotated routes with split sections and appendixes will make a few other improvements possible, in particular, a more clever GPX download where you can choose which direction and role types to include. This has to wait until later. For now I wanted to push this first version in the hope that it is useful to help you maintain and improve the state of route relations.

OSM History Viewer and OSM Route Manager are two ancient tools that help visualising and analysing changesets and route relations. In particular, they provide the following features: * Show the geographic and tag changes that a specific changeset has caused * Render a route relation (with support for nested relations), detect gaps and inconsistencies, and export the route as GPX * Analyze the history of relation members and show who last edited (and is thus to blame for) which section of the relation.

I have not maintained these services in many years and they frequently crashed or got overloaded. The user experience was also far from great.

I have decided to rewrite the logic of these tools and integrate it into FacilMap. While the don’t particularly fit the use case of FacilMap, the infrastructure (in particularly the UI elements) is there, making it convenient to integrate it there.

So far I have implemented the first functionality, changeset analysis. You can analyze a changeset by typing changeset <id> (for example changeset 6798641) into the search field, or by calling the URL https://facilmap.org/#q=changeset%20<id> (for example https://facilmap.org/#q=changeset%206798641) directly. As opposed to the legacy OSM History Viewer, the analysis and API requests are now entirely performed on the client side.

I will implement the other two features soon. Once done, the old services will be shut down and a redirect will be put in place.

Feel free to report any problems that you come across by writing to me or by creating an issue.

Latest Update from Henderson.

All roads, sidewalks and parking lots were traced out. Traced out some of the park details as well. Unfortunately not too many commercial details or bing street side photos are available of this small town, so cant add too much more information such as stop signs, or storefronts.

For the next town, ill probably do something in the north north east.

Also, anyone have any updates as to when bing will work in JOSM again?

Harita güncelleme nasıl yapılmaktadır.

vir: eProstor - Javni vpogled

Dol pod Gojko

• 2024-12-20: hišne številke 1 - 4 (s soležečimi zgradbami)
• 2025-02-27: hišne številke 5 - 9 (s soležečimi zgradbami)
• 2025-03-03: hišne številke 10 - 17 a (s soležečimi zgradbami)
• 2025-03-04: hišne številke 17 b - 41 (s soležečimi zgradbami)
• dokončano

I want better local information so here I am learning and updating Open Street Maps! (4 MAR 2025)

Introduction

This diary entry describes my current view on how best to map and tag pedestrian and bicycle crossings. Best, considering detail, correctness, time consumption, clarity and usability. The many words in this diary may make it seem complicated, but the actual tagging is designed for easy and direct node tagging of what you see on the road, with as little redundancy and required expertise as possible. As follows:

A simple unmarked, uncontrolled crossing is just an intersection node without any tags.

A simple zebra can be tagged with highway=crossing + crossing=zebra (or equivalent ansd just as easy: highway=crossing + crossing:markings=zebra)

A simple crossing with other markings can be tagged with highway=crossing + crossing:markings=dots/dashes/lines/surface

If traffic lights control the crossing, add crossing:signals=yes

If there are special kerbs, add kerb=lowered/flush/…

If there is tactile paving, add tactile_paving=yes

If there is a crossing island within the crossing, add crossing:island=yes

If the crossing path goes uninterrupted over the road it crosses, so that the road is interrupted rather than the crossing path, ad crossing:continous=yes

Scope:

• Footway crossing any higher order way, including cycleway and busway, excluding rail.
• Cycleway crossing any higher order way, including busway, excluding rail.
• Mentioned, but not detailed: paths, including combined footway/cycleway paths as mapped regulary in Germany.
• Mentioned, but excluded: designated horse crossings.
• Mentioned, but excluded for now: how to map a crossing as a way.
• Mentioned, but excluded for now: detailed mapping of the operation of traffic signals.
• Mentioned: level crossing over tram railways

Basic principles:

1. Consider only nodes where a footway, path or cycleway intersects a higher order way, or would intersect if it is actually drawn as a way of its own.
2. The intersection of two ways is already a crossing node, even without any tags. It gives the location and the fact that the ways cross, and type and access/designation tags from the crossing way apply to the crossing node.
3. only add the highway=crossing tag and additional tags if there are actually attributes to tag, which do not follow (inherit) from the crossing way itself.
4. Only tag positive attributes, not missing attributes, unless: a. the applicable default values in your country differ from world-wide defaults; b. the no indicates something generally unexpected, such as crossing=no on a location that cannot be crossed.
5. All existing crossing=* schemas are flawed and form a chaotic mix, leaving data users and other mappers to guess what was meant. I use only the additional tags to describe each additional attribute. A crossing= value may still be computed from the separately tagged attributes, for any of the previously used mixed schemes.
6. For incremental mapping (start simple and add details later) crossing=zebra is acceptable as a stub for a zebra crossing. All the other crossing types have unclear meanings, because of historical differences in tagging schemes. Note that in some countries even crossing=zebra has been used systematically for non-zebra crossings!

Explanations of the basic principles

Ad 1. If a path, footway or cycleway is not actually drawn in OSM, you can still put a node on the way representing the place where the actual crossing is. In this case, it’s required to tag it highway=crossing, and preferably a tag to indicate how people can see that it’s a crossing (crossing:markings=zebra/dots/dashes/lines/surface and/or crossing:signals=yes)

Ad 2. The intersection node of a footway with a higher order way is a pedestrian crossing with access foot=designated. If the footway is tagged with bicycle=yes and/or horse=no, the crossing is also foot=designated + bicycle=yes and/or horse=no. Explicit tagging of the node with the same information is redundant, unnecessary, because the information is already there.

Ad 3. Information which warrants explicit tagging of the crossing node is: markings, signal control, tactile_paving, special kerbs, presence of a (safe) crossing island, access or designation not present on the crossing way (or in absence of the crossing way).

Ad 4. Many crossings are tagged as e.g. highway=crossing + crossing=unmarked/uncontrolled + crossing:markings=no + crossing:signals=no + crossing:island=no + tactile_paving=no. The only information there (apart from being an intersection) is that someone sometime did not see those attributes. While that is useful workflow information for a mapathon, OSM generally stores what you can see, not what you can not see, and it’s up to data users to determine what to do if they want information which is not there. We should be clear in what we tag and how, so data users can apply logical defaults. Only if e.g. a national default is clearly different from the OSM-wide default, it is sometimes wise to tag no. Tagging crossing=no (without highway=crossing) on a location where seemingly a crossing is possible: an example is a point where separately mapped cycleways are linked from both sides to the centre line representing the road. This would suggest a crossing, but that is an artefact of using short linking sections to make routing possible.

Ad 5. These special tags I often use:

• crossing:markings=zebra/dots/dashes/lines/surface /* road markings showing where to cross
• crossing:signals=yes /* the traffic over the crossing node is normally controlled by traffic lights
• crossing:island=yes /* the crossing has a traffic island, but the road has not been split around it.
• kerb=yes/lowered/flush/… /* The kerb type, important for the impaired pedestrian
• tactile_paving=yes /* presence of tactile paving to guide the visually impaired pedestrian over the crossing.
• crossing:continous=yes /* The crossing path goes uninterrupted over the crossed way; the crossed way is visually interrupted rather than the crossing path.

Tag what’s there, not what you would expect

Only tag positive values, where the expected default is no. However, for footways a kerb is to be expected, so kerb=yes on a foot crossing is redundant and kerb=no is special, to be tagged if it is seen.

bicycle=yes/designated?

In Nederland, bicycle=yes and bicycle=designated have been used a lot. I regard this as unnecessary for a bicycle crossing, because the crossing cycleway already contains that information. Only if a bicycle crossing has been mapped without a crossing way, an explicit bicycle=designated would be warranted. In Nederland, crossings without a crossing way in OSM are always pedestrian crossings. I don’t know if this default holds up world-wide, though.

highway=path

Paths crossing a higher order road can be handled according to the same basic principles. Since the access/designation of a crossing is taken from the crossing way, it only requires extra tagging if there is an exception. E.g. the path is by default allowed for pedestrians, bicycles and horses, but horses are not allowed to cross, then add horse=no to the crossing (section of the) way. If the path is for bicycles and pedestrians without segregation, but the crossing has separate lanes for pedestrians and cyclists, add segregated=yes to the crossing way, or use separate ways on the crossing. Likewise, if the path is segregated but the crossing is not, split off the crossing section and tag segregated=no on the crossing section.

Crossing node or crossing way?

I think it is acceptable to map both the node(s) as highway=crossing and the way as a *way=crossing, but tag the details on either the node OR the way, not on both at the same crossing. The exact geometry of a crossing can be mapped using the crossing way, adding way type and access as needed, possiby split into sections such as cycleway=crossing, footway=traffic_island and kerb nodes at the exact spots. My preference is to tag markings, traffic signal control, tactile paving and kerbs on crossing nodes, and to add a crossing node on every intersection node on the crossing.

Example. Suppose we have a footway crossing a secondary road that has two separate ways for the directions, a traffic island in between, and separately mapped cycleways on both sides; and zebra markings from side to side; and traffic lights for pedestrians to cross the main road, but not the cycleways. There is tactile paving all along, and kerbs are lowered.

I would draw a highway=footway from side to side, crossing a cycleway, two halves of the secondary road, and again a cycleway. I would 1. tag the footway as highway=footway + footway=crossing. 2. tag the four intersection nodes as highway=crossing with crossing:markings=zebra + tactile paving=yes + kerb=lowered. 3. additionally tag the two footway/tertiary intersection nodes with crossing:signals=yes

Now this is intermediate level of detail mapping. Other mappers might just put crossing=zebra on the intersection nodes: low level of detail (entry level duck tagging). High level of detail would be to add nodes for the exact postion of traffic lights and kerbs, splitting the footway into sections for approach, crossing and traffic_island, and e.g. tagging request buttons, sounds and vibrations.

Horse crossings

I don’t know any designated horse crossings in Nederland, although I am sure there are some. Since it would be a bridleway crossing a higher order road, I think the basics are the same as for cycleways and footways. There might be special markings, then we could simply add a value for crossing:markings. Where horses are allowed on footways, paths and cycleways, not even horse-yes would be needed. If they are -by exception- not allowed, add horse=no to the crossing footway/cycleway/path. I know that in several places high placed request buttons are present for horse riders. This is probably best tagged as a detail on the crossing nodes or on the highway=traffic_signals nodes. I don’t know an existing or proposed tag for this.

Tram level crossings for pedestrians and cyclists

In Dutch cities, many pedestrian and bicycle crossings also cross tramways. The mapping of the intersection nodes is inconsistent, to put it mildly. Let’s say that the nodes are tagged railway=crossing. Where the crossing path has markings, I simply add crossing:markings= to the intersection node. Where the tram crossing is controlled by lights regulating the flow of pedestrians/bicycles, add crossing:signals=yes. Where the tramway crossing and the main road crossing coincide, which is a common occurrence, the intersection node simply gets both the highway=crossing and the railway=*crossing tags, and the additional detail tags.

What about crossing_ref?

Nederland does not have a reference list of crossing types. The only crossing type with a nickname is the zebra crossing. Some mappers use crossing_ref to mean that it’s an official pedestrian crossing with zebra markings and either the official NL:L2 traffic sign or traffic signals controlling the two traffic streams. However, many more mappers have used it as an easy way to indicate what’s known colloquially as “a zebra” (or “zebrapad”), which does not require signs or signals, just zebra markings. In addition, no efforts are made or planned to correct the faulty usage. And we have the approved and unambiguous tag control:markings=zebra to capture the markings. All in all, the crossing_ref key is currently useless in Nederland.

Finally: Why this blog?

I have seen the ugly results of persistent competing mapping and tagging schemes for crossings, defining crossings on the basis of two independent attributes which may or may not be present, or known. Now, in Nederland, different crossings may have equal tagging, and equal crossings may have different tagging. The different mapping and tagging schemes all live on, also because different tools use the same tags to mean different things. As a result, data users cannot know what information the mapper (or their tools) had in mind and what the actual situation on the road is. Wild/ I mean educated guessing is an option, but I think most data users will just ignore the unclear features, and at most put an icon for a highway=crossing, no details. The way I map’m, there is no ambiguity in the crossing=* tag, because it is not necessary at all. Instead of guessing the attributes from the crossing= value, you could deduct the crossing= value from the mapped attributes using the scheme you like most. If you can’t assign a crossing type because you don’t know the right value(s) for markings and control, then don’t. Just tag what you now. Only one exception: highway=crossing + crossing=zebra remains as an entry level duck tag for zebra crossings. I consider it a kind of fixme note.

The latest updates from the town of Hernderson Nebraska. I believe i have around 90% of the buildings mapped. Once done, will move on to the sidewalks, parking lots, and other navigation details visible from the sky.

2025年2月22日，羅東街景踏查團在台灣維基媒體協會支援下，由 OpenStreetMap 台灣以及 Wikidata 台灣一同進行，收集街景影像以及廟宇的圖像記錄。這次特別邀請在林業管理單位工作的陳建忠，寫了兩篇 Facbook 貼文(1、2)談到他因工作關係常會獨自踏查，這次羅東廟宇工作坊則是能夠以團體方式進行，能夠彼此交流方法。而宗教專家提到宜蘭的靈場，他也列出宜蘭這一帶的分佈，發現隨著時代演進地貌已經改變，有些廟宇位置已經不在原先的位置了。

我這邊因為決定參與 g0v 大松，就沒過去羅東，遇到 ProtoMaps 開發者 Brandon Liu。我事先已經先鍵盤繪製羅東週邊了，還有當天依照臺灣宗教與民俗文化平台加台北艋舺，尤其偏大加魶一帶廟宇。Brandon 有協助 Meta 地圖團隊做事，前陣子把 Overture Maps 資料集套疊到 RapiD 編輯當中，但不知道誰用。看到我弄就趕緊拍一張照片。而我也真的編輯加了一間廟。

2025年 OpenStreetMap 台灣與 Wikidata 台灣社群會繼續合作，著重在廟宇等宗教資料的繪製工作。

Soon…