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 https://wiki.openstreetmap.org/wiki/Key:crossing */
way(area.a)["crossing"]->.ways;

/* Loop each way as .parent */
foreach.ways->.parent
{
  /* https://wiki.openstreetmap.org/wiki/Key: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