<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>News on Open Location Stack</title><link>https://openlocationstack.com/news/</link><description>Recent content in News on Open Location Stack</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 27 Apr 2026 13:00:00 +0000</lastBuildDate><atom:link href="https://openlocationstack.com/news/index.xml" rel="self" type="application/rss+xml"/><item><title>Indoor maps need to grow up</title><link>https://openlocationstack.com/news/indoor-maps-need-to-grow-up/</link><pubDate>Mon, 27 Apr 2026 13:00:00 +0000</pubDate><guid>https://openlocationstack.com/news/indoor-maps-need-to-grow-up/</guid><description>&lt;p&gt;Most companies that use indoor maps still treat them as an afterthought. They&amp;rsquo;ll buy an expensive location system, for example based on ultra-wideband, and spend a lot of money installing the necessary infrastructure and dialing that in. But the maps that go with this system do not get much attention from a practical or aesthetic point of view. Most people base their maps on architectural drawings. The dominant aesthetic is that of a technical drawing. Quite often these come in bitmap form. You can see this clearly when zooming in. The edges get all pixelated and the text labels become blurry.&lt;/p&gt;</description></item><item><title>Open Location Hub 0.1.0 is out</title><link>https://openlocationstack.com/news/open-location-hub-0-1-0/</link><pubDate>Tue, 14 Apr 2026 08:06:00 +0000</pubDate><guid>https://openlocationstack.com/news/open-location-hub-0-1-0/</guid><description>&lt;p&gt;&lt;a href="https://github.com/Open-Location-Stack/open-location-hub/releases/tag/0.1.0"&gt;Open Location Hub 0.1.0&lt;/a&gt; is now published.&lt;/p&gt;
&lt;p&gt;This is the first public release of Open Location Hub. Our goal with this release is to offer a full implementation of the current API surface and solicit feedback that helps define what the eventual &lt;code&gt;1.0&lt;/code&gt; release should look like.&lt;/p&gt;
&lt;h2 id="what-is-in-010"&gt;What is in 0.1.0&lt;/h2&gt;
&lt;p&gt;For the initial &lt;code&gt;0.1&lt;/code&gt; scope, Open Location Hub now implements the full omlox API surface planned for this release.&lt;/p&gt;</description></item><item><title>Benchmarking Open Location Hub with OpenSky and replayed traffic</title><link>https://openlocationstack.com/news/benchmarking-open-location-hub-with-opensky/</link><pubDate>Wed, 08 Apr 2026 08:00:00 +0000</pubDate><guid>https://openlocationstack.com/news/benchmarking-open-location-hub-with-opensky/</guid><description>&lt;p&gt;We wanted a benchmark built from real traffic, easy to rerun locally, and good at showing where Open Location Hub starts to drop work.&lt;/p&gt;
&lt;h2 id="intro-opensky-and-the-benchmark-input"&gt;Intro: OpenSky and the benchmark input&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://opensky-network.org/"&gt;OpenSky Network&lt;/a&gt; publishes live aircraft state data from a community-operated sensor network. For this benchmark we used the Germany preset, captured about five minutes of traffic, and stored the raw &lt;code&gt;location_updates&lt;/code&gt; stream as NDJSON.&lt;/p&gt;
&lt;p&gt;The input is both realistic and repeatable. We start from a real capture and replay the same file against the hub whenever we change the runtime.&lt;/p&gt;</description></item><item><title>Easter Update: soft launch, public repositories, and rapid hub progress</title><link>https://openlocationstack.com/news/easter-update-2026/</link><pubDate>Thu, 02 Apr 2026 07:00:00 +0000</pubDate><guid>https://openlocationstack.com/news/easter-update-2026/</guid><description>&lt;p&gt;Open Location Stack has moved from a private build effort to something partners can inspect, test, and challenge directly.&lt;/p&gt;
&lt;p&gt;At &lt;a href="https://www.logimat-messe.de/en"&gt;LogiMAT in Stuttgart&lt;/a&gt;, we soft-launched the &lt;a href="https://openlocationstack.com/"&gt;Open Location Stack website&lt;/a&gt;. The goal was simple: show the work to RTLS partners early, while the architecture is already credible and still open to feedback.&lt;/p&gt;
&lt;p&gt;At the same time, we made our first two GitHub repositories public:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://openlocationstack.com/open-location-hub/"&gt;Open Location Hub&lt;/a&gt; on &lt;a href="https://github.com/Open-Location-Stack/open-location-hub"&gt;GitHub&lt;/a&gt;, which is the integration backbone of the stack and the first component we expect many partners to evaluate seriously.&lt;/li&gt;
&lt;li&gt;&lt;a href="https://openlocationstack.com/floor-plan-editor/"&gt;Floor Plan Editor&lt;/a&gt; on &lt;a href="https://github.com/Open-Location-Stack/floorplan-editor"&gt;GitHub&lt;/a&gt;, which gives the stack an open indoor mapping foundation for creating and maintaining structured venue data.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;That order matters. For many teams, the hub is where the value becomes concrete. It can sit between existing RTLS deployments, normalize location flows, and open a path toward mixed-vendor interoperability without forcing a rip-and-replace project.&lt;/p&gt;</description></item></channel></rss>