OpenStreetMap logo OpenStreetMap

Diary Entries in English

Recent diary entries

Posted by HealthArc on 23 April 2025 in English.

HealthArc is an advanced care management platform providing industry leading digital health solutions to streamline patient engagement and health outcomes. We empower healthcare providers to deliver enhanced patient care with cellular medical devices and Remote Patient Monitoring (RPM) software that allows real time monitoring of patients out of clinical settings. Our HIPAA compliant remote patient monitoring platform is capable of delivering Chronic Care Management (CCM), Remote Therapeutic Monitoring (RTM), Transitional Care Management (TCM), Principal Care Management (PCM), and Behavioral Health Integration (BHI) services to manage patients with one or multiple chronic illnesses. We implement the latest updates to our virtual healthcare software for efficient billing and reimbursements. Book a demo now to find out how HealthArc can help your healthcare organization in meeting its care delivery goals. For more insights visit: https://www.healtharc.io/

Posted by HealthArc on 23 April 2025 in English.

HealthArc is an advanced care management platform providing industry leading digital health solutions to streamline patient engagement and health outcomes. We empower healthcare providers to deliver enhanced patient care with cellular medical devices and Remote Patient Monitoring (RPM) software that allows real time monitoring of patients out of clinical settings. Our HIPAA compliant remote patient monitoring platform is capable of delivering Chronic Care Management (CCM), Remote Therapeutic Monitoring (RTM), Transitional Care Management (TCM), Principal Care Management (PCM), and Behavioral Health Integration (BHI) services to manage patients with one or multiple chronic illnesses. We implement the latest updates to our virtual healthcare software for efficient billing and reimbursements. Book a demo now to find out how HealthArc can help your healthcare organization in meeting its care delivery goals.

The relationship between municipalities and populated places in the United States is often not obvious, especially in New England due to the naming of their local governments. Naming them towns has blurred the distinction of populated places and municipal governments, when in reality, a clear distinction can be made between the two.

First, let’s look at the things almost everyone should agree with. Nodes tagged with a “place” tag can be referred to as “populated places”, or named concentrations of people. The GNIS definition of a populated place says it best: “Place or area with clustered or scattered buildings and a permanent human population (city, settlement, town, village). A populated place is usually not incorporated and by definition has no legal boundaries. However, a populated place may [correspond with a] “civil” [entity], the legal boundaries of which may or may not coincide with the perceived populated place. Distinct from Census [places] and Civil [entities].” In other words, nodes with a place tag refer to a human settlement, NOT to a municipality. They are the places one might see on a green direction sign while on the road. The exception to this is if the municipal boundary corresponds to the extent of the populated place, which is the norm in most states.

However, in New England, town boundaries are usually formed out of straight lines and rivers, not with the intention of delineating the boundary of a populated place. Therefore, even if a town shares a name with a populated place within its borders, the populated place will not always fill the entire municipality, leaving room for other populated places to fill the rural areas. Some municipalities even lack a populated place with the same name as it. This leads to there being no 1:1 correspondence between municipalities and populated places in New England.

See full entry

I’ve fixed some accidental error introduced in changeset 165092634 by user “Hooptie Bike Lounge”.

Both errors are now fixed in changeset 165210184.

Error #1 : Bowen St

They accidentally moved a node of Bowen St by 100’s of feet.

  • Before their edit the Bowen St node was here

  • their edit accidentally moved the node 100’s of feet to here.

Error #2 : Sidewalk on Boston Ave

They accidentally moved a node 100’s of feet for the sidewalk along the south side of Boston St near Hooptie Lounge.

  • Before their edit the Boston Ave sidewalk node was here

  • their edit accidentally moved the node 100’s of feet to here

Location: Longmont, Boulder County, Colorado, United States

Hey fellow mappers! 👋🌍

I’m beyond excited to share that the global State of the Map (SOTM) 2025 will be held in Manila, Philippines 🇵🇭 — and preparations are already in motion! For those who are also planning ahead, here are some important links you should definitely bookmark::


🔗 Link Type URL
🌍 Official Website https://2025.stateofthemap.org/
📝 Call for Participation (CfP) https://2025.stateofthemap.org/calls/general/
🧪 OSM Science Track – Call for Abstracts https://2025.stateofthemap.org/calls/osm-science/
💸 Call for Travel Grant https://2025.stateofthemap.org/calls/travel_grants/


🌐 Official SOTM Social Media & Platforms

