Last September I wrote about a concept where instead of hand-listing 15–30 recycling:* tags on every packaging container, the user could just pick the container’s colour and let the editor auto-add the right tags. Well, now the concept has become a working prototype.

Estonia’s container colours try to follow the Danish standard: paper blue, glass green, metal/plastic packaging yellow. Other countries and regions use different colours, but across EU paper, glass and packaging have surprisingly consistent colouring.

Source: European Commission, “Harmonising waste-sorting labels across the EU” (2023).

… See full entry

Second day of “quick” weekend project.
Frankly, I’ve run out of interesting things to map around my immediate surroundings. During the holiday season I travelled around the countryside and noticed long stretches of cycleways running alongside highways, occasionally featuring benches, bins, and similar roadside infrastructure. On one trip I tried mapping a rural street using EveryDoor, but the result was similar to summer cycling: frequent stopping dropped my average speed by 10–15 km/h.

I needed a solution where I could mass-save coordinates while moving, and deal with proper mapping later. Vespucci’s copy-paste workflow is probably the closest thing in the OSM ecosystem, but it still requires first tagging a node, then tapping the correct spot on the map. If the map is accidentally dragged, follow-position mode is disabled, and changing the type of copied element requires tagging a new node.
After concluding development I was suggested OsmAnd may support something similar.

I’m android user, so the problem was phrased as “Is there some Android app with a super fast UI for saving coordinates?”

A quick search showed that virtually no existing apps allow bulk bookmarking of unnamed unorganised coordinates My intention was save location something i could later properly map from aerial images. Most apps seemed to require at least 2-3 taps to save position, often with typing bookmark name.

Functional requirements

For time estimates and comparison I used my typical summertime EveryDoor mapping experience. Potential mapping-assisting app should consider these points:

… See full entry

In order for OpenStreetMap to thrive, we need to attract and retain new mappers. To be welcoming to newcomers, we should avoid high barriers to starting mapping and instead support contributions that can be made with limited time, context, and experience. StreetComplete is a great example of this approach: by asking simple, well-scoped questions, it enables contributors to improve data quality in small, incremental steps. An effort-inclusive tagging philosophy builds on this idea by encouraging tagging schemas where each additional piece of information can be added independently and still be useful on its own. For example, amenity=bench is still a bench regardless if mapper knew about backrest=* and armrest=*.

I am writing this because I have encountered cases where newcomers are advised to follow practices that I consider unnecessarily demanding for basic contributions. A particularly stark example appears in the context of CCTV and ALPR mapping, where a sub-community recommends mappers to take high-resolution photographs, research manufacturers and exact models at home, and consult product datasheets for adding a single camera to OSM. While such detailed work can be valuable, it not only risks discouraging participation, but also makes incorrect data harder to detect if mapper misidentifies the model.

… See full entry

Started this year with a weekend mapping project: locate and map public traffic camera feeds from city’s website. Day 2 and I’m halfway done, about 130 out of ca 260 have live feed links now. Roughly 5 of them weren’t previously mapped at all.

Purpose of this diary entry is to save the checker scipt in publicly accessible place for unlikely reuse. Script scrapes all possible camera IDs and cross references them against already mapped feeds via overpass.

EDIT: Project was mostly completed as of 2026-01-02, changeset/176761784 outlines up to 10 missing cameras yet to be mapped.

Overpass query to get already mapped ones:

[out:json][timeout:25];
area(id:3600079510)->.searchArea;
node["contact:webcam"~ristm](area.searchArea);
out geom;

… See full entry

(Writing a short stub in case i forget it again)

Estonian mappers may have already noticed how this year Land Board’s imagery is still missing. Previously new orthophotos were captured in March-April, preliminary release was in May-June and TMS layers were available in OSM editors by around September, then this year there are no images.

Turns out on 31st of March 2025 someone filed a complaint to Chancellor of Justice, that their garden hose can be identified on the imagery. On 27th of November chancellor’s response was published and public broadcaster published few small news:

• EST: https://www.err.ee/1609869541/oiguskantsler-palub-kaaluda-kaardirakenduste-eraelulist-detailsust
• EST: https://www.err.ee/1609870686/maa-ja-ruumiamet-plaanib-geoportaali-andmeid-uldisemaks-muuta
• ENG: https://news.err.ee/1609869930/land-and-spatial-board-to-make-publicly-available-map-data-less-detailed
• Original source documents:
  • EST PDF: https://www.oiguskantsler.ee/sites/default/files/2025-11/Orto-%20ja%20kaldaerofotode%20avalikustamine.pdf
  • Sample images: https://adr.rik.ee/okk/dokument/18175002 (asice is basically zip file, you’d need digidoc4 to open it).
    • Mirror at Land Board’s registry: https://adr.envir.ee/et/document.html?id=8c7c0dd4-17c5-463b-a00c-57c6019ea8d8
  • Original complaint (restricted access): https://adr.rik.ee/okk/dokument/16914665
  • § 26 of constitution which according to chancellor prohibits aerial images: https://www.riigiteataja.ee/en/eli/ee/521052015001/consolide/current#para26

