OK. Last year I wrote a short guide on mapping Indian addresses but I lost it in my tiny pursuit to delete myself. Today I suddenly came across the fact that the guide was actually used by mappers and, hence, as a result I am now writing this post to become a replacement for that old guide. Since this is a new one, I don’t want to just rehash the old stuff and instead this time I am going to take a simple problem and show how I would solve it from scratch.

A1, Tower 2, Sector 11, RK Puram, South West District, Delhi, India

A problem very similar to this one came up in OSM India’s XMPP channel today. So, how does one go about mapping this address?

As it’s usually the case we can ignore the district, state, and country part as they are all very well mapped in India. This leaves us with everything upto RK Puram.

If you are thinking that something as big as RK Puram should surely be already on the map then you are wrong; In my “career” I have actually seen larger areas without any nodes for them. So we will in fact check if it’s already on the map and, guess what, it actually is already mapped as a suburb, so that’s one less step for us! I should mention that in OSM there are three “neighbourhood” levels below the district: quarter, suburb, and neighbourhood in decreasing order of size. In most cases suburb and neighbourhood should be enough for you, but it is important to be aware of quarter for special situations.

Now let’s check for Sector 11. As of writing this, Sector 11 isn’t on the map. So I will put a neighbourhood node at the approximate centre of Sector 11. (Remember that neighbourhood is smaller than suburb.) We are making good progress.

Now let’s take care of Tower 2. It’s actually specifying a particular building, unlike the previous steps which were about specifying the area in which the building lies. In this case it should be “Tower 2” for housename and “Sector 11” for place. It’s important to specify the place because it could be the case that “Sector 45” node is actually closer to the building.

A small interjection: when mapping a building try to choose between housename and housenumber or place and street logically. If your address is “36, Shivaji Marg” then please please use 36 for housenumber and Shivaji Marg for street. If you do it incorrectly then there’s a 90% of divine punishment from OSM gods.

OK. The building is done. Now all you have to do is to add A1 to the unit tag as a separate node inside the building. Note that the A in this case does not refer to a block and so it should not be separated from the 1. Another important point is that even though A1 is referred to as housenumber in common language, in OSM it isn’t actually a housenumber since housenumber/housename are reserved for building. A1 is just a unit number which means that it is a part of the building. (In case you haven’t realized it yet, the given address was for an apartment.)

I forgot to mention but blocks are somewhat of a controversial topic. My method is usually to retain the blocks in housenumber if they are simple (such as the 1 in “1/265”) or move them into “place” if they are more complicated (like the Pocket E in “36, Pocket E”).

OK. Let’s see if you were reading carefully. Tell me how you would map

1/26/65EB, Gali Shanti, Near Phoole Wala Mandir, Chandni Chowk, Old Delhi

Were you able to do it? Here’s my answer:

Old Delhi is probably already mapped, Chandni Chowk would be a neighbourhood, I would ignore Phoole Wala Mandir, I would add Gali Shanti to the name of highway, then finally for the building I would add 1/26/65E as housenumber and Gali Shanti as street. Did you notice that I never actually told you that letters like E are allowed in housenumber? By that I wanted to show that this guide probably does not contain comments for each and every case, but it should work for the majority of cases. If you come across a difficult problem, then your best bet is always OSM Wiki. Just look it up!

This post was first released on my website with 💜 under CC BY-NC-SA 4.0.

本系列编辑主要修复了部分住宅楼的过大幅度偏移，以及一些误标记的绿化。问题区域主要在星塘街以东，为方便起见，以东西向道路作阶段性的分割。

记录

2026/2/24已完成修复兆佳巷以北

A few months ago, I worked on a new project: the OSM Tagging Schema MCP — a Model Context Protocol (MCP) server built for AI assistants and LLM applications that interact with OpenStreetMap tagging data.

It serves as a bridge between AI systems and the official OpenStreetMap tagging schema, allowing agents to validate tags, query values, search presets, and suggest improvements using the structured knowledge from the @openstreetmap/id-tagging-schema library.

The current 3.x release is technically stable — all tools and endpoints work reliably without errors — but it should still be considered experimental. Active development on version 3 has ended; for now, I only maintain it through dependency updates.

The next major step will be version 4, a complete rewrite developed with AI-assisted coding, focusing on a cleaner architecture, long-term maintainability, and deeper MCP integration.

You can try the service live here: mcp.gander.tools/osm-tagging.

I invite you to experiment, test, and share feedback — your ideas and suggestions are always appreciated: gander-tools/osm-tagging-schema-mcp discussions

Before

After

Whether you’re passionate about maps, data, or shaping the future of  OpenStreetMap (OSM), the community is always looking for your inspiring ideas! Why not sharing them during State of the Map 2026?

The call for participation of SotM 2026, taking place in Paris, France, on August 28 – 30, 2026, is now open! The programme committee is ready and waiting, eager to unwrap your submissions for talks, workshops, and panels. These sessions aren’t just part of the conference; they’re its beating heart, driving conversations and sparking ideas that resonate worldwide. Presenting your work, projects and ideas at SotM is also a great way to get in touch with the wider OSM community.

Tracks

Sessions can be submitted for the following tracks:

• OSM Basics – Information dedicated to newcomers
• Community and Foundation – Bringing people together, working group experiences, strategies & vision
• Mapping – All about making the mapping easier and better
• Cartography – Your ideas on how to create good-looking presentations of the OSM dataset
• Software Development – Software for processing and editing data
• Data Analysis & Data Model – Reflections about the OSM data, its model and analysis of quality and completeness
• User Experiences – Stories of using OSM and its data as a user
• Education – How you use OSM in an educational context

If your submission doesn’t seem to fit into one of these tracks, don’t worry – as long as it is clearly related to OpenStreetMap, you’re perfectly fine if you simply choose the track that feels to fit best.

OSM Science (Academic Track) at SotM 2026

In addition to this general call for participation, there will again be a proper academic track with a separate CfP, which will be announced later. So, if you’re knee-deep in the captivating world of OpenStreetMap, stay tuned for the official call: The working group is eagerly awaiting the most riveting insights and groundbreaking results from your studies. Get your research hats on, gather your data, and prepare to submit the best of your studies.

Timeline and Deadlines

• 27 April 2026 23:59:59 UTC: Deadline talk, workshop and panel submissions
• End of May 2026: End of review phase, speakers will be informed, schedule published
• 28-30 August 2026: State of the Map in Paris, France

For more information on the above track categories, submission requirements and rating criteria, please visit the complete call for participation and the submission guidelines on the SotM website.

Stay tuned for more news about the State of the Map 2026! See you later this year in Paris, France, and online!

The State of the Map Working Group

Do you want to translate this and other blogposts in your language…? Please email communication@osmfoundation.org with subject: Helping with translations in [your language]

The State of the Map conference is the annual, international conference of OpenStreetMap, organised by the OpenStreetMap Foundation. The OpenStreetMap Foundation is a not-for-profit organisation, formed to support the OpenStreetMap Project. It is dedicated to encouraging the growth, development and distribution of free geospatial data for anyone to use and share. The OpenStreetMap Foundation owns and maintains the infrastructure of the OpenStreetMap project, is financially supported by membership fees and donations, and organises the annual, international State of the Map conference. Our volunteer Working Groups and small core staff work to support the OpenStreetMap project. Join the OpenStreetMap Foundation for just £15 a year or for free if you are an active OpenStreetMap contributor.

