🚀 QGIS2VectorTiles v3.2 is here!

🧩 Centroid Fill symbol layers now match QGIS behavior in the output web viewer - on the largest part or on every part.

🖼️ New Icon Quality setting for sharper sprites than ever.

🔥 Still using ESRI's VTPK? Switch to an open, free, and fully customizable workflow.

❤️‍🔥 Go #FOSS ! Boost, rate, and spread the word!

🔗 https://gallpeters.github.io/QGIS2VectorTiles/

#opensource #maplibre #vectortiles #qgis #gdal #gis #openlayers #geoserver #maptiler #mapbox

on s'amuse comme des petits fours avec #vroom

#openstreetmap #maplibre #openfreemap

I achieved something I find cool today: Displaying cliffs on my #openMapTiles vector tile based #openStreetMap map (using tiles from #openFreeMap

Not really complicated, but I haven't seen them on any of the maps on #mapTiler, #osm, or any of the other vector maps I look at.

Example: An end of the white cliffs of Dover, of cause, and a screenshot of the #mapLibre style rules. It is simply a line + a dashed line offset to the right. And it looks about like in OSM Carto. :)

weeklyOSM 829 is out, covering the @maplibre May newsletter, a new OSRM Trip demo for solving real-world routing puzzles, HOT's seagrass mapping initiative, and SotM 2026 details. A good 5-minute read for anyone building on the open mapping stack.

#OpenStreetMap #MapLibre
https://weeklyosm.eu/archives/18636

I'd like to hear #geo people's personal experiences with #Leaflet and #MapLibre - I only know the former but it looks like all the Cool Kids are using MapLibre these days? If I'm only trying to show tiled maps with markers, is there any benefit to a GL-based library?

The other question would be: How hard is it to switch from one to the other?

🚀 QGIS2VectorTiles v3.1 is out!

📍 Supports QGIS point label positions (on/around point).
⚡ Supports QGIS label priority.
🛡️ Validation warnings for invalid expressions.
🎨 Better sprite buffers.
🐞 Bug fixes and stability improvements.

❤️‍🔥 Please rate and boost to support #FOSS
🔗https://gallpeters.github.io/QGIS2VectorTiles/

#opensource #maplibre #vectortile #qgis #gdal #gis #openlayers #geoserver #maptiler #mapbox

This article originally appeared on The Fulcrum.

Welcome to this week’s The Programmer’s Fulcrum.

It’s your weekly curation of the essential news in the Open Media Network and Fediverse development communities with a focus on devastating big tech via Techno Anarchism.

As usual, we aim to provide actionable content you can use to destroy Techno Feudalism each week. It has the additional […]

MapLibre GL JS

https://voragine.net/link/maplibre-gl-js

Self-Hosted Google Maps egy Raspberry Pi-n

Mindig is lenyűgözött az a gondolat, hogy a saját négy falunk között is fusson egy olyan térkép szolgáltatás, ami nem függ az internetkapcsolattól. Egy olyan „Google Maps”, ami a saját gépemen fut, a saját adataimat használja, és akkor is működik, ha épp nincs net. Az inspiration a N.O.M.A.D. (Network of Offline Mapping and Discovery) projektből jött, akik egy teljes offline szolgáltatás stack-et álmodtak meg. Az ő nyomdokaikon haladva építettem meg a saját verziómat, ami egy Raspberry Pi-n fut, Docker konténerekben, és teljes Magyarországot lefedi.

A hardver – Mi ez a gép?

A szolgáltatás a xorp-archive.xorp.hu nevű gépemen fut, ami nem egy átlagos Raspberry Pi. Egy Raspberry Pi ARM64 architektúrájú eszköz, 8 GB RAM-mal, NVMe HAT kiegészítővel és egy 1 TB-os Crucial CT1000E100SSD8 NVMe SSD-vel. Ez nem a régi SD kártyás megoldás – az NVMe sebessége és megbízhatósága nélkülözhetetlen egy ilyen adatigényes stack működtetéséhez. A gép Ubuntu 24.04 LTS-t futtat, a kernel pedig a Raspberry Pi-hez optimalizált 6.8.0-1057-raspi.

Az ötlet – Miért építsünk offline térképet?