🌐 Platform Link
🐘 Mastodon https://en.osm.town/@sotm
📺 YouTube https://youtube.com/stateofthemap
📘 Facebook https://facebook.com/stateofthemap
📸 Instagram https://instagram.com/stateofthemap
💼 LinkedIn https://www.linkedin.com/company/stateofthemap/
💬 Telegram Group https://t.me/sotm_international
📝 OSM Wiki Page https://wiki.openstreetmap.org/wiki/State_of_the_Map_2025
📣 Official Blog https://blog.openstreetmap.org
💻 GitHub https://github.com/openstreetmap/stateofthemap-2025
❤️ Support OSM https://support.openstreetmap.org

If you’re thinking of applying, speaking, or volunteering — go for it! The energy, the people, and the purpose behind SOTM are truly unmatched.

Let’s map the future, together. See you in Manila! 🇵🇭


Brazil Singh,
On behalf of the SOTM organizing committee.

It’s difficult to write in all map style languages. A style written in JSON, like MapLibre, has a few extra pain points because JSON is not designed for editing by humans.

Some “common” style languages are

  • CartoCSS
  • Mapnik XML
  • MapCSS
  • MapServer
  • MapLibre GL/Mapbox GL

Some, like CartoCSS, are designed for human editing, while others, like Mapnik XML, serve as a lower-level language. MapLibre GL falls into this category of not being designed for editing by humans. MapLibre GL preprocessors like glug were designed to help with this, but none of them have taken off. Other style projects like openstreetmap-americana have taken a different route. Their developers have written a program in JavaScript that generates the style.

I’m taking a different route. I’m creating a language that uses minimal pre-processing of its input to produce MapLibre GL. I don’t aim to solve every difficulty with MapLibre GL, only the ones that impact me the most. The end result will be a pre-processing language

The biggest problems I encounter when writing MapLibre GL are

  1. No comments

    Comments are essential so other readers understand what’s written

  2. Everything has to be in one file.

    With large styles this is a burden. More than one file makes it easier to edit.

  3. Having to repeat definitions instead of using a variable.

    Something like a color or symbol definition might appear a dozen times in the style. If you want to change it, you need to make sure you got all the occurrences.

  4. Inability to make versions of the style in different colors.

    When you only want to change a few superficial elements of the style, you want to contain those changes to one file.

  5. Not having support for more colorspaces

    I work in perceptual colorspaces like Lch. It’s a lot of converting that the computer should automate.

What issues have you found when writing MapLibre GL styles?

This blog post explains how I handle a typical bug report for the new OSMF Shortbread tiles. Here, I focus on the “island” seems to be missing from “place_labels” report from SomeoneElse

After verifying that the report is correct, I set up my editor environment. It’s useful to have an environment that syntax highlights Jinja SQL files, as well as other files. I use a Visual Studio Code-based editor with the Better Jinja plugin.

The issue is in the place_labels layer. After checking Shortbread, I see that place=island should show at zoom 10 or higher, so there is a bug. Tilekiln creates tiles by reading definitions from shortbread.yaml, so I check there for the place_labels definition.

place_labels:
    description: Holds label points for populated places.
    fields:
        kind: Value of OSM place tag
        name: *name
        name_en: *name_en
        name_de: *name_de
        population: Value of OSM population tag
    sql:
    - minzoom: 4
        maxzoom: 14
        file: shortbread_original/place_labels.04-14.sql.jinja2

This file shows that for zooms 4 to 14, the SQL for the layer is in shortbread_original/place_labels.04-14.sql.jinja2. Since this file is in shortbread_original, osm2pgsql-themepark created it, and it remains unchanged.

SELECT
        ST_AsMVTGeom(geom, {{unbuffered_bbox}}, {{extent}}, {{buffer}}) AS way,
        name,
        name_de,
        name_en,
        kind,
        population
    FROM place_labels
    WHERE geom && {{bbox}}
        AND {{zoom}} >= minzoom
    ORDER BY population desc

There aren’t any obvious bugs in the SQL. There’s no filtering out of islands, so either the data isn’t making it into the place_labels table or it has the wrong zoom. The data is loaded by osm2pgsql, and shortbread.lua tells osm2pgsql how to do that.

themepark:add_topic('shortbread/places')

See full entry

Posted by -karlos- on 18 April 2025 in English.

