OpenStreetMap logo OpenStreetMap

Users' Diaries

Recent diary entries

Glow Heaven is a skin care Clinic in Thrissur. Under the guidance of highly qualified dermatologists, Glow Heaven offers the best treatment your skin truly needs. Utilizing high end technology and premium equipment, Glow Heaven perfects your skin. For the ultimate solution to your skin problems, trust Glow Heaven, the best skin care clinic in Thrissur.

Posted by SimonPoole on 26 February 2025 in English. Last updated on 27 February 2025.

Some of the readers may have experienced the sinking feeling when they just attempted to upload dozen if not 100s of changes and a network glitch resulted in the editor app failing the upload.

What’s the problem when that happens?

It is literally that your editing app doesn’t know if any new objects it created locally have been successfully created on the server or not. If they have been created, retrying the upload will create duplicates, and if you don’t retry you potentially loose your work.

This post is related to work that I’m doing for version 21 of Vespucci that automates all of this, but the interesting thing is that you can easily handle many of the cases manually without editor support.

As you may know OSM changesets are not atomic, but individual uploads are (yes, you can upload multiple times in to the same changeset). With other words if your upload succeeded, but your editing app lost the response from the server, all your changes will have been successfully made, and, the other way around, if your upload fails it will fail completely.

The other point to note is that changesets are opened in a separate operation and are only automatically closed after a timeout of an hour if they are not explicitly closed after the upload by your editing app.

A normal upload operation will roughly contain the following steps

  • open the changeset.
  • upload the data and process the response. Depending on your editing app it will update the downloaded data in place, or throw it away and re-download from the server.
  • close the changeset.

This means that there are simple cases that you can handle manually, assuming you are not uploading more than once per changeset (more on that later):

  • opening the changeset fails: if you go to your account and check your edits, you should see either no new changeset or an open one with no changes. You can safely retry the upload.
  • something went wrong uploading the data: if you check your edits, you should see an open changeset that either
    1. is empty, that is the upload failed completely. You can safely retry the upload.
    2. contains your uploaded edits. In this case you should discard your edits and re-download data from the server.
  • closing the changeset failed, this is normally harmless and your editing app should probably not even report this, as all your changes have been saved and your editor has current state. In your OSM account you will simply see that the changeset hasn’t been closed till an hour later.

Now for the the tricky bits.

You would assume that these could be avoided completely by not uploading multiple times per changeset. However the popular, at least in JOSM and Vespucci Upload selection functionality and chunked uploads in to separate changesets have exactly the same issue: you have pending changes in your editors data that you haven’t attempted to upload yet, and that possibly, to make matters worse, refer to elements that you did try to upload and that failed.

If the upload failed completely as in 1. above, you are good to go and can retry, but 2. doesn’t help you. Why is that?

When an editor creates an new object it assigns a negative value id to it, then when you upload the data the OSM API replaces that with the actual one that will be used in the database and reports that back in the response to the upload. If you don’t get the response you don’t have the mapping between placeholder id and actual id.

Assume you’ve created two completely new ways, with one common node. You will have actually created 5 new nodes, n-1 to n-5 and two ways w-1 and w-2.

n-1
n-2
n-3
n-4
n-5
w-1 [n-1, n-2, n-3]
w-2 [n-4, n-2, n-3]

Now you’ve uploaded the 5 nodes as first changeset and that fails. So even if your 5 nodes were uploaded completely you have no way to change the references in w-1 and w-2 to match the ids of the nodes that were successfully uploaded. This is the JOSM “importing a gazillion objects” scenario in which you are uploading dozen of changesets with 20’000 nodes before getting to the ways and it fails halfway through. leaving a gazillion orphan nodes behind.

You definitely can’t reasonably fix this manually. Note “reasonably”: you could naturally save your OSM data to a file and then manually change the ids, this even works for toy data as in the example, but is hopeless for any larger edit.

This is what I’m working on for Vespucci 21, besides providing a simple way of retrying an upload when it is safe, I’m adding functionality to patch data in the app in such scenarios. In principle this is quite simple, we can download all the changes in a changeset from the API with https://wiki.openstreetmap.org/wiki/API_v0.6#Download:GET/api/0.6/changeset/#id/download then update the data from it.

This is straightforward for updates and deletions of existing objects as we can identify them by id. Newly created objects need to be determined by using heuristics as the API provided osmChanges format data doesn’t (can’t?) provide the placeholder id to actual id mapping.