A válasz egyszerű: szabadság. Amikor nincs internet, vagy korlátozott a sávszélesség, a legtöbb térkép szolgáltatás használhatatlanná válik. Gondoljunk csak egy kirándulásra a Pilisbe, egy külföldi utazásra roaming nélkül, vagy épp egy olyan helyzetre, ahol az adatvédelem miatt nem szeretnénk külső szolgáltatókra bízni magunkat. Egy offline térkép ezekre mind megoldást nyújt.

A stack négy fő komponensből áll, amelyek Docker konténerekben futnak:

• OSM Tile Server – a térkép csempék (tile-ok) kiszolgálása
• Photon – címkeresés, geokódolás
• GraphHopper – útvonaltervezés (autó, bicikli, gyalogos)
• GraphHopper PT – tömegközlekedési útvonaltervezés (MÁV, Volánbusz, BKK)
• MapLibre GL UI – a webes felület, ami összefogja az egészet

Az architektúra áttekintése

Minden kérés egyetlen belépési ponton, a map-ui konténeren keresztül történik, ami egy Nginx reverse proxyként szolgál. Ez nemcsak egyszerűbbé teszi a konfigurációt, hanem kiküszöböli a CORS problémákat is, hiszen a böngésző számára minden kérés ugyanarról az origin-ről érkezik.

A Docker Compose – Minden együtt

A teljes stack egyetlen docker-compose-osm-extended.yml fájlban van definiálva. Lássuk a lényeget (az IP címeket és elérési utakat természetesen megváltoztattam a valóságban):

1. OpenStreetMap Tile Server – A térkép alapja

Az overv/openstreetmap-tile-server Docker image egy előre összeállított környezet, ami tartalmazza az Apache webszervert, a renderd-et (a csempe renderelő démont), a PostgreSQL-t PostGIS kiegészítővel, és a mod_tile-t, ami a csempe kiszolgálásért felel. Ez a négy komponens együtt teszi lehetővé, hogy a nyers OpenStreetMap adatokból szép, böngészhető térképi csempéket (tile-okat) kapjunk.

Az import folyamat

Minden egy PBF fájllal kezdődik – ez a Protocol Buffer Binary Format, az OpenStreetMap adatok tömörített formátuma. Nekünk a Magyarországra vonatkozó kivonatra van szükségünk, ami a geofabrik.de-ról szerezhető be. Ez a fájl a /home/osm/data/hungary-latest.osm.pbf elérési úton található.

Az import az osm-import konténer egyszeri futtatásával történik:

A konténer a shm_size: 1gb beállítással fut, mert az importálás és a renderelés során rengeteg megosztott memóriára van szükség a gyorsítótárazáshoz. Ez egy kritikus beállítás – ha kicsi a shared memory, a renderelés rendkívül lassú lesz.

Folyamatos frissítés

A legmenőbb funkció a beépített incrementális frissítés. Az UPDATES: enabled környezeti változó hatására a konténer percenként letölti a minute diff fájlokat a planet.openstreetmap.org-ról. Ez azt jelenti, hogy a térképünk gyakorlatilag valós időben frissül – ha valaki módosít egy utat az OSM-ben, az pár percen belül megjelenik a saját szerverünkön is. Természetesen ha nincs internet, a script egyszerűen csendben meghibásodik, és a konténer tovább szolgálja a már meglévő csempéket.

2. Photon – Címkeresés geokódolással

A Photon egy nyílt forráskódú geokódoló motor, ami az OpenStreetMap adatokra épül. A mi stackünkben a local/photon:1.1.0 image fut, ami egy Magyarországra szabott adatbázissal dolgozik. Ez nem a teljes világ – csak Magyarország, ami jelentősen csökkenti a keresési időt és a tárhely igényt.

A Photon adatbázis frissítése egy /root/photon-import.sh script segítségével történik, ami hetente egyszer fut (vasárnap 11:30-kor a cron-ban).

A script működése:

Az importált adatbázisok verziózott könyvtárakba kerülnek (/home/osm/photon/imports/20260603200523/), így mindig vissza lehet térni egy régebbi verzióhoz, ha valami elromlana. Egy szimbolikus link (photon_data -> imports/20260603200523/) mutat az aktuális verzióra.