OpenStreetMap was founded in 2004 and is an international project to create a free map  of the world. To do so, we, thousands of volunteers, collect data about roads, railways, rivers, forests, buildings and a lot more worldwide. Our map data can be downloaded for free by everyone and used for any purpose – including commercial usage. It is possible to produce your own  maps which highlight certain features, to calculate routes etc. OpenStreetMap is increasingly used when one needs maps which can be very quickly, or easily, updated.

finding myself to osm was something I couldn’t understand at the time. Now with an open eye, in my field of water engineering introduced to geographical information system. I love it here my journey begins now mapping take me overseas. 😊

I successfully put Novato Baylands Point Blue Conservation Science as a pin on the map. However, I have not had success with editing the directions that maps provides to get you to the site. The directions still route you past the facility, rather than stopping right at the facility. They should tell you to go down Aberdeen Rd, and then the location is on your right. Thanks for any assistance with editing the route.

I’m new to editing OpenStreetMap, so this is my first change! I noticed that most neighbourhood areas in Lethbridge, my local city, don’t have a name shown in OSM. However, they’re all neatly shown on an official 2024 map from the government of Lethbridge, so I used it as a source. I did notice that some areas are already named in other ways, but I couldn’t find the item that holds the name. This induced visual clutter by doubling some names (those of the industrial parks, Copperwood, and seemingly Paradise Canyon), but I still added the names to the neighbourhood areas for consistency anyways. If anyone around knows how to get rid of this without removing the naming consistency, it would be great if this slight issue could be resolved. I haven’t actually tested the map yet, since I just uploaded the edit, but if what I’m describing is actually a problem, please help? Anyway, I intend on updating and adding a lot of things to Lethbridge (like adding addresses and new buildings) in the near-ish future, so it’d be fun to get to know the local OSM community.

Code for Harimaの定例会で自分が表明したことで議事録に載せてますが、こちらに転記しておきます。

数ヶ月ほど前にあったCode for Harimaの定例会で、OSMを利用した万博マップに対して自分が「大阪万博には、赤字補てんのための公的資金投入やカジノありきの計画、パビリオン建設工事費未払問題などさまざまな政治的問題があり、それに加担するような活動は良くない」という発言したところ、参加していたOpenStreetMap Foundation Japanの某氏は「万博は政治的じゃない」と発言したことに驚いた出来事がありました。

OSMFJの人がそういう発言をするのであれば、自分は逆に 政治的なOpenStreetMap のプロジェクトをやろうと思いつきました。

自分が個人的にぼちぼちやるので、別になにかあるというわけではありませんが、とりあえず表明ということで書いておきます。ひとまず、次の2つを考えています。

1. 反人種差別のためのマッピング
2. 敵対的建築物(Hostile architecture)を記録するマッピング

1. 反人種差別のためのマッピング

OpenStreetMaps USで、社会的公平性のために人種差別に関する地物をマッピングして、wikidataとリンクさせて可視化するというプロジェクトがあります。

• United States/Racism - OpenStreetMap Wiki

アメリカでは、黒人奴隷や南軍、KKK関連の地物をマッピングしています。日本では、戦前、戦中に韓国や中国から強制労働で多数の人が連れて来られて、炭鉱や建設などに従事させられました。

その労働は過酷で、命を落とす人もいたので慰霊のための慰霊碑が建てられていたりします。たとえばこれとか。

• 神戸電鉄朝鮮人労働者の像 - Wikipedia

こういうものを記録していきます。群馬の森の朝鮮人慰霊碑が歴史修正主義者のクレームにより撤去されるという事態も起こっているので、記録は残さないとと思っています。

• 「群馬の森」朝鮮人追悼碑の撤去…平和を願う関係者の無念を映画化 - RKB毎日放送

2. 敵対的建築物(Hostile architecture)を記録するマッピング

敵対的建築物は直訳ですが、日本語では「意地悪ベンチ」「排除アート」と呼ばれているものです。

排除アートは、行政がホームレスや若者がたむろさせないために、ベンチを座りにくくしたり寝られないように手すりをつけることや、人が溜まりやすいスペースに意味不明なアートっぽい（アートではない）オブジェを置いて、そこに滞留できないようにすることです。

• 〈人を座らせないベンチ〉東京・新宿の“意地悪ベンチ”に批判続出！ 一方、下町では真逆の試み…ベンチだらけの商店街を取材 - 集英社オンライン - ニュースを本気で噛み砕け
• Hostile Architecture
• 排除アート - Wikipedia

ふと気になってOSMのタグを調べたら、そのものズバリ「Hostile architecture」のタグがproposalに出てたので、この動きを推進するために、これらをマッピングします。

• Hostile architecture - OpenStreetMap Wiki
• Proposal:Hostile Architecture - OpenStreetMap Wiki

redditの写真を見れば排除アートがどんなものかわかりますが、広がっている問題については可視化しないとわからない人がいるので、どんどんつけて可視化したいと思ってます。

ということで、時間ができたときに自分はぼちぼちやっていきます。興味がある人がいれば連絡をください。

• https://tools.geofabrik.de/
• https://hdyc.neis-one.org/
• https://osmose.openstreetmap.fr/

12/02/2026-18/02/2026

Mapping

• Comments are requested on the proposal bicycle_parking=absent. This tag aims to document that no bicycle parking is available around a feature, for example a shop or station, making such gaps in infrastructure discoverable in data analyses. Related discussion is also taking place on the forum.

Community

• Clifford Snow introduced the ‘Safe Routes to School’ initiative, which supports families who want their children to walk or cycle to school in a safe way. The project focuses on identifying the most suitable routes and collaborating with local authorities to make those routes safer. The team is currently looking for additional volunteers to improve the data. Those who would like to contribute can join the #safe-routes-to-school channel on the OSM US Slack.
• OpenCage has published an interview with Nicolas Collignon, CEO of Kale AI, a company developing urban delivery routing solutions powered by OpenStreetMap.
• Anne-Karoline Distel showed how to add information about what is or was quarried at a quarry in OpenStreetMap, noting that such data can be valuable for historical research, whether in industrial, social, or even church history.
• Marcelm005 has proposed a project to map the Lincolnshire ER Routes, emergency routes that enable people to quickly evacuate from flood-prone areas.
• rtnf is trying to learn how OSM tile servers work.
• The OpenStreetMap US community is currently deliberating on the most effective method for querying OpenStreetMap objects based on their geometric shapes.

OpenStreetMap Foundation

• The next OSM Foundation Board meeting will take place on Thursday 26 February 2026 at 13:00 UTC.The meeting will be accessible through the video room.The topics to be covered are:
  • Chairperson’s report
  • Secretary’s report
  • Treasurer’s report
  • 2026 board face-to-face meeting update
  • French cadastre changes and release of code updates for ‘OSM components’ on GitHub
  • Creation of an OSMF Coinbase account for BTC donations
  • Potential statement/policy for OSMF’s participation with other parties in proposals for EU-funded projects, and related topics:
    • Draft blog post: OSMF approach to EU-funded project collaborations
    • Potential OSMF participation in Horizon Europe CSA (GeosTeX)
    • European Institute of Technology (EIT) communications
    • 2026 Sovereign Tech Agency call for tenders
  • Request for comments for GERS as an OGC Community Standard
  • Guest comments or questions.
