Przetwarzanie OpenStreetMap na systemie wbudowanym #1 - Format .osm

[kronikary]

W prezentowanym przeze mnie artykule, zostaną przedstawione kroki mające na celu wyświetlenie na systemie wbudowanym map tworzonych przez społeczność OpenStreetMap. Temat wydaje się prosty, bo jak trudny może być odczyt paru punktów, a następnie połączenie ich ciągłą linią, lecz niestety nie udało mi się znaleźć przykładowych rozwiązań, ani nawet filmików na youtube. Myślę, że przetrę trochę szlak i wyjaśnię problematykę tematu oraz proces, jaki mi towarzyszył podczas tworzenia algorytmów. W głównej mierze skupię się na części programistycznej tzn. przedstawię i opiszę najważniejsze linijki kodu. Artykuł jest podzielony na cztery części, lecz dopiero w drugiej zaczynam opisywać problematykę przetwarzania map.

Ten artykuł bierze udział w naszym konkursie! 🔥
Na zwycięzców czekają karty podarunkowe Allegro, m.in.: 2000 zł, 1000 zł i 500 zł.

Potrafisz napisać podobny poradnik? Opublikuj go na forum i zgłoś się do konkursu!
Czekamy na ciekawe teksty związane z elektroniką i programowaniem. Sprawdź szczegóły »

Do testów wykorzystałem

• Płytkę rozwojową STM32 - NUCLEO-L496ZG-P 
• Wyświetlacz LCD SPI FS024QV069-RT 
• Kartę SD 2GB 
• Dodatkowo: moduł GPS U-blox NEO-6M 
• STM32CubeIDE wraz z CubeMX 
• PyCharm Community Edition 2020.3

Czym jest OpenStreetMap?

OpenStreetMap jest projektem tworzonym przez społeczność internetową, której celem jest stworzenie bardzo szczegółowej (i darmowej) mapy kuli ziemskiej. Największą zaletą, a jednocześnie wadą jest to, że każdy zarejestrowany użytkownik może edytować oraz nakładać poprawki na mapę. Zaleta, bo nie ma drugiego darmowego oraz tak rozbudowanego i szczegółowego zbioru danych geograficznych. Niestety nowi użytkownicy często nie znają zasad podczas edytowania danych i zdarzają się błędy w formacie.

Czym jest .osm?

W formacie .osm zapisane są wektorowe informacje (jako dane geograficzne) o wszystkich obiektach na danym obszarze. Dane te są przedstawiane w specyfikacji XML, dzięki czemu łatwo jest zrozumieć jak kodowane są obszary, ulice, budynki, drzewa itp.

Struktura danych OpenStreetMap

OpenStreetMap utworzył pewien standard danych, który jest wykorzystywany do opisu obiektów. Składa się on z następujących elementów:

• Nodes – opisuje dowolny punkt na mapie. Mogą to być współrzędne geograficzne jakiegoś lokalu, ławki, miasta, osiedla itp. Każdy punkt musi zawierać koordynaty oraz numer ID. Przykład reprezentacji punktu w .osm

<node id="277320011" visible="true" version="6" changeset="44098395" timestamp="2016-12-01T22:22:49Z" user="pawka007" uid="1123676" lat="53.1163643" lon="23.1422956"/>

• Ways – jest to zbiór punktów wyżej opisanych. Są one wykorzystywane do opisania dróg, rzek, budynków, obszarów itp. Taki element również posiada swój własny numer ID.
• Relations – jest to zbiór danych typu „ways” wykorzystywany do opisania bardziej zaawansowanych obiektów na przykład takich, które składają się z dwóch zbiorów punktów.

W powyższym przykładzie zbiór punktów/koordynatów A-D będzie jednym zbiorem danych typu „ways”, natomiast E-H zupełnie oddzielnym.  W taki sposób można przedstawić np. obiekt który posiada patio. Przykład wykorzystania relacji w .osm:

<relation id="8655507" visible="true" version="20" changeset="90120818" timestamp="2020-08-29T14:02:10Z" user="Michoo" uid="594456">
  <member type="way" ref="221209008" role=""/>
  <member type="way" ref="221209016" role=""/>
</relation>

• Tags - każdy element taki jak way, node, relation może posiadać własny tag, który opisuje właśnie ten element. Każdy tag składa się z ‘key’ oraz ‘value’.  Z reguły ‘key’ określa typ obiektu, natomiast ‘value’ jego rodzaj. Na przykład droga może zostać otagowana jako:

<tag k="highway" v="service"/>

 

Struktura danych w pliku .osm

Weźmy teraz na przykład opis jakiejś drogi serwisowej.

<node id="3940502643" visible="true" version="4" changeset="62793294" timestamp="2018-09-21T11:15:48Z" user="Michoo" uid="594456" lat="53.1042847" lon="23.1626099"/>
 <node id="3940502642" visible="true" version="2" changeset="25569250" timestamp="2014-09-20T23:06:39Z" user="iso-lator" uid="1759163" lat="53.1035107" lon="23.1600469"/>
 <node id="3940502636" visible="true" version="6" changeset="26286351" timestamp="2014-10-23T19:47:35Z" user="pawka007" uid="1123676" lat="53.1054507" lon="23.1530499"/>

<way id="390899781" visible="true" version="1" changeset="36513896" timestamp="2016-01-11T21:37:47Z" user="acza" uid="1407051">
  <nd ref="3940502643"/>
  <nd ref="3940502642"/>
  <nd ref="3940502636"/>
  <tag k="highway" v="service"/>
  <tag k="surface" v="paving_stones"/>
 </way>