3. GraphHopper – Útvonaltervezés (autó, bicikli, gyalogos)

A GraphHopper egy nagy teljesítményű, nyílt forráskódú útvonaltervező motor, ami az OpenStreetMap úthálózatára épül. A mi stackünkben a local/graphhopper:9.1 image fut, 4 GB RAM allokációval.

A GraphHopper három útvonal profilt támogat:

• car – autós közlekedés, figyelembe veszi az egyirányú utcákat, sebességkorlátozásokat, út típusokat
• bike – biciklis közlekedés, preferálja a kerékpárutakat, kerüli a főútvonalakat
• foot – gyalogos közlekedés, használja a járdákat, gyalogutakat, lépcsőket

A konfiguráció /home/osm/graphhopper/config.yml-ban található:

A Contraction Hierarchies (CH) egy előfeldolgozási technika, ami drámaian felgyorsítja az útvonal keresést. Az autó és bicikli profilokhoz CH-t használunk, ami az első induláskor 5-10 perc előfeldolgozást igényel, de utána a lekérések ezredmásodpercek alatt teljesülnek.

4. GraphHopper PT – Tömegközlekedési útvonaltervezés

Ez a stack talán legmenőbb komponense. A GraphHopper PT (Public Transport) egy speciális konfigurációja a GraphHopper-nak, ami nemcsak az OSM úthálózatot, hanem a menetrendi adatokat (GTFS) is felhasználja a tömegközlekedési útvonaltervezéshez.

GTFS adatforrások

Három GTFS adatforrást használunk, amelyek Magyarország teljes tömegközlekedését lefedik:

A MÁV regisztrációs kálvária

A MÁV GTFS elérése sajnos nem nyilvános – a mavcsoport.hu/gtfs oldalon kell regisztrálni, ahol egy rövid adatkezelési hozzájárulás után kapunk Basic Auth felhasználónevet és jelszót. A regisztráció egyszerű, de a mai napig nem értem, miért kell ez egy nyílt GTFS adatfolyamhoz – a MÁV indoklása szerint azért, hogy „tudják, hányan és milyen célra használják az adataikat”. Nos, a mi célunk egyértelmű: jobb tömegközlekedési információt adni a felhasználóknak.

A Volánbusz és a BKK szerencsére nyíltan, mindenféle regisztráció nélkül elérhető – köszönet érte!

A GTFS szinkronizáló script

A /root/gtfs-sync.sh script naponta (hajnali 3:30-kor) letölti mindhárom GTFS fájlt, majd újraindítja a graphhopper-pt konténert, hogy az új menetrend alapján újraépítse a gráfot. Ez a folyamat 2-5 percet vesz igénybe – ezalatt a tömegközlekedési útvonaltervezés nem elérhető.

Érdekesség, hogy a GraphHopper PT konfigurációja egyszerre három GTFS fájlt is be tud tölteni – a gtfs.file paraméterben vesszővel felsorolva:

Ez azért fontos, mert a tömegközlekedési útvonaltervezésnél nem elég a menetrend – tudni kell, hogyan jutok el a buszmegállóhoz gyalog, amihez pontosan az OSM adataira van szükség.

5. A Webes Felület – MapLibre GL UI

A felhasználói felület MapLibre GL JS-re épül, ami a Mapbox GL JS nyílt forráskódú továbbfejlesztett változata. A map-ui konténer egy Nginx Alpine image, ami a statikus fájlokat szolgálja ki és proxy-zik a háttérszolgáltatások felé.

Ami különösen fontos: minden JavaScript és CSS fájl lokálisan van tárolva a /root/osm-ui/vendor/ könyvtárban. Nincs CDN függőség, nincs Google Fonts, nincs unpkg – ha elmegy az internet, a felület továbbra is teljesen működőképes marad.

A UI funkciói

• Térkép nézet – raszteres csempék MapLibre GL-lel, teljes képernyős interakció
• Keresés – autocomplete címkeresés a Photon segítségével, kattintásra odarepülés
• Útvonaltervezés – A→B útvonal négy módban: autó, bicikli, gyalogos, tömegközlekedés
• Kanyarról-kanyarra navigáció – összecsukható lista az útvonal panelen, bármelyik kanyarra kattintva odarepül a térkép
• Több alternatíva – tömegközlekedésnél több útvonal közül választhatunk indulási/idő szerint
• Járat jelvények – színkódolt jelvények a különböző járatokhoz (busz=kék, villamos=sárga, metró=piros, vasút=lila, stb.)
• Rétegek váltása – OSM (alap) és Műhold (ESRI World Imagery) között
• Offline érzékelés – a műhold réteg automatikusan letiltódik, ha nincs internet