Why this matters to OSM?

At least 90% of OSM’s data originates from Land Board’s imagery, either through imports or via usual imagery tracing. Esri and Bing are also using using Land Board’s data for Estonia.

… See full entry

I have been preparing a RFC for several days, but now weekend is over and i won’t have time to finish things up. Here’s drafted tldr of a draft of a RFC in case this ends up as another forgotten project. Scope of this proposal is limited to Estonia. For international uses, I suggest to read EU report on waste sorting standardisation.

Problem: When surveying packaging recycling containers (PRC) it’s repetitive to list all kinds of waste collected there. There’s also risk of errors introduced by human input. My initial estimate is that trio of standard PRCs should get about 20-30 recycling:* tags.

Observation: PRC colours are standardised across Estonia – Paper blue, glass green and metal/plastic/beverage yellow (source). While Estonia has adapted Danish color schema as nationwide standard for garbage collection, PRCs have bit different colours. Standard-PRCs are often accompanied by reusable clothes container (no standard colouring).

Objective: Simplify & standardise mapping of different waste collected.

• Mapper has to simply pick colour(s) of the container(s) they see and..
• …preset ensures consistency of different waste types listed.
• Therefore PRC can be mapped at higher quality from further distance (assuming mapper doesn’t know PRC colour codes by hearth.

Solution: Introduce localised custom (iD & JOSM) editor tagging preset (e.g “Pakendikonteiner EE”)

Downsides:

• Difficult to scale legal rules up to international level, in some countries even to county level. Some cities may use own colours.
• Unclear if this idea is technically fully achievable (editor limitations, namely adding multiple colours to single node)
• Technical scale-up difficulties – possible performance loss is each major city or county in developed world gets own preset.

Initial idea originally published on 2025-09-12. Full 40 pages of notes are not processed yet.

… See full entry

RapiD editor has rather unique feature that it can flag pedestrian crossings where node and way are tagged differently. But how to know where are such crossings if you can’t load entire city or country into iD editor? Luckily there’s overpass syntax for that. Quite a few people found this query useful, therefore I’m sharing it with wider audience.

Most of query was produced by LLM after feeding it with Overpass QL language reference. Only parent.u syntax needed manual fixing. I decided to use dynamic comparison of tag values because I wasn’t sure what would happen if there were some unique tagging typo, such as crossing=marked2 or similar.

[out:json][timeout:180];
{{geocodeArea:Estonia}}->.a;

/* Ways that explicitly have crossing=* */
way(area.a)["crossing"]->.ways;

/* Loop each way as .parent */
foreach.ways->.parent
{
  /* crossing=* nodes of parent, but
     with different crossing value */
  node(w.parent)["crossing"]
    (if: t["crossing"] != parent.u(t["crossing"]))
    ->.badnodes;

  /* Output if there is at least one mismatching node */
  (.badnodes;)->._;
  if (count(nodes) > 0)
  {
    .badnodes out tags geom meta; /* the mismatching node(s) */
    .parent   out tags geom meta; /* the parent way */
  }
}

Originally published at OSM World Discord on 2025-08-23

First post in hopefully a series of entries where I’m planning to share various OSM-related experiments I have conducted over the years.

Mapper asked if area should be mapped as grassland, scrub or heath. Since this kind of information is better to be extracted from infrared imagery, without knowing where the mapper is from, I pointed them to use global satellite dataset provided by European Space Agency (OSM wiki link) at Copernicus browser.

Two most commonly user IR imageries are using CIR-NRG and CIR-NGR styles. These acronyms essentially mean that when compared to regular RGB (red, green, blue) pictures, infrared images drop blue signal channel and instead use IR as red, and then original red and green as green and blue. For NRG, red becomes green and green turns blue; NGR is vice versa with green staying green and reds are blue.

Turned out that while Copernicus does have multiple infrared imagery layers (such as one simply called False Color is NGR), but because infrared channel is relatively overexposed compared to visible light, then default configuration showed nothing but red (IR) patches on black earth. Solution was building a custom rendering with linear adjustments.
In hindsight, Copernicus browser has button called “Effects and advanced options applied” where one could apply most of those transformations directly without custom layers.

Anyways, custom layer is basically javascript code that should execute on client’s browser for every single pixel on image and calculate RGB values for each. Here’s the tutorial.
I haven’t figured out most feasible way to add pictures to diary posts yet.

• Go to https://browser.dataspace.copernicus.eu/
• Click on green diagonal arrow (↗️) on sidepanel to see latest images
• Select Layers -> Custom (at bottom of list) -> Custom script (rightmost tab)
• Paste script and click apply below textbox.
• Colour balance and lightness can be tweaked using sliders under button “Effects and advanced options applied”

… See full entry