• The Marche Region (Italy) reported ► about its recent entry among the supporters of OpenStreetMap as a ‘Silver Member’. This is the first time that an Italian public body has officially recognised the usefulness of OpenStreetMap and decided to actively contribute to its financial support.

Local chapter news

• OpenHistoricalMap has kicked off their first donation drive to help fund technical development and operations.

OSM research

• A Danish survey conducted in January 2026 found that in Denmark, OpenStreetMap contained approximately 20,878 km more paths, footways, and tracks than the official Danish road network dataset, GeoDanmark Vejmidter. The survey was carried out by the Danish organisation GeoDanmark.
• A new study published in Nature Communications uses OpenStreetMap land use and AOI data to help classify 110 million buildings across 109 Chinese cities, demonstrating how open, community-mapped data supports national-scale urban inequality analysis and evidence-based planning.

Maps

• kafked has presented his side project rename.world on Hacker News. rename.world is a MapLibre-based map where users can click any place and propose new names. Around 40,000 renames have already been submitted; the non-commercial project runs on SvelteKit, with self-hosted vector tiles, and is explicitly not intended for navigation.
• The Welikia project shows the native ecology of New York City (i.e. what it was before settlement), using OSM as base map. The project is maintained by the Urban Conservation team at the New York Botanical Garden.

OSM in action

• ^[1] At the News-Infographics-Analytics-Maps 2026 conference in Berlin, data visualisation journalist Ferdinand Holsten presented how the German news magazine DER SPIEGEL has built its own open-source mapping stack based on MapLibre and Protomaps. This allows DER SPIEGEL to host tiles for interactive maps independently of commercial services such as Mapbox. The presentation, which is now available as a video on media.ccc.de, outlines the workflow from data preparation to tile generation and the integration into an interactive storytelling. Ferdinand Holsten has kindly provided us with an automatic translation of the presentation into English.
• Jake Coppinger (UrbanSpectra) has published a map tracking community and government projects across a river catchment, utilising OpenStreetMap data (Sydney, Australia).
• rbb24, part of public service broadcasting in Germany, naturally uses ► OpenStreetMap, with correct attribution, in its reporting of locations.

Open Data

• HeiGIT reported that it has published new open and ready-to-use global risk assessment datasets, with the objective to simplify risk analysis by removing major technical barriers to data preparation. These datasets are designed for easy use with the risk assessment QGIS plugin and enable humanitarian stakeholders to conduct multi-hazard, evidence-based risk assessments to support anticipatory action.
• Xiong et al. have published a dataset, which contains a topologically connected representation of the European high-voltage grid (220 kV to 750 kV) compiled from OpenStreetMap data extracted with overpass turbo.

Software

• sylvester_aswin has introduced their project Map Frame, which allows users to generate minimalist map posters based on OpenStreetMap data. Any location worldwide can be selected and downloaded as a 4K PNG (3600×4800); the first poster is free, additional downloads cost one US dollar.
• Carlos Froh introduced OnRouteMap, a web tool that helps find petrol stations, supermarkets, snack bars, drinking fountains, and similar places along your uploaded GPX track.
• The solo developer thattechiedude, from Hudson Valley, has presented ROLLIN, a map platform rating locations from 0–100 based on six features such as wheelchair access, accessible toilets, and lifts. The project uses OpenStreetMap data, cross-references Google Places, and adds community verification, and offers a free API tier for developers.
• Terence Eden, the developer of OpenBenches, has recently implemented a login with OpenStreetMap function in OpenBenches.
• Ulf Rompe has developed ‘What Did You Do‘, a simple tool that shows the number of OpenStreetMap edits made by each software application within a certain period of time.

Programming

• Thomas de Wolff has introduced his Go library geo/osm on Reddit, offering fast parsing of OSM PBF files through handwritten protobuf decoding, optimised readVarint and readSint routines, and custom zlib decompression. The library can skip specific object types, generate file statistics, and extract geometries by region filter, making it suitable for building custom renderers.
• In response to recent Overpass API service instability, Matt Whilden has developed microcosm, a GitHub Actions script that retrieves a narrow slice of OSM data and updates it nightly.
• Andy Townsend discussed the difficulties encountered in setting up your own Overpass API server.

Did you know that …

• … you can zoom one-handed in Organic Maps?
• … you can easily submit a brand to the Name Suggestion Index project by using NSI Submit a Brand?
• … there is a Mastodon instance run by and for OpenStreetMap contributors that is funded by the OSMF?

Other “geo” things

• Emmanuel Mathot and Jonas Sølvsteen wrote on the Development Seed blog about the release of the ‘EOPF Sentinel Zarr Explorer’, a framework for spatial analysis based on Sentinel images. The cloud-based geospatial project is funded by the European Space Agency through the Copernicus Space Component programme, and was developed by a consortium led by Development Seed and EOX, with community outreach led by thriveGEO.

Upcoming Events