The heuristics will fail (as in use the wrong id mapping) for untagged elements with exactly the same geometry (consider untagged nodes on top of each other), but that is probably survivable in the grand scheme of things,

See https://github.com/openstreetmap/openstreetmap-website/issues/2201 for some discussions on potential ways to avoid these issues in the API.

Dados do MapBiomas no OpenStreetMap e sugestão de etiquetagem

📄 Resumo

Neste texto discorro sobre a minha experiência mapeando vegetação de Caatingas no OpenStreetMap no município de Cuité, Paraíba, através dos dados do MapBiomas. Apresento um modelo de etiquetagem semelhante ao meu diário anterior focado nos dados ambientais do IBGE, mas dessa vez voltado para os dados sobre vegetação brasileira produzidos pelo Projeto MapBiomas. O intuito é ser um suporte para quem tiver interesse em mapear áreas vegetadas no OpenStreetMap sem a necessidade de criação de novas tags e utilizando o que já está documentado na Wiki. A tabela com a etiquetagem sugerida pode ser visualizada no Google Planilhas.

❓ Os dados do MapBiomas podem ser utilizados no OpenStreetMap?

Sim. Através de e-mails, o usuário Matheus Gomes conseguiu uma autorização explícita do MapBiomas para o uso no OpenStreetMap. Originalmente, a licença do projeto é CC-BY-SA, contudo a equipe autorizou a utilização dos dados mesmo com a incompatibilidade com a licença ODbL. A conversa está documentada na wiki.

🌎 O que é o MapBiomas e quais são as características dos dados?

Segundo o próprio site, o MapBiomas é:

“(…) é uma iniciativa do Observatório do Clima, co-criada e desenvolvida por uma rede multi-institucional envolvendo universidades, ONGs e empresas de tecnologia com o propósito de mapear anualmente a cobertura e uso da terra do Brasil e monitorar as mudanças do território.”

É importante destacar que os dados de cobertura e uso do solo do MapBiomas possuem resolução espacial de 30 m e podem ser baixados em formato raster (GeoTiff) em diversos níveis como bioma, município ou estado através de script no Google Earth Engine. Mais informações de como realizar o download estão nas informações sobre as Coleções e a metodologia do projeto é descrita na visão geral da metodologia.

💻 Processamento dos dados para o uso no OpenStreetMap

A primeira etapa foi baixar os dados de cobertura do solo a nível de município através do script no Google Earth Engine. Este vídeo do canal GeoAplicada explica bem como fazer isto. Com o arquivo obtido é um raster, foi preciso vetorizar o arquivo. Para isso, usei o QGIS. Com o arquivo vetorizado, foi possível exportar cada tipo de cobertura de solo para um GeoJSON tomando o cuidado de identificar a cobertura correta através dos Códigos de Legenda do MapBiomas. Como meu foco era vegetação nativa, exportei apenas os códigos correspondentes à Formação Savânica e à Formação Campestre, visto que correspondem a maior parte do município.

📍 Mapeamento no OpenStreetMap e porque não fiz importação massiva dos dados

Devido a resolução espacial dos vetores gerados, optei por não importar a geometria exatamente do Mapbiomas. Preferi utilizar apenas como camada de fundo no JOSM e redesenhar as geometrias utilizando imagens áereas do Bing, verificando e subindo pouco a pouco para o OpenStreetMap. Foi um trabalho cansativo e demorado, mas é preciso fazer essa verificação para que a geometria seja mais coerente com o existente. Isso evitou também conflito com geometrias de vegetação já presentes no OpenStreetMap, como as do Banco de Dados e Informações Ambientais do IBGE, e a criação de multipolígonos com açudes, lavouras e etc.

📝 O modelo de etiquetagem

Para as tags de vegetação, utilizei método semelhante à minha proposta anterior de correspondência com os dados do IBGE, permitindo uma maior diversidade nas características da vegetação e um rastreamento de onde vieram aqueles dados. A etiquetagem sugerida para cada classe do MapBiomas está descrita no Google Planilhas. Por conhecimento da região e experiência em mapeamento de vegetação, optei por não mapear algumas classes com base no Mapbiomas, principalmente as lavouras, pois a resolução espacial do projeto e outros fatores podem identificá-las incorretamente. O mesmo vale para tipos de vegetação nativa. O conhecimento local do mapeador nestes casos é sempre muito importante!