Offline audit – Mi működik internet nélkül?

Ez a projekt egyik legfontosabb szempontja. Lássuk, mi a helyzet:

Teljesen offline (nincs szükség internetre)

• ✅ Térképi csempék – a PostgreSQL adatbázisból renderelve (Magyarország OSM PBF)
• ✅ Címkeresés – Photon a lokális Magyarország dump-ot használja
• ✅ Útvonaltervezés – GraphHopper ugyanazt a lokális PBF-et olvassa
• ✅ Tömegközlekedés – GraphHopper PT a lokálisan szinkronizált GTFS menetrendekkel
• ✅ MapLibre GL JS/CSS – /root/osm-ui/vendor/ könyvtárból (nincs CDN)
• ✅ Összes HTML/JS/CSS – nincs külső font, nincs Google Fonts, nincs külső API hívás
• ✅ Nginx proxy – minden upstream cél localhost vagy konténer név

Internetet igényel

• ❌ Műhold réteg (ESRI World Imagery) – opcionális, kikapcsolható
• ❌ OSM tile frissítések – minute diff letöltések (ha elérhető a net, különben csendben hibázik)
• ❌ Photon adatfrissítés – heti dump letöltés graphhopper.com-ról
• ❌ GTFS adatok – napi menetrend letöltés

Üzemeltetés – Cron feladatok

A rendszer üzemeltetése nagyrészt automatizált. Három cron job gondoskodik a frissítésekről:

Az OSM konténer beépített frissítése percenként fut a konténeren belül, nem cron-on keresztül.

Ismert korlátok

• Hiányzó házszámok a Photon keresésben – a Magyarország Photon dump nem tartalmazza az OSM házszintű címkéit. Ez nem hiba, hanem adatkorlát.
• Street View nem elérhető – nincs gyakorlati, önállóan üzemeltethető alternatíva (a Mapillary internetet igényel, a Google Street View pedig API kulcsot és internetet).
• GraphHopper frissítése kézi – amikor az OSM PBF frissül, a GraphHopper graph cache-t manuálisan kell törölni (vagy újraindítani a konténert).
• Transit gráf újraépítés – GTFS frissítéskor 2-5 percig nem elérhető a tömegközlekedési útvonaltervezés.
• GTFS adatok időszerűsége – a menetrendek olyan frissek, amilyen friss az utolsó szinkronizáció (maximum 24 óra késés).

Zárszó

Ez a projekt számomra a szoftveres szabadság egyik legszebb példája. Egy olcsó, kis fogyasztású Raspberry Pi-n fut egy teljes értékű térkép szolgáltatás, ami semmilyen külső függőséggel nem rendelkezik. A nyílt forráskódú OpenStreetMap közösség munkája, a Photon, a GraphHopper és a MapLibre projectek lehetővé teszik, hogy bárki a saját kezébe vegye a térképezést.

A forráskód és a konfigurációk természetesen elérhetők a saját infrastruktúrámon. Ha bárki szeretne egy hasonló rendszert építeni, a N.O.M.A.D. projekt remek kiindulási alap, és az itt leírt konfigurációk is szabadon felhasználhatók.

Következő lépésként szeretném kiterjeszteni a szolgáltatást Szlovákiára, Romániára, Ausztriára, Szlovéniára és Horvátországra is – a Kárpát-medence teljes lefedésére. Továbbá tervben van egy útnyitás (road closure) támogatás is, ahol a felhasználók jelezhetik az aktuális lezárásokat, tereléseket, ami aztán az összes felhasználó számára megjelenne.

Ha kérdésetek van, vagy kipróbáltátok a megoldást és elakadtatok, nyugodtan szóljatok!

May 2026 newsletter is here!

https://maplibre.org/news/2026-06-03-maplibre-newsletter-may-2026/

#maplibre #openstreetmap #opensource #foss4g