Country	Where	Venue	What	When
	Karlsruhe	Geofabrik, Amalienstraße 44, 76133 Karlsruhe	Karlsruhe Hack Weekend February 2026	2026-02-21 – 2026-02-22
	Belfast	School of Geosciences, Queen’s University Belfast	Belfast Mapathon	2026-02-21
		TAK Kadıköy Tasarım Atölyesi	OpenStreetMap Outdoor Editing	2026-02-21
	Toulouse	Artilect – 10, Rue Tripière – Toulouse	Rencontre OSM Toulouse	2026-02-21
	Kalyani Nagar	TomTom Pune Office, India	OSM Mapping Party at TomTom Pune, India	2026-02-21
		Atelier Vélo Utile	Rencontre OSM Saint-Brieuc	2026-02-21
	Mumbai	High Point restaurant, Lokhandwala Market, Andheri	OSM Mumbai Mapping Party No.7 (Western Line – South)	2026-02-22
			Missing Maps : Mapathon en ligne – CartONG [fr]	2026-02-23
	Saint-Étienne	Zoomacom	Rencontre Saint-Étienne et sud Loire	2026-02-23
	Olomouc	Přírodovědecká fakulta Univerzity Palackého	Únorový olomoucký mapathon	2026-02-24
		Online	Mappy Hour OSM España	2026-02-24
	Derby	The Brunswick, Railway Terrace, Derby	East Midlands pub meet-up	2026-02-24
	Berlin	Online	OSM-Verkehrswende #72	2026-02-24
	City of Edinburgh	Guildford Arms, Edinburgh	OSM Edinburgh pub meetup	2026-02-24
	Praha	Fakulta Elektrotechnická ČVUT v Praze	Missing Maps Mapathon na ČVUT v Praze	2026-02-25
	Hannover	Kuriosum	OSM-Stammtisch Hannover	2026-02-25
	Luxembourg	neimënster, Luxembourg & online	MSF Luxembourg hybrid Mapathon	2026-02-25
	Düsseldorf	Online bei https://meet.jit.si/OSM-DUS-2026	Düsseldorfer OpenStreetMap-Treffen (online)	2026-02-25
	Seattle	Seattle, WA, US	OpenThePaths 2026: Connecting People and Places Through Sustainable Access	2026-02-26 – 2026-02-27
	Essen	Fahrrad-Messe Essen, Halle 5, Show-Truck	Vortrag: Mitmachen bei OpenStreetMap, der Basis vieler Outdoor-Apps	2026-02-26
	Milano	Building 3A Ground Floor – Politecnico di Milano	PoliMappers Maptedì	2026-02-26
	Zürich	Meta Zurich Office	Mapillary: Celebrating 3 Billion Images	2026-02-26
		Online	Asamblea General Ordinaria – Asociación OpenStreetMap España	2026-02-26
	Santa Clara	Santa Clara University	Friends of MSF Mapathon	2026-02-26
			UN Maps Validation Friday Chat & Map	2026-02-27
	Essen	Fahrrad-Messe Essen, Halle 5, Show-Truck	Vortrag: Mitmachen bei OpenStreetMap, der Basis vieler Outdoor-Apps	2026-02-27
	Potsdam	Hafthorn	Potsdamer Mappertreffen	2026-02-27
	Ferrara	Cimitero monumentale della Certosa di Ferrara	Ferrara mapping party	2026-02-28
	Messina	Messina	Mapping Day @ Messina	2026-02-28
	नई दिल्ली	Jitsi Meet (online)	OSM India – Monthly Online Mapathon	2026-03-01
	Milano	Building 4A, Room Fassò – Politecnico di Milano	PoliMappers Maptedì	2026-03-03
	Salzburg	Bewohnerservice Elisabeth-Vorstadt	OSM-Treffpunkt	2026-03-03
	Lille	Salle Yser, MRES, 5 rue Jules de Vicq, Lille	Rencontre OpenStreetMap à Lille	2026-03-03
			Missing Maps London: (Online) Mapathon [eng]	2026-03-03
			iD Community Chat	2026-03-04
			OSM Indoor Meetup	2026-03-04
	Brno		Kvartální OSM pivo	2026-03-04
	Stuttgart	Stuttgart	Stuttgarter OpenStreetMap-Treffen	2026-03-04
			OSM US Mappy Hour: OpenHistoricalMap in North America	2026-03-04
		Online	OpenHistoricalMap in North America	2026-03-04
	Flensburg	Offener Kanal Flensburg	3. Open Data Day Flensburg	2026-03-05
			OSMF Engineering Working Group meeting	2026-03-06
	Gent	Wijgaard	OpenStreetMap meetup in Gent – Pre-VLA-congres editie	2026-03-06
		Hogeschool Odissee Hospitaalstraat 23 Sint-Niklaas	Vereniging Leraars Aardrijkskunde (VLA) conference 2026	2026-03-07
	Perth	Espresso Perk U Later	Social Mapping Sunday: Moort-ak Waadiny / Wellington Square Perth	2026-03-07
	Perth	Espresso Perk U Later	Social Mapping Sunday: Moort-ak Waadiny / Wellington Square Perth	2026-03-08
	Delhi		OSM Delhi Mapping Party No.27 (East Zone)	2026-03-08
	København	Cafe Bevar’s	OSMmapperCPH	2026-03-08
	London	Social Sciences Centre – Western University	Friends of MSF UWO Mapathon	2026-03-09
			Missing Maps : Mapathon en ligne – CartONG [fr]	2026-03-09
	Brno	Geografický ústav, PřF MUNI, Brno	Březnový brněnský Missing Maps Mapathon na Geografickém ústavu	2026-03-09
	臺北市	MozSpace Taipei	OpenStreetMap x Wikidata Taipei #86	2026-03-09

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

This weeklyOSM was produced by MarcoR, MatthiasMatthias, PierZen, Raquel IVIDES DATA, Strubbl, Andrew Davidson, barefootstache, derFred, mcliquid.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

包含建筑物、森林。之前陆陆续续修复了一些，不过都是游击式地修复，没有系统地记录过。现在有时间捡起这件事了，先在这里留个坑吧。

……不要给房子加layer标签来逃避冲突检查器的检查。

26/2/21

Taking a break for 1 week because of ramadhan and installing gentoo as my main system.

I have a large set of photographs I made while running. They are geotagged, as I took them with my phone camera. The compass direction is completely unreliable, but lat/lon is more trustworthy. I thought it would be an interesting experiment to extract greenery like grass and trees from these photographs. It can be a useful addition for creating routes that are more pleasant to walk, since the eye-level point of view is not available in OSM. As this is based on my personal photographs, it has the additional benefit of recommending routes that I tend to use. The first challenge I encountered is that out of a few thousand photographs, only a handful were taken during the daytime. After deduplicating and dropping all photos that contain no greenery, this becomes a relatively small set of waypoints. I decided not to extrapolate additional points along OSM ways to keep the dataset small and avoid adding misleading info. The greenery detection works well enough with the SegFormer model, although it is somewhat slow locally. My plan is to select waypoints from this dataset before calling OSRM. This way I get routes that are more enjoyable to walk and run, but are generally longer than the default shortest route. You can find my dataset on Kaggle.

A few quick notes on some changes I made to OSM based on local knowledge.

1. Changed the point for the Riverside Centre building to reflect that it is now a Builder’s Corner hardware store.

2. Added a point for the nearby Hole in the Wall Centre

3. Defined an area for the Somerset Lofts apartment complex and added some details for it.

I’ve recently begun contributing street-level imagery on Mapillary and Panoramax in my local area. I figured that my dash cam was already recording anyway, so if it could be of use to anyone, why not share it?

Contributing to Mapillary was very easy; since my dash cam has an integrated GPS that encoded its data into the video file, I could just upload the video to Mapillary and their website would turn it into an image sequence. Panoramax requires you to preprocess the video into geotagged images yourself, which made it hard to contribute to. Some cameras can be configured to save periodic images instead of videos, but that didn’t work for me because I still needed the dash cam to work normally as a dash cam first and Panoramax instrument second. It took me a while to figure it out, so I’m writing this blog post to hopefully help out the next guy in the same situation.

The task involves four basic steps. I scripted a solution that works specifically for my dash cam model (Garmin 47) and operating system (Linux). If Panoramax continues to grow, I imagine that separate scripts could be written for each step to mix and match for different camera types and computing environments. The steps are:

1. Extract the raw GPS data from the dash cam video clip(s)

2. Along the GPS trace, create a set of evenly-spaced points

3. Extract images from the video occurring at the evenly-spaced points, and

4. Add the GPS and time data to the image files

One could go even further and automatically upload the images to Panoramax straight from the terminal, but that’s beyond my coding abilities.

Let’s take a look at each step in detail:

Step 1 - Getting GPS data from the video

Thankfully, Garmin makes this relatively easy to do with exiftool. If you open the terminal in the directory with the video clips and run the command

exiftool GRMN<number>.MP4

The output will contain a warning:

Warning : [minor] The ExtractEmbedded option may find more tags in the media data

So we can modify the command into

exiftool -ee3 GRMN<number>.MP4

Now exiftool will output all the same information as before, as well as a bunch of the following

Sample Time                     : 0:00:58
Sample Duration                 : 1.00 s
GPS Latitude                    : XX deg YY' ZZ.ZZ" N
GPS Longitude                   : UU deg VV' WW.WW" W
GPS Speed                       : 11.2654
GPS Date/Time                   : 2026:02:13 22:24:45.000Z

Jackpot! Now we can redirect the output to a file and get our GPS coordinates. We need to have a file saved in the working directory to tell exiftool how to format the data. So I saved the following as gps_format.fmt:

#[IF]  $gpslatitude $gpslongitude
#[BODY]$gpslatitude#,$gpslongitude#,${gpsdatetime#;DateFmt("%Y-%m-%dT%H:%M:%S%f")}