Once I had a concept to render gabled roofs in 3D with OSMgo.org but it did not work. Often the roof looked like broken down. After a long time of abandoning OSMgo, I found a “working” solution and used it in my code. But no, the browser got stuck in an infinite loop %-(

May be update the version of ThreeJS, after years? That took me many many hours. For the geeks: Using es6 needed much export and import. After hours of typing, I fond at last VS-Code plugin to show me the missing variables. Not using “with” any more needed a lot of “this”. Worse, ThreeJS dropped the geometry.merge() and changed the geometry attributes, typing, typing. Hey, something positive!: Because now Vertex-Colours are used, only one Draw-Call per 3D-tile is needed. OSMgo should run faster now.

With the new ThreeJS the infinite loop was gone, but: the roof was at the wrong place and direction. Some adaptions of the theft code were needed. Now, the City of London looked much better than before. Oh wait, all roofs were mirrored, one more adaption.

See full entry

Posted by kumakyoo on 18 April 2025 in English.

This blog post is part of a series of blog posts about the new OSM file format “OMA”. This is the seventh post. At the end of the article you’ll find links to the other blog entries.

 

To create and use blocks and slices, you need to know the type of an element - is it a highway, a landuse or a barrier. And if it is a highway, is it a primary, a secondary or a footway.

 

Keys

Apart from relations where the type key stores it, this information is not available within OSM data. Again, it has to be guessed, and there is much discussion on the forums and elsewhere about the “main keys”, as they are sometimes called. Several apps, such as most OSM editors, contain such a list, but the lists are not always the same.

The approach I took was this: I counted all the keys of all the tags of all the elements and took the one that appeared most often in this list. I considered this the first main key and removed all elements with this key from the set of elements. Then I repeated this process.

After a while some “dirt” remains: elements that do not show a clear “main key”. I think if you start digging around in that dirt, you might find some hidden gems, that is, main keys that aren’t used very often, because the items they represent do not exist very often in the real world. But I didn’t.

I repeated this process twice,1 once for nodes and once for ways. You have to keep an open mind, because sometimes the top key is clearly not a “main key”, for example name pops up after a while. Addresses needed some special treatment, because there is no address key. Addresses are stored as a collection of addr:* keys. Fortunately the addr:housenumber is almost always present, so I used that as the key for addresses.2

 

Values

See full entry

This post is the result of a student project. The work was done by the following group of students: Alice Rey, Jihene Haj Hamouda, Yahia Heni, Mohammed El Mehdi Alaoui, Kaies Mhadhbi.

Example

Try our online demonstration to find your own shade-optimized route! Discover how we improve pedestrian comfort during hot days by prioritizing shaded paths. (demo restricted to the Nantes Area)

Introduction

This project focuses on enhancing pedestrian routing in OpenStreetMap (OSM) by incorporating shade into route computations. Exposure to direct sunlight significantly affects pedestrian comfort, especially during hot weather, making shaded routes preferable even if slightly longer. Despite this importance, existing OSM data related to shade has typically been qualitative and limited in precision. To address this, we developed and implemented two complementary methods to integrate detailed shading information into OSM-based routing engines like Graphhopper:

See full entry

Simple 3D buildings

They are ofcourse not M4TR as you use the building=yes tag and you add colours, height and roof shapes.

But for more complicated buildings?

What if there is an apartment building with different colours? Am i allowed to use building:part=yes for each colour? Or is that M4TR?

Monuments

Monuments can be a little sad to just se as a square or even a node, so could i map them in 3D? That sure is M4TR, but we want to map how it is in reality. So therefore it should be allowed? Right?

How an algorithm from the 80s sets the new standard for modern spatial indices

Geospatial indices are all around us. They allow us to search through millions of points in an instant answering questions such as “find me the closest bike repair shop” efficiently.

And yet there are still forgotten gems in the archives of computational geometry: Space-filling curve based spatial indices. With an optimization going back to the year 1981 this spatial index delivers surprising efficiency; and yet it is rarely discussed in the geospatial community.

Let’s go back in time and rediscover how we can build a spatial index on top of a space-filling curve to accelerate geospatial queries and simplify geospatial indexing for location-based applications.

Small note based on reader feedback: If you know about Z-Order Curves or Hilbert Curves already I still recommend you reading this as the post below will show you how use Z-Order Curves efficiently as a spatial index and that is something you probably don’t know yet.

The Z-Order Curve

The Z-Order Curve is one of many space-filling curves transforming multi-dimensional data into a single dimension while preserving locality. In the geospatial domain it allows us for example to transform longitude and latitude into a single number while preserving geographic proximity.

For spatial queries such as “find me the closest bike repair shop” we want to find points within a rectangular area. To search a rectangular area on the Z-Order Curve (highlighted in gray below) we start at the top left Z value of the rectangular area and walk the curve until we’re at the bottom right.

See full entry