Będę specjalnie unikać nazewnictwa ze specyfikacji XML, aby nie wprowadzić jeszcze większego zamieszania. Opis obiektu zaczyna się od ‘way’, który posiada swój własny nagłówek zawierający numer ID oraz informacje o użytkowniku, który dodał/edytował ten obiekt. Następnie widzimy trzy numery ID ‘nd ref’. Są to numery ID punktów ‘nodes’, natomiast wszystkie ‘nodes’ z informacją o koordynatach są zadeklarowane przed ‘ways’. Ostatnie w kolejności pojawiają się tagi. Wpierw otrzymujemy informacje, że jest to droga serwisowa, a następnie dane dotyczące powierzchni z jakiej ta droga jest wykonana. Tagów może być mniej lub więcej, lecz sytuacja gdy nie ma ani jednego taga uniemożliwia poprawne zdekodowanie informacji o obiekcie. Odczytując wszystkie informacje (a przynajmniej koordynaty oraz rodzaj i typ obiektu) wiemy jak wygląda dany obiekt.  W analizowanym przypadku widzimy, że jest to droga, więc będziemy rysować wielolinie, a nie poligon. Dodatkowo zależnie od ‘value’ możemy tej linii nadać różny kolor lub szerokość, aby rozróżnić np. autostradę od drogi leśnej.  Warto dodać, że przestawiony przykład jest jedynie poglądowy, ponieważ w znacznej większości przypadków droga składa się z kilkudziesięciu lub nawet kilkuset punktów.
 

Ponownie zachęcam do otworzenia zasobów map OSM, aby zapoznać się z rodzajami obiektów. Dodatkowo po wejściu na stronę OSM możemy wyeksportować interesujący nas wycinek mapy, a następnie odtworzyć go w jakimś XML viewer. Polecam wpierw odtworzyć pojedynczy obiekt i zobaczyć jak jest opisany. W ten sposób można w bardzo łatwy sposób oswoić się z wyglądem formatu .osm. Więcej informacji na temat OpenStreetMaps można znaleźć w różnych przewodnikach dostępnych w sieci.

 

Format .osm, a może coś innego?

Wraz z rozwojem i coraz większym zainteresowaniem projektem zaczęły powstawać inne formaty. Pytanie - po co? Niestety wraz z powiększaniem się ilości punktów na mapie (aktualnie około 7 miliardów) rozmiar plików zaczął trochę doskwierać. Na dzień kiedy publikuję ten artykuł cała planeta zapisana w formacie .osm zajmuje powyżej 1TB. Obszar polski to około 25GB. Przechowywanie, a następnie dekodowanie takich plików jest niemałym wyzwaniem nawet dla najbardziej wydajnych systemów. Między innymi z tego powodu wprowadzono kilka różnych formatów, a według mnie największy potencjał ma .pbf. Ta sama mapa planety zapisana w tym formacie zajmuje już „tylko” ~50GB. Zaletą .osm jest fakt, że wykorzystuje on XML, dzięki czemu łatwo jest poznać strukturę danych OpenStreetMap, lecz z tego samego powodu rozmiar danych jest kolokwialnie mówiąc ogromny. Z formatem .pbf jest inaczej. Każdy z elementów struktury danych OSM jest kodowany do wcześniej zdefiniowanego formatu binarnego, przez co rozmiar pliku jest zdecydowanie mniejszy, lecz bez specjalnego wrappera (lub poznania kodera) nie jesteśmy w stanie odczytać informacji.

Istnieje jeszcze jeden format, który został specjalnie utworzony dla systemów wbudowanych, a mianowicie .img wykonany przez Garmina. Zapewne pojawi się pytanie w jakim celu zagłębiłem się w format .osm skoro teoretycznie istnieje gotowe rozwiązanie. Przede wszystkim potrzebuję wyświetlać proste informacje o drogach
i budynkach, a format Garmina jest tak zaprojektowany, aby można go było wykorzystywać we wszystkich urządzeniach GPS, niezależnie od wymaganego poziomu zaawansowania. Co ciekawe za niektóre mapy trzeba zapłacić – nie wystarczy posiadać urządzenia tego producenta. Kolejna kwestia to fakt, że niekiedy łatwiej jest coś stworzyć od podstaw, niż dokonywać inżynierii wstecznej.

Podsumowanie

Tym krótkim wstępem mam nadzieję, że naświetliłem odrobinę, czym jest projekt OpenStreetMaps oraz jak reprezentowane są obiekty w stworzonej przez nich strukturze danych. Zachęcam do zapoznania się z różnymi reprezentacjami obiektów w formacie .osm, jako że wiedza ta przyda się w następnych odsłonach artykułu. Mapy OpenStreetMaps na dobre zagościły w projektach DIY, a to między innymi dlatego, że są łatwo dostępne w sieci. Dodatkowo są one aktualizowane prawie codziennie.

W kolejnej części artykułu opiszę problematykę i algorytm do przetwarzania map oraz odpowiem na pytanie jak przetworzyć na mikroprocesorze mapę o rozmiarze 25GB.

 

Spis treści:

1. Przetwarzanie OpenStreetMap na systemie wbudowanym #1 - Format .osm
2. Przetwarzanie OpenStreetMap na systemie wbudowanym #2 - Parsowanie formatu .osm
3. Przetwarzanie OpenStreetMap na systemie wbudowanym #3 - Kodowanie formatu .ltd
4. Przetwarzanie OpenStreetMap na systemie wbudowanym #4 - Dekodowanie formatu .ltd

[Treker (Damian Szymański)]

@kronikary witam na forum! Pierwsza część artykułu została właśnie zaakceptowana i jest już widoczna publicznie. Kolejne części będą publikowane w ciągu kilku najbliższych dni (jest całkiem spora kolejka prac konkursowych - staram się przeplatać tematy) 😉