Now we pass that to exiftool to only print the metadata we’re interested in. We’ll also put > gps.tmp to save the output to a file:

exiftool -p gps_format.fmt -ee3 GRMN<number>.MP4 > gps.tmp

And we’re done! Now we have the raw GPS information out of the video and into plain text.

Step 2 - Turn the GPS data into evenly spaced points

To do this, I use python to linearly interpolate between GPS points approximately 3 meters apart. And I do mean very approximately: instead of doing a proper distance calculation, I just eyeball how many meters are in a degree. One meter is very roughly about 0.000009° of latitude. Since one meter is a larger portion of a degree near the poles, it needs to be adjusted based on the latitude. I blindly use the latitude of the first point of the sequence and assume it doesn’t change enough over time to matter.

from math import cos, radians
cosd = lambda x: cos(radians(x))

scale_lat =  1 / 9e-6
scale_lon = (1 / 9e-6) * cosd(lat0)

Now it is easy to use the Pythagorean Theorem to estimate the distance between two points:

dx = scale_lon * (lon1 - lon0)
dy = scale_lat * (lat1 - lat0)
dist_between_points = (dx**2 + dy**2)**0.5

Recursively find this distance for each pair of points along the GPS trace. Also keep a running tally of the total distance traveled. For example, consider the following data after you stop at a red light, sit for a while, and then keep going:

Pt | Dist | Tot
A  | --   | 0
B  | 10   | 10
C  | 6    | 16
D  | 2    | 18
E  | 0    | 18
(sit at the red light...)
Q  | 0    | 18
R  | 1    | 19
S  | 3    | 22
T  | 7    | 29
U  | 11   | 40
V  | 14   | 54
(and so on)

Suppose you want image spacing of about 3 meters (about 10 feet or half a car length). So you want images at 0, 3, 6, 9, 12, 15, …, and so on. We can take point A as our first point, but we need to interpolate between GPS points to find evenly-spaced points. I’ll use the notation X -> Y N% to mean “interpolate N% from X to Y.” Then to find our desired points, we need:

Pt | Formula
0  | A
3  | A -> B 30%
6  | A -> B 60%
9  | A -> B 90%
12 | B -> C 33%
15 | B -> C 83%
18 | D
21 | R -> S 67%
24 | S -> T 29%
27 | S -> T 71%
30 | T -> U  9%
etc...

Since Garmin takes GPS measurements once per second, this is a convenient way to determine at exactly what time each new point occurred. For the point 60% from A to B, it’s just the GPS timestamp of A plus 0.60 seconds. For the latitude and longitude of the interpolated point, we can just interpolate the latitude and longitude coordinates separately. 3 meters is not even close to far enough for great-circle paths to matter. So e.g.

lerp = lambda a, b, x: (1 - x) * a + x * b

lat_interp = lerp(latA, latB, 0.6)
lon_interp = lerp(lonA, lonB, 0.6)

# And so on for each interpolated point

Save this output to a file (I call mine processed_points.csv), and you’re done with step 2!

Step 3 - Extract images from the video

It is possible to extract a single frame of a video using ffmpeg. The time should be a decimal number of seconds after the start of the video to exactly three decimal places.

ffmpeg -ss <time> -i <video>.MP4 -frames:v 1 output.jpg

By default, ffmpeg compresses the images quite a bit. It was enough that I could notice a quality difference when I put a paused frame of the video side-by-side with an extracted image. We can force ffmpeg to improve the quality with q:v (number). A smaller number here produces a higher quality image at the expense of file size and processing time. I’ve settled on a value of 3, but feel free to play around with this to get the quality or file sizes you want.

ffmpeg -ss <time> -i <video>.MP4 -q:v 3 -frames:v 1 output.jpg

ffmpeg will print a bunch of text to the console that we don’t care about. To avoid flooding the screen, use the -hide_banner and -loglevel options to reduce (but not completely shut up) the amount it outputs to the console:

ffmpeg -ss <time> -i <video>.MP4 -q:v 3 -frames:v 1 -hide_banner -loglevel fatal output.jpg

Since you are going to extract many images, you’ll have to use this command in a loop with a bunch of variables that change from iteration to iteration, e.g.

ffmpeg -ss $(printf "%.3f" "$time") -i "$input_dir""/DCIM/105UNSVD/GRMN""$num"".MP4" -q:v "$jpeg_quality" -frames:v 1 -hide_banner -loglevel fatal "$output_dir"/"$num""-""$(printf "%04d" $img_num)"".jpg"

My naming convention produces file names of the format video number-image number.jpg. So for example, the 25th image extracted from GRMN4567.MP4 would be named 4567-0025.jpg.

And we’re almost there! Now we just need to put the metadata from step 2 into the images we just generated.

Step 4 - Add the GPS and time metadata to the images

You can write tags to files using exiftool using the format:

exiftool -<key>=<value> <file name>.jpg

You can add multiple tags in a single line.

exiftool -<key1>=<value1> -<key2>=<value2> <file name>.jpg

Note that exiftool only supports specific keys, so it won’t write the metadata if it doesn’t know what the key is. It creates a new image by default, so to avoid duplicating each image, add:

exiftool -overwrite_original -<key1>=<value1> -<key2>=<value2> <file name>.jpg

This will write a line to the terminal to confirm after every single image. To avoid that, redirect the output to /dev/null. This tells the terminal to throw the output into a black hole, or the wardrobe to Narnia, or anywhere else besides the terminal.

exiftool -overwrite_original -<key1>=<value1> -<key2>=<value2> <file name>.jpg 2> /dev/null

For Panoramax to accept your images, you need all of the following tags:

-gpslatitude=45.6789
-gpslongitude=-123.456789
-gpslatituderef=N
-gpslongituderef=W
-datetimeoriginal=2000-01-02T03:04:05

If you are missing these, Panoramax will reject your image. Note that the latitude and longitude ref tags are necessary because exiftool doesn’t understand negative coordinates as being in the southern or western hemispheres. You have to provide them separately for the GPS data to be read correctly. If you forget to add them, Panoramax may accept the image but put it in the wrong place. The date and time should be given in ISO 8601 format. If you don’t specify a time zone, Panoramax will assume local time and automatically convert it to UTC on their site.

You can theoretically add any tag in the exif specification. Some ones I like for Panoramax are:

-subsectimeoriginal=067
-author=FeetAndInches
-make=Garmin
-model="Garmin 47 Dash Cam"

The SubSecTimeOriginal field is important for getting Panoramax to put your sequence in the right order. Since the images come from a dash cam, speeds of 10-20 m/s are common, so multiple images are taken per second of video. The DateTimeOriginal tag does not preserve fractional seconds (even if you provide them when writing the tag), so several pictures would be recorded as the same time and Panoramax would have to guess their order. Note that this needs to be provided as an integer string after the decimal point. So for a time of 51.328 seconds, you would write -subsectimeoriginal=328. For a time of 51.1 seconds, you would just write -subsectimeoriginal=1. For a time of 51.001 seconds, you would need to include leading zeroes as -subsectimeoriginal=001.

If you don’t use the SubSecTimeOriginal tag, you can still get Panoramax to show your images in order if you use a suitable file naming convention. You can open the sequence on the website and select the option to sort by file name.

The author tag is just nice to attribute that it’s your image even if it gets shared outside Panoramax. The make and model tags help fill in some of the camera information on Panoramax and helps determine your GPS accuracy, which is used to determine the image’s quality score.

