osm2pgsql — Online w chmurze

PROGRAM:

IMIĘ

osm2pgsql - konwerter danych Openstreetmap na PostgreSQL.

STRESZCZENIE

osm2pgsql [Opcje] planeta.osm
osm2pgsql [Opcje] planeta.osm.{gz,bz2,pbf}
osm2pgsql [Opcje] plik1.osm plik2.osm plik3.osm

OPIS

Ta strona podręcznika opisuje pokrótce osm2pgsql dowództwo.

osm2pgsql importuje dane z plików OSM do bazy danych PostgreSQL odpowiedniej do użytku przez
Renderer Mapnik lub geokoder Nominatim.
Migawki planet OSM można pobrać z http://planet.openstreetmap.org/. Częściowy
dostępne są pliki planet ("wyciągi") dla różnych krajów, patrz
http://wiki.openstreetmap.org/wiki/Planet.osm.

Ekstrakty w formacie PBF (ProtoBufBinary) są również dostępne od
http://download.geofabrik.de/osm/.

Podczas pracy w trybie „slim” (i na bazie danych utworzonej w trybie „slim”!), osm2pgsql mogą
przetwarzają również pliki zmian OSM (pliki osc), w ten sposób zwiększając istniejącą bazę danych do
data.

OPCJE

Te programy działają zgodnie ze zwykłą składnią wiersza poleceń GNU, z długimi opcjami zaczynającymi się od
dwie myślniki (`-'). Podsumowanie opcji znajduje się poniżej.

-a|--dołącz
Dodaj plik OSM do bazy danych bez usuwania istniejących danych.

-b|--bbox
Zastosuj filtr obwiedni do importowanych danych. Należy określić jako:
minlon, minlat, maxlon, maxlat np. --bbox -0.5,51.25,0.5,51.75

-c|--utwórz
Usuń istniejące dane z bazy danych. To jest domyślne, jeśli --dodać nie jest
określony.

-d|--nazwa bazy danych
Nazwa bazy danych PostgreSQL do połączenia (domyślnie: gis).

-i|--tabela-indeks nazwaobszaru-tabeli
Przechowuj wszystkie indeksy w oddzielnej przestrzeni tabel PostgreSQL nazwanej przez ten parametr.
Pozwala to np. na przechowywanie indeksów na szybszej pamięci masowej, takiej jak dyski SSD.

--tablespace-main-data nazwaobszaru-tabeli
Przechowuj tabele danych (nie slim) w podanej przestrzeni tabel.

--tabela-główny-indeks nazwaobszaru-tabeli
Przechowuj indeksy głównych tabel (nie slim) w danej przestrzeni tabel.

--tablespace-slim-data nazwa przestrzeni tabel
Przechowuj tabele trybu szczupłego w określonej przestrzeni tabel.

--tablespace-slim-index nazwa przestrzeni tabel
Przechowuj indeksy tabel trybu szczupłego w danym obszarze tabel.

-l|--długie
Przechowuj dane w stopniach szerokości i długości geograficznej.

-m|--najemnik
Przechowuj dane w odpowiednim sferycznym Mercatorze (domyślnie).

-E|--numer projektu
Użyj projekcji EPSG:liczba

-u|--utf8-odkażanie
Napraw uszkodzone dane wejściowe UTF-8 (obecne w zrzutach planet przed sierpniem 2007 r.). Dodaje
około 10% kosztów ogólnych.

-p|--prefiks prefix_string
Prefiks nazw tabel (domyślnie: planet_osm).

-r|--format czytnika danych wejściowych
Wybierz czytnik formatu wejściowego. Dostępne opcje to libxml2 (domyślnie) dla OSM XML
formatować pliki, o5m dla pliku w formacie o5m i pbf , , , , , , , , , , , ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, ,, , dla formatu binarnego OSM PBF (może nie
być dostępne na wszystkich platformach).

-s|--szczupła
Przechowuj dane tymczasowe w bazie danych. Bez tego trybu wszystkie dane tymczasowe są
przechowywane w pamięci RAM i jeśli nie masz wystarczającej ilości, import nie będzie działał pomyślnie.
W trybie slim powinieneś być w stanie zaimportować dane nawet w systemie z ograniczonym
RAM, chociaż jeśli nie masz wystarczającej ilości pamięci RAM, aby buforować przynajmniej wszystkie węzły,
czas importu danych prawdopodobnie znacznie się wydłuży.

--upuszczać
Po zakończeniu importu usuń tabele trybu szczupłego z bazy danych. To może
znacznie zmniejsza rozmiar bazy danych, ponieważ tabele w trybie szczupłym zwykle są
ten sam rozmiar, jeśli nie nieco większy niż główne stoły. Nie oznacza to jednak
zmniejszyć maksymalny wzrost wykorzystania dysku podczas importu. Może ponadto wzrosnąć
szybkość importu, ponieważ nie trzeba tworzyć indeksów dla tabel w trybie szczupłym, które
(w zależności od sprzętu) może prawie o połowę skrócić czas importu. Jednak stoły w trybie szczupłym mają
być wytrwałym, jeśli chcesz mieć możliwość aktualizacji bazy danych, ponieważ te tabele
są potrzebne do przetwarzania różnicowego.

-S|--styl /ścieżka/do/styl
Lokalizacja pliku stylu osm2pgsql. Określa, które tagi z danych otrzymują
importowane do kolumn bazy danych i które tagi są usuwane. Domyślnie do
/usr/share/osm2pgsql/default.style.

-C|--liczba pamięci podręcznej
Tylko dla trybu szczupłego: użyj do num. wielu MB pamięci RAM do buforowania węzłów. Dający
osm2pgsql wystarczająca ilość pamięci podręcznej do przechowywania wszystkich importowanych węzłów zazwyczaj znacznie się zwiększa
szybkość importu. Każdy węzeł w pamięci podręcznej wymaga 8 bajtów pamięci podręcznej plus około 10%
- 30% kosztów ogólnych. W przypadku bieżącego importu całej planety OSM z około 3 miliardami węzłów, a
dobra wartość to 27000, jeśli masz wystarczającą ilość pamięci RAM. Jeśli nie masz wystarczającej ilości pamięci RAM, to
prawdopodobnie korzystne jest, aby osm2pgsql był zbliżony do pełnej dostępnej ilości pamięci RAM.
Domyślnie 800.

--strategia strategii pamięci podręcznej
Istnieje wiele różnych trybów, w których osm2pgsql może organizować swój węzeł
pamięć podręczna w pamięci RAM. Są one zoptymalizowane pod kątem różnych założeń danych i
dostępne zasoby sprzętowe. Obecnie dostępne strategie są gęsta, porcje,
rzadki oraz zoptymalizowane. gęsta zakłada, że ​​numery id węzła są gęsto upakowane,
tzn. brakuje/usunięto tylko kilku identyfikatorów z zakresu. W przypadku ekstraktów z planet jest to
zwykle tak nie jest, co sprawia, że ​​pamięć podręczna jest bardzo nieefektywna i marnuje pamięć RAM. rzadki
zakłada, że ​​identyfikatory węzłów w danych nie są gęsto upakowane, co znacznie zwiększa buforowanie
wydajność w tych przypadkach. Jeśli identyfikatory węzłów są gęsto upakowane, tak jak w całości
planeta, ta strategia wiąże się z wyższymi kosztami indeksowania pamięci podręcznej. zoptymalizowane zastosowania
strategie gęste i rzadkie dla różnych zakresów przestrzeni ID. Na bloku
na podstawie bloku próbuje określić, czy bardziej efektywne jest przechowywanie bloku
Identyfikatory w trybie rzadkim lub gęstym. Jest to ustawienie domyślne i powinno być zwykle używane.

-U|--nazwa użytkownika
Nazwa użytkownika Postgresql.

-W|--hasło
Wymuś monit o hasło.

-H|--host nazwa hosta
Nazwa hosta serwera bazy danych lub lokalizacja gniazda.

-P|--numer portu
Port serwera bazy danych.

-e|--kafelki wygasania [min_zoom-]max-zoom
Utwórz listę ważności kafelków.

-o|--expire-output /ścieżka/do/expire.list
Nazwa pliku wyjściowego dla wygasłej listy płytek.

-o|--wyjście
Określa wyjściowy schemat zaplecza lub schemat bazy danych do użycia. Obecnie osm2pgsql
wspiera Pgsql, słownik nazw geograficznych oraz zero. Pgsql jest domyślnym zapleczem wyjściowym / schematem
i jest zoptymalizowany do renderowania za pomocą Mapnika. słownik nazw geograficznych czy schemat bazy danych jest zoptymalizowany dla
geokodowania i jest używany przez Nominatim. zero nie zapisuje żadnych danych wyjściowych i jest tylko
przydatne do testowania.

-x|--dodatkowe-atrybuty
Uwzględnij atrybuty dla każdego obiektu w bazie danych. Obejmuje to nazwę użytkownika,
identyfikator użytkownika, znacznik czasu i wersja. Uwaga: ta opcja wymaga również dodatkowych wpisów
w twoim pliku stylu.

-k|--hsklep
Dodaj tagi bez kolumny do dodatkowej kolumny hstore (klucz/wartość) do PostgreSQL
stoły.

-j|--hstore-wszystkie
Dodaj wszystkie tagi do dodatkowej kolumny hstore (klucz/wartość) w tabelach PostgreSQL.

-z|--hstore-kolumna nazwa_klucza
Dodaj dodatkową kolumnę hstore (klucz/wartość) zawierającą wszystkie tagi, które zaczynają się od
określony ciąg, np. --hstore-column "name:" wygeneruje dodatkową kolumnę hstore
który zawiera wszystkie tagi name:xx

--hstore-tylko-dopasowanie
Przechowuj tylko obiekty, które mają wartość w jednej z kolumn (normalne działanie z
--hstore ma zachować wszystkie obiekty).

--hstore-dodaj-indeks
Utwórz indeksy dla kolumn hstore podczas importu.

-G|--topienie-geometria
Zwykle osm2pgsql dzieli wieloczęściowe geometrie na oddzielne wiersze bazy danych na
część. Pojedynczy identyfikator OSM może więc mieć kilka wierszy. Dzięki tej opcji
Zamiast tego PostgreSQL generuje funkcje wielogeometryczne w tabelach PostgreSQL.

-K|--utrzymaj-linie brzegowe
Zachowaj dane linii brzegowej, zamiast je filtrować. Domyślnie natural = linia brzegowa
oznakowane dane zostaną odrzucone w oparciu o założenie, że po przetworzeniu linii brzegowej
Zostaną użyte pliki kształtu szachownicy.

--wyklucz-nieprawidłowy-wielokąt
Dane OpenStreetMap są definiowane w kategoriach węzłów, sposobów i relacji, a nie w
warunki rzeczywistych cech geometrycznych. Dlatego Osm2pgsql próbuje zbudować postgis
geometrie z tej reprezentacji danych. Jednak nie wszystkie sposoby i relacje
odpowiadają poprawnym geometriom postgisowym (np. samo przecinające się wielokąty). Za pomocą
domyślny osm2pgsql próbuje automatycznie naprawić te geometrie za pomocą ST_Bufor(0)
wokół nieprawidłowych wielokątów. Dzięki tej opcji nieprawidłowe wielokąty są zamiast tego po prostu
usunięte z bazy danych.

--wylogowany
Użyj niezalogowanych tabel postgresql do przechowywania danych. Wymaga to PostgreSQL 9.1 lub
nad. Dane zapisywane w niezalogowanych tabelach nie są zapisywane do funkcji zapisu z wyprzedzeniem w PostgreSQL
log, co czyni je znacznie szybszymi niż zwykłe tabele. Jednak są
nie jest bezpieczny w przypadku awarii: niezalogowana tabela jest automatycznie przycinana po awarii lub
nieczyste zamknięcie.

--liczba-procesów liczba
Określa liczbę równoległych procesów używanych do niektórych operacji. Jeśli dyski
są wystarczająco szybkie, np. jeśli masz dysk SSD, może to znacznie zwiększyć prędkość
etapy „przechodzenia przez oczekujące sposoby” i „przechodzenia przez oczekujące relacje” na a
serwer wielordzeniowy.

-I|--wyłącz-indeksowanie-równoległe
Domyślnie osm2pgsql inicjuje budowanie indeksu na wszystkich tabelach równolegle do
zwiększyć wydajność. Może to być wadą na wolnych dyskach lub jeśli ich nie masz
wystarczająca ilość pamięci RAM, aby PostgreSQL mógł wykonać do 7 równoległych procesów budowania indeksu
(np. ponieważ Maintenance_work_mem jest ustawiony na wysoki).

--flat-nodes /ścieżka/do/nodes.cache
Tryb płaskich węzłów to osobna metoda przechowywania informacji o węzłach w trybie szczupłym
dysk. Zamiast przechowywać te informacje w głównej bazie danych PostgreSQL, to
tryb tworzy własną oddzielną niestandardową bazę danych do przechowywania informacji. Jak to
niestandardowa baza danych ma wiedzę na poziomie aplikacji na temat danych do przechowywania i nie jest
ogólnego przeznaczenia, może znacznie wydajniej przechowywać dane. Przechowywanie węzła
informacje dla całej planety wymagają około 100 GB w PostgreSQL, te same dane
jest przechowywany tylko w ~16 GB w trybie płaskich węzłów. Może to również zwiększyć prędkość
stosowania plików diff. Ta opcja aktywuje tryb płaskich węzłów i określa
lokalizacja pliku bazy danych. Jest to pojedynczy, duży plik > 16 GB. Ten tryb jest tylko
zalecane do importu z całej planety, ponieważ nie działa dobrze z małymi ekstraktami.
Domyślnie jest wyłączone.

-h|--pomoc
Informacje pomocy.
Dodaj -v aby wyświetlić obsługiwane projekcje.

-v|--pełne
Gadatliwe wyjście.

UTRZYMANY PROJEKCJE

Latlong (-l) SRS: 4326 (brak)
Sferyczny Mercator (-m) SRS:900913 +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0
+lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +ponad
Zdefiniowane w EPSG (-E) SRS: +init=epsg:(jak podano w parametrze)

Korzystaj z osm2pgsql online za pomocą usług onworks.net