⏳️ Antes e depois do mapeamento

Embora ainda não tenha concluído totalmente o mapeamento, este é o resultado para o município de Cuité, Paraíba.

Mapa de Cuité antes e depois dos dados do MapBiomas Município de Cuité no OpenStreetMap antes e depois dos dados de vegetação do Mapbiomas 2022. Tamanho completo

E aqui um exemplo de uma vegetação local com bastante informação nas etiquetas.

🍂 🌿🌴🌵 Sugestões e opiniões são sempre bem-vindas! 🌳🌲🌻🍃

The Year 2021 was my most productive year in OpenStreetMap mapping. It was all downhill from there due to a variety of factors, highlighted by an abrupt career change that I never anticipated (COVID-19 pandemic did a lot of damage to everyone), and derailed me on my tracks.

Four (4) years since, despite being busier as a government employee with multiple designations, I decided to go back to mapping. I allocate a part of my free time to reacquaint myself with a long-lost love, and continue updating the places that became part of my journey.

Also, I became a father in the last quarter of 2024. To honor my only son, Daniw (an Iloko term for “poem”), who has exhibited a profound interest in exploring the outdoors at four (4) months as of this writing, I shall be using a new name bearing his name.

See our photo here: https://www.facebook.com/photo/?fbid=2294431287573827&set=a.119524685064509

Hello, everyone! I am happy to be back!

Location: Sitio Imbakaan, Centro I, Sanchez Mira, Cagayan, Cagayan Valley, Philippines

Buenas tardes, soy Osvaldo y estoy buscando ayuda para colocar un mapa de ruta en el itinerario de viaje de mi agencia de viajes. la idea es por ejemplo:

DÍA 01 MÉXICO – LONDRES DÍA 02 - PARÍS DÍA 03 - ZURICH DÍA 04 - PARÍS DIA 05 - PARIS-MEXICO

Y DEBAJO UN MAPA QUE UNA CADA DESTINO CON UNA LINEA. el problema es que no estoy inmerso en este tema y deseo que me ayuden para lograrlo. utilizo Worpress y el tema Hello Elementor. muchas gracias por su atención

Posted by miurahr on 16 February 2025 in English. Last updated on 22 February 2025.

OSGEO Hokkaido team and SotM Japan team hosted the FOSS4G Hokkaido and State of the Map Japan 2024 in 15th February in Sapporo, Hokkaido.

The idea to organize two related conference was raised by Hokkosha in June 2024 and now is realized.

You can find the record at YouTube

Here is a link to the presentations.

  1. adım: ArcGIS REST sunucusunda yanlış konfigürasyon nedeniyle erişilebilen WFS endpoint ini kopyalıyoruz.
  2. adım: QGIS indirip kuruyoruz, ardından WFS endpoint i ilgili kısımdan ekliyoruz.
  3. adım: Endpointten elde edilen altlıkları açıyoruz ve istediklerimizi Shapefile olarak dışa aktarıyoruz.
  4. adım: Son olarak eğer projeksiyon EPSG:4326 değilse JOSMdeki OpenData eklentisi genelde düzgün açamamakta. Bunun için de [https://mygeodata.cloud/ şu siteden] GeoJSON haline dönüştürüyoruz.
  5. Adım: Multipolygonlar düzgün aktarılmadığı için sınırları elle bir daha düzenleyip OSM sunucusuna yolluyoruz. Veride azıcık kayma olması mümkün. (muhtemelen veriler önce ED50/TUREF’den aktarılıyor, biz de bunu bir daha dönüştürdük. hata payı var)

Como mapear nomes de Rua no Openstreetmap com uma camada de fundo do senso-2022.

nesse video vou mostrar como mapear nomes de Rua com uma camada de fundo com dados de nomes de Rua disponibilizada pelo IBGE.

Link do arquivo usado no video com os dados de nomes de Rua de algumas cidades brasileiras para o mapeamento de nomes de Ruas no Openstreetmap.

OBS: use esse arquivo como camada de fundo.

https://projeto.softwarelivre.tec.br/s/3zxd54iSjr7YQZ4

Link do Video; https://www.youtube.com/watch?v=2hyHqiViMMw&t=118s

Baixar os aquivos da camada de face do Senso-2022;IBGE http://gpsutil.com/CNEFE-2022/

Fonte: IBGE; Senso-2022

UMBRAOSM - União dos Mapeadores Brasileiro do Openstreetmap