You can do step 4 in the same loop as step 3. Since the coordinates and time will change for each image, the command will look messy like:

exiftool -overwrite_original -gpslongitude=$lon -gpslatitude=$lat -gpslatituderef=$ns -gpslongituderef=$ew -datetimeoriginal=$timestamp -author="$exif_author" -subsectimeoriginal="$subsec" -make="$exif_make" -model="$exif_model" -usercomment="$exif_comment" "$output_dir"/"$num""-""$(printf "%04d" $img_num)"".jpg" > /dev/null

Closing Notes

This post explains the basic principles of how to turn a video into usable images on Panoramax. I plan to write a second post going into the 201 level - things like how to deal with missing a single GPS measurement, duplicated measurements, getting sent to Null Island, how to detect erroneous data, using the videos immediately before and after to interpolate better at the edges, recursively doing this for multiple video clips, etc. But for now, I hope this has been useful to you.

If anyone is interested, I can share the entire scripts that I use right now. They’re a little buggy, only partially commented, and occasionally require some babysitting to make sure they work properly. But if something is better than nothing and you are willing to try and deal with someone else’s amateur code, please let me know.

Thanks for reading,

FeetAndInches

• I spent some time today improving the map data in my local area using the iD editor. As a local, I noticed that several roads were untracted

• added roads but i got confused while selecting presets- then i realised the more i do mapping, the better i will get with using presets. Each preset serves a unique purpose.

• Few weeks ago i spent time mapping my school in my city, i was soo fun- just wish they could use more updated satelite image.

Two years ago or so I started the OSM XRAY project, later I wrote about it in this blog post. Since then I have renamed this project to “OSM Spyglass” and I have kept working on it on and off.

At the State of the Map Europe 2025 in Dundee I gave a talk with the title “Everything Everywhere All At Once” about this project. You can see the video on Youtube. This got some people excited about the project, there is even some talk about putting the tool on OSMF infrastructure. Until this comes about the tool is now hosted at spyglass.jochentopf.com.

I am finally getting around to writing some more about what’s been happening since my first announcement and since the talk.

User Interface

I keep fiddling with the user interface. Optional globe view (not much to do for me now that Maplibre supports that out of the box), map is now resizable (horizontally), display of city names in some zoom levels, improved pop-up menus for keys and tags, and much more. Generally the UI has been getting faster and more reliable.

There are still some bugs to fix and plenty of possible improvements. And I’d be happy about feedback and ideas. Its quite a lot of information we are trying to show here in limited space, so good ideas on how to do that are needed.

Caching

In the first blog post I wrote about some caching that I implemented in the database. That did work but it turns out it is pretty useless. The user wants to access the newest data anway and we can keep up with minutely updates (at least in larger zoom levels), so I removed the caching completely for vector tiles and for high zoom rasters. Only raster images at zoom levels up to 10 are cached. Currently we can not deliver them fast enough otherwise.

Map updates

The database is updated from OSM using minutely diffs. We are usually about 3 to 5 minutes behind the OSM data, that’s just how long it takes the OSM servers to create the minutely diffs, push them out to their server and for our update job to download the data and to apply it to the database. It is unlikely we can improve on that much further. Spyglass shows the timestamp of the latest data it has in the bottom right corner. This timestamp is updated whenever new data is loaded, i.e. when you move the map or so.

Vector tiles are always generated on the fly from the current database, for higher zoom levels they contain all data, for medium zoom levels only “larger” objects are shown, i.e. long ways and larger areas. In small and medium zoom levels raster tiles are shown. They always contain all data. So for the medium zoom levels raster data in gray is overlayed with vector data in black (nodes and ways) or blue (relations). So you can see everything, but only click on the larger items.

Raster tiles in small zoom levels are only updated once per day, for zoom 0 to 7 this happens by taking the zoom level 8 tiles, and merging and rescaling them. I have spent quite some time on optimizing this. The first version happened in the database but only generated black-and-white tiles, the current version uses code written in Go which creates grayscale images which are much better than the black-and-white images. And it is much faster than the gdal tools I tried for this task. Gdal is a great tool, but, as an “all purpose tool”, it has to cope with all sorts of different data sources, projections etc. which makes it much slower than a specialized tool for a specific use case. It only takes a few minutes now to create the low zoom tiles from the zoom level 8 tiles. And they are not stored in the database any more but on disk which is easier and they are faster to use that way, too.

Rasters are still generated in the database from the data. That is, unfortunately, not as efficient as one might think. We don’t need to copy the data from the database into another process, and the cost of actually getting the data seems to be not that huge, but the rasterizing costs time. This is probably something that could be improved inside PostGIS, or maybe we have to get rid of this idea alltogether and move rendering outside the database. There is plenty of space to experiment and improve performance here.

Server

Originally I used pg_tileserv as server to create the vector tiles from the database on the fly. It could also be tricked into creating the raster tiles. But I also needed GeoJSON output and some other API endpoints. I experimented with pg_featureserv which did work, but having two servers with lots of specialized PL/pgSQL functions in the database plus an ever growing configuration for nginx (used as reverse proxy) became too complicated and error prone. So I decided to rewrite the server from scratch in Go. Turns out it is really easy to write robust and featureful HTTP servers in Go, it comes with everything you need; the only external library I am using is for accessing the database. And deployment is really easy: Just copy over one Go binary and restart the server, no extra configuration files or functions to update in the database etc.

Filters

Everything is done three times for nodes, ways, and relations. There are three sets of raster tiles, 3 sets of vector tiles. It is easy to switch those layers on and off in the UI. And then there is the key or tag filter. The vector tiles in higher zoom levels contain all the data, the filter is applied on the client, which is very fast. For raster tiles the filtering has to be done on the server which takes somewhat more time. Filtering is (silently) disabled on the small zoom levels, so you always see all data there. This isn’t great as a user experience, I’ll still have to figure out a way to make this transition more user friendly. Or, ideally, allow filtering on all zoom levels.

It is a lot of fun to zip around the map and look at far away places and how they are mapped. Try it out!. And if you have any problems or ideas, open an issue on Codeberg.

There has been a very interesting question on the OSM US Slack lately.

“Does anyone have a method to search through the OSM database for a building of a particular shape? I need assistance finding OSM buildings with this specific shape. They should be located in NJ, DE, northeastern MD, eastern PA, or southern NY.”

The question quickly exploded into a huge discussion. At the time of writing, there are already 71 replies.

Someone suggested :

“You could load OSM buildings into PostGIS and then use ST_HausdorffDistance to compare the geometries.”

From there, the discussion veered into how to solve that specific puzzle and find the exact OSM building in question.

One person added, “So the strategy is: create the shape of the building you want to search for, scale it to, say, fill a 100x100 m bounding box or something. Ask Postgres to, within a search-area bounding box, take each building and scale it to a 100x100 m bounding box, compute the Hausdorff distance with the scaled input shape, and return all OSM element IDs and their Hausdorff distances, sorted in ascending order.”

Another said, “What I’m currently doing is combining several shape exports into a single file with around 20,000 objects that have concavity. Concavity plus more than 10 nodes eliminates most buildings.”

At that point, instead of hunting that elusive specific OSM building, I became more interested in the generalized version of the problem.

So I added my two cents to the discussion:

“The generalized version of this problem would be : Can we represent a shape in some kind of data type that allows us to computationally check whether two objects have the same shape, regardless of rotation and scaling?

I haven’t studied the Hausdorff distance yet, but I’m wondering whether it can solve this problem, or if there’s a better alternative—Hu moments, Procrustes analysis, Fourier descriptors for contours…”

Someone replied :

“Hu moments are a good option. Elliptic Fourier Descriptors, Shape Context Histograms, Turning functions, etc. I’ve experimented with those four while trying to classify sports pitches more accurately. You can actually get pretty far with just compactness, convexity, and aspect ratio, thankfully.”

Do you have any other ideas on how to solve this problem?

New CNEFE Tool Revolutionizes Street Name Correction in OpenStreetMap Brazil

The community of Brazilian mappers has just gained a powerful ally to improve one of the most crucial and, at the same time, challenging data points in any map: street names. The CNEFE Verification System platform has been launched, accessible at https://cnefe.mapaslivre.com.br, a tool created by and for the OpenStreetMap (OSM) community in Brazil, aimed at validating and correcting address data using the latest information from the 2022 IBGE Census.

The project is an initiative of UMBRAOSM (Union of Brazilian OpenStreetMap Mappers) and was developed by experienced mappers Raphael de Assis, president of UMBRAOSM and member of the OpenStreetMap Foundation, and Anderson Toniazo, both active members of the OSM Brazil community. The tool arrives to solve a long-standing bottleneck in national mapping: the updating and verification of street names based on official sources. The Challenge of Street Names in Brazil

For those mapping in Brazil, one of the biggest challenges has always been the lack of a complete, accurate, and freely accessible street database. Through the Demographic Census, IBGE compiles the National Registry of Addresses for Statistical Purposes (CNEFE) . This registry is a vast list of addresses from across the country, containing street names, address types, neighborhoods, and, in many cases, geographic coordinates, especially in rural and non-residential areas.

Historically, the OSM community has used CNEFE data from previous censuses (such as 2010) to enrich the map. However, the process was complex, involving downloading text files (fixed format), cross-referencing them with census tract shapefiles, and extensive manual work to match the information with the streets already drawn on the map, in addition to correcting spelling differences.

With the recent publication of the CNEFE 2022 microdata by IBGE, the need for an efficient tool to integrate this new data into OSM became even more evident. CNEFE System: A Bridge Between Official Data and the Collaborative Map

It is in this context that the CNEFE Verification System emerges. The platform created by Raphael de Assis and Anderson Toniazo is not just a data viewer; it is a complete work tool, designed to optimize the collaborative verification and correction workflow.

The system’s intuitive interface allows mappers of all experience levels to:

Visualize CNEFE 2022 Data: The tool presents official address data from the most recent census clearly, overlaid on the map.

Compare with OpenStreetMap: The mapper can easily identify discrepancies between a street name recorded in CNEFE and the name currently present in OSM.

Correct and Include Names: When a street in OSM is unnamed (very common in less mapped areas) or has a different name than the IBGE registry, the tool facilitates the correction and inclusion of the correct name directly on the map.

Fill Gaps: In places where IBGE registered addresses, but the corresponding streets have not yet been drawn in OSM, the application highlights these areas, encouraging the complete mapping of road geometries and, subsequently, the addition of names.

The platform is already at version 1.0, updated on January 22, 2026, and features rich support material for the community. Mappers can access a step-by-step tutorial with images, watch demonstrative videos, and even download complete PDF tutorials for offline consultation, ensuring everyone can make the most of the tool. The Strength of the Community Behind the Tool

The development of the CNEFE System is a testament to the power and organization of the OSM Brazil community. UMBRAOSM, under the leadership of Raphael de Assis, has stood out for promoting initiatives that facilitate and professionalize collaborative mapping in the country. Projects like “Mapeia Crato” have already demonstrated the capacity of unity in training new mappers and carrying out large-scale tasks.

The partnership between Raphael and Anderson in developing this tool reinforces the community’s commitment to not only use open data but also to give back, creating ecosystems that improve the quality of geospatial information available to everyone. Their work directly aligns with broader discussions within the community, such as the matching of CNEFE 2022 variables with OSM tags, a fundamental step for any data import or validation process. A Future with More Accurate Maps

The availability of the CNEFE System marks a significant advance for Brazilian mapping. By facilitating access and comparison with official Census 2022 data, the tool not only speeds up the map update process but also increases the reliability of the OpenStreetMap database as a whole.

For the end-user, whether a driver using a navigation app, a delivery person, or a researcher, the result is more accurate maps, with correctly identified streets and addresses that are easier to locate. The CNEFE tool is, therefore, a key piece in Brazil’s open data infrastructure, built collaboratively by those who understand the subject best: the mapping community itself.

Visit https://cnefe.mapaslivre.com.br and start contributing to a more complete and correct map of Brazil.

Nova Ferramenta CNEFE Revoluciona a Correção de Nomes de Ruas no OpenStreetMap Brasil

A comunidade de mapeadores brasileiros acaba de ganhar uma poderosa aliada para aprimorar um dos dados mais cruciais e, ao mesmo tempo, desafiadores de qualquer mapa: os nomes das ruas. Foi lançada a plataforma Sistema de Verificação CNEFE, acessível em https://cnefe.mapaslivre.com.br, uma ferramenta criada por e para a comunidade OpenStreetMap (OSM) no Brasil, com o objetivo de validar e corrigir os dados de logradouros utilizando as informações mais recentes do Censo 2022 do IBGE.

O projeto é uma iniciativa da UMBRAOSM (União dos Mapeadores Brasileiros do OpenStreetMap) e foi desenvolvido pelos experientes mapeadores Raphael de Assis, presidente da UMBRAOSM e membro da Fundação OpenStreetMap, e Anderson Toniazo, ambos membros ativos da comunidade OSM Brasil. A ferramenta chega para resolver um antigo gargalo no mapeamento nacional: a atualização e verificação dos nomes das ruas a partir de fontes oficiais . O Desafio dos Nomes de Ruas no Brasil

Para quem mapeia no Brasil, um dos grandes desafios sempre foi a falta de uma base de dados de logradouros completa, precisa e de livre acesso. O IBGE, através do Censo Demográfico, coleta o Cadastro Nacional de Endereços para Fins Estatísticos (CNEFE). Este cadastro é uma vasta lista de endereços de todo o país, contendo nomes de ruas, tipos de logradouro, bairros e, em muitos casos, coordenadas geográficas, especialmente em áreas rurais e não residenciais .

Historicamente, a comunidade OSM já utilizava dados do CNEFE de censos anteriores (como o de 2010) para enriquecer o mapa. No entanto, o processo era complexo, envolvendo o download de arquivos de texto (formato fixo), o cruzamento com shapefiles de setores censitários e um trabalho manual intenso para casar as informações com as ruas já desenhadas no mapa, além de corrigir diferenças de grafia .

Com a recente publicação dos microdados do CNEFE 2022 pelo IBGE, a necessidade de uma ferramenta eficiente para integrar esses novos dados ao OSM tornou-se ainda mais evidente . Sistema CNEFE: Uma Ponte entre o Dado Oficial e o Mapa Colaborativo

É nesse contexto que surge o Sistema de Verificação CNEFE. A plataforma criada por Raphael de Assis e Anderson Toniazo não é apenas um visualizador de dados; é uma ferramenta de trabalho completa, projetada para otimizar o fluxo de verificação e correção colaborativa.

A interface intuitiva do sistema permite que mapeadores de todos os níveis de experiência possam:

Visualizar os Dados do CNEFE 2022: A ferramenta apresenta os dados oficiais de logradouros do censo mais recente de forma clara e sobreposta ao mapa.

Comparar com o OpenStreetMap: O mapeador pode facilmente identificar discrepâncias entre o nome de uma rua registrado no CNEFE e o nome atualmente presente no OSM.

Corrigir e Incluir Nomes: Quando uma rua no OSM está sem nome (algo muito comum em áreas menos mapeadas) ou com um nome diferente do cadastro do IBGE, a ferramenta facilita a correção e a inclusão do nome correto diretamente no mapa .

Preencher Lacunas: Em locais onde o IBGE registrou endereços, mas as ruas correspondentes ainda não foram desenhadas no OSM, a aplicação sinaliza essas áreas, incentivando o mapeamento completo da geometria das vias e, posteriormente, a adição dos nomes.

A plataforma já está na versão 1.0, atualizada em 22 de janeiro de 2026, e conta com um rico material de suporte para a comunidade. Os mapeadores podem acessar um tutorial passo a passo com imagens, assistir a vídeos demonstrativos e até baixar tutoriais completos em PDF para consulta offline, garantindo que todos possam aproveitar a ferramenta ao máximo. A Força da Comunidade por Trás da Ferramenta

O desenvolvimento do Sistema CNEFE é um testemunho do poder e da organização da comunidade OSM Brasil. A UMBRAOSM, sob a liderança de Raphael de Assis, tem se destacado por promover iniciativas que facilitam e profissionalizam o mapeamento colaborativo no país. Projetos como o “Mapeia Crato” já demonstraram a capacidade da união em capacitar novos mapeadores e realizar tarefas de grande escala .

A parceria entre Raphael e Anderson no desenvolvimento desta ferramenta reforça o compromisso da comunidade em não apenas usar os dados abertos, mas também em retribuir, criando ecossistemas que melhoram a qualidade da informação geoespacial disponível para todos. O trabalho deles dialoga diretamente com discussões mais amplas na comunidade, como a correspondência das variáveis do CNEFE 2022 com as etiquetas do OSM, um passo fundamental para qualquer processo de importação ou validação de dados . #Um Futuro com Mapas Mais Precisos

A disponibilização do Sistema CNEFE marca um avanço significativo para o mapeamento brasileiro. Ao facilitar o acesso e a comparação com os dados oficiais do Censo 2022, a ferramenta não só acelera o processo de atualização do mapa, mas também aumenta a confiabilidade da base de dados do OpenStreetMap como um todo.

Para o usuário final, seja ele um motorista usando um aplicativo de navegação, um entregador ou um pesquisador, o resultado são mapas mais precisos, com ruas corretamente identificadas e endereços mais fáceis de localizar. A ferramenta do CNEFE é, portanto, uma peça chave na infraestrutura de dados abertos do Brasil, construída colaborativamente por quem mais entende do assunto: a própria comunidade de mapeadores.

Acesse https://cnefe.mapaslivre.com.br e comece a contribuir para um mapa do Brasil mais completo e correto.

Changeset: 178729012

Today I contributed to OpenStreetMap by improving map completeness in my local area in Bengaluru, Karnataka.

🔹 What I Worked On

Added a missing café using local knowledge Verified placement to ensure it was mapped at the correct entrance location Added appropriate tags including: amenity=cafe name= ##Bean Stop Café

Checked for duplicate entries before uploading

🔹 Mapping Approach

I focused only on verified, ground-truth information and avoided copying from copyrighted sources. All additions were based on direct familiarity with the area.

🔹 Quality Checks

Ensured the point was not placed on the roadway Confirmed correct spelling and capitalization Reviewed surrounding features for consistency

🔹 Objective

The goal was to improve local POI completeness and contribute accurate, structured data to OpenStreetMap. This is part of my effort to make consistent, quality-focused contributions rather than large, unverified edits.

In one of my previous blog posts, I explored how to read live vehicle data through the OBD II port that is present in most (modern) cars. As mentioned in the outlook, the next step in my project is to combine vehicle telemetry with (accurate) positional information in order to enable more advanced analysis. To achieve this, I created a small GNSS test setup. The platform for all experiments is again a Raspberry Pi. For a first comparison, I selected two GNSS boards from Waveshare: the L76X GPS HAT and the ZED F9X GPS RTK HAT.

Why these two modules?
The L76X is an inexpensive entry level device that is suitable for navigation, mapping or general position tracking. It supports GPS and BDS and normally delivers a position accuracy of a few meters. The ZED F9X belongs to a completely different class. It is a multi band GNSS receiver that supports real time kinematic (RTK) processing. When correction data is available, it can reach accuracy in the range of centimeters, which makes it suitable for robotics, surveying, precision agriculture or any application that requires very accurate geolocation data. The antenna systems also show clear differences. The L76X includes a simple single band GPS antenna, while the ZED F9X works together with a multi band active GNSS antenna that allows reception of several frequency ranges at once. This antenna design is essential for achieving the high accuracy that the ZED F9X is capable of.

From the provided software to writing my own scripts
Both modules are delivered with example software and Python scripts on the manufacturer web pages. I tried using these examples first, but outdated Python versions and older code libraries quickly created compatibility problems. Because of this I moved directly to writing my own scripts, which turned out to be the better choice later on. The L76X operates at one update per second in its default configuration, but it can be configured to send up to ten updates per second. The ZED F9X can operate with even higher update rates, in some cases up to twenty five updates per second depending on the selected messages. However, not every communication protocol supports these higher update rates. I started with NMEA, which worked well up to ten updates per second. Above that limit the protocol becomes inefficient because the messages are relatively large. For the ZED F9X, switching to UBX made much more sense because UBX uses compact binary messages. Unfortunately the L76X does not support UBX, which means NMEA remains the only option for that board.

What comes next?
With the hardware and software configured and with automated startup and first measurement routines working reliably, the next step will be real world testing inside a car. In particular, I want to find out how the speed of the vehicle affects the quality of the GNSS measurements, how different surroundings such as hills, forests and tall buildings influence the accuracy, and how big the practical performance gap is between the simple L76X with its basic antenna and the ZED F9X combined with a multi band active antenna.

Automatic Pedestrian Detection at Signalised Crossings

Hi everyone,

I recently noticed that many modern pedestrian crossings are equipped with automatic detection sensors that trigger the traffic signal without requiring a push button.

Currently, in OpenStreetMap, we can tag:

• highway=crossing and crossing=traffic_signals for signalised crossings
• button_operated=yes/no to indicate if a manual button is present
• traffic_signals:sound=yes/no for auditory signals

However, there is no standard way to indicate automatic activation by a detector for pedestrians or vehicles.

To address this, I have proposed a new tag on the OSM forum: detector_operated=yes/no, which would clearly indicate that a traffic signal is automatically triggered by a detector.

You can view and comment on the proposal here: https://community.openstreetmap.org/t/proposal-tag-traffic-signals-detector-operated-pedestrian-presence-sensor/141624

Here is an example illustration showing automatic pedestrian detection:

This tag would help improve mapping of intersections, pedestrian routing, traffic simulation, and accessibility information.

I’d love to hear your thoughts and experiences with automatic pedestrian detection at crossings in your area!