Mam prośbę o pomoc - czy jest jakiś w miarę prosty sposób (skrypt, wiersz poleceń albo jakieś narzędzie), żeby wyekstrahować dane z całego świata, ale tylko elementy widoczne na domyślnym stylu na poziomach 1-6 (ew. do 7)? Przymierzam się do porządków na tych poziomach, więc musi być cały świat, ale nie chcę sobie zarżnąć komputera zbędnymi danymi.
Próbowałem na razie czegoś takiego:
~/Documents/OSM/tilemill/osmconvert planet.osm.pbf -o=world.o5m
osmfilter world.o5m --keep=" boundary=national_park admin_level=2 admin_level=3 admin_level=4 highway=motorway highway=primary highway=secondary highway=trunk natural=nature_reserve natural=glacier natural=water place=city place=island place=town railway=rail waterway=river waterway=riverbank landuse=reservoir landuse=basin" --drop-version > world.osm
na ładowaniu do bazy zeżarło 4GB ramu, zeżarło 60GB dysku na swap file, zeżarło jeszcze kilka GB na plik tymczasowy, po czym po ponad 20 godzinach i tak wywaliło się z
Processing: Node(457495k 96.9k/s) Way(15947k 0.28k/s) Relation(201330 26.27/s)
Unable to allocate memory: 1895201
Segmentation fault (core dumped)
pomimo tego iż jeszcze wolne miejsce było
Sadzac po liczbie wezlow, drog i relacji, w trybie “slim” (-s) powinno to byc calkiem wykonalne na srednim komputerze. Teoretycznie ten tryb jest wolniejszy ale wiecej niz dwa dni nie powinno zajac nawet na tradycyjnym dysku, na SSD mysle ze nawet mniej niz 20h.
A czy ktoś (z was na przykład) mógłby spróbować takie dane przygotować i wystawić? Oczywiście sam też mogę to zrobić, ale sprzęt mam słaby, a przede wszystkim chciałbym się skupić na samym stylu i ogólnym łączeniu różnych kropek w OSM, bo naprawdę jest co robić.
Potrzebuję to zrobić w ramach nowego stylu dla dróg - więc w ciągu najbliższych tygodni w jakiś sposób to zrobię. Jeszcze nie wiem jak ale…
@balrog-kun - to już było w trybie slim
osm2pgsql -c -S /home/mateusz/Documents/OSM/tilemill/osm-carto/openstreetmap-carto.style --slim --flat-nodes /media/mateusz/Backup/flat-nodes.bin --drop --number-processes 2 -C 2650 --multi-geometry world.osm
A propos - kolejny wpis Mateusza na temat proponowanego nowego stylu dróg:
http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35351
Jedyny parametr ktorego nie uzywalem to --multi-geometry, nie wiem skad taka roznica. Na openstreetmap.pl import Europy (ok. 3x wiecej wezlow, 12x wiecej drog i relacji o ile pamietam) nie przekroczylby 10GB ram+swap (nie liczac -C). Aktualne i kompletne dane sa tam tylko dla Europy a globalne sa nieaktualne, przefiltrowane pod wzgledem z<10 i maja uproszczone geometrie. Nie mam zasobow na wiecej danych ale jesli te Wam wystarcza to mozecie tam wykonywac eksperymenty, obawiam sie ze wymagaloby to dostosowania zapytan w stylu.
A może w temacie surface=unpaved i innych nawierzchni nieasfaltowych dałoby się zrobić takie renderowanie?
(przykład zrobiony na szybko w Gimpie)
Chyba taka propozycja padła (zamiast zabaw z kolorami brzegów), ale szczegółów już nie pamiętam - najlepiej zajrzeć do wątku o poprawie stylu dróg na GiHubie.
O tutaj. https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-116224523
Tak jak myślałem, wygląda na to że nie jest to taka prosta sprawa w Mapniku.
Krótkie piłki, bo trzeba zdecydować, a jest mało głosów:
- Jak ma wyglądać ikonka dla kliniki weterynaryjnej, czy wystarczy łapka jak dla sklepu zoologicznego, tylko w kolorze medycznym?
https://github.com/gravitystorm/openstreetmap-carto/issues/1649
- Czy zamienić banków i bankomatów na brązowy (jak większość obiektów amenity=*), czy może jednak na fiolet sklepowy?
https://github.com/gravitystorm/openstreetmap-carto/issues/1642
- Czy nową ikonkę skrzynki pocztowej dać z wlotem a dole (ideowo), czy na górze (fizycznie)?
https://github.com/gravitystorm/openstreetmap-carto/pull/1558#issuecomment-116053184
Może coś w stylu łapka + np. stetoskop?
Nie wspomniałem o najważniejszym ograniczeniu: mamy do dyspozycji tylko 14x14 pikseli i jeden (z góry określony) kolor.
Tak, popieram. Myślę też, że ta łapka mogłaby być trochę mniejsza, bo z racji dużego współczynnika wypełnienia sprawia wrażenie dominującej.
A próbowałeś tę kopertę “wsunąć” trochę w szczelinę? Myślę, że może wtedy byłaby bardziej wymowna…
Ale z tych dwóch propozycji, bardziej mi się widzi ta z wlotem na górze.
Kolejny, tym razem bardzo rozbudowany, raport Mateusza na temat zmian w stylu wyświetlania dróg:
http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35389
Następny ma być jutro, tymczasem można wpisywać swoje uwagi w komentarzach - Mateusz pyta o kilka rzeczy.
Od wczoraj na mocnej maszynie zapuszczam dokładnie z twoimi ustawieniami z ciekawości i przeszedł przez ten moment (parse time: 69044s). Ale htop wykazywał, że z 4 GB wykorzystywał stale około 3-3,5 GB, natomiast w którymś momencie zużył dodatkowo ok. 2 GB swapu.
Z tego co ustalałem - robiłem to z starym osm2pgsql który mógł mieć pewne poważne bugi (usunięte w nowszych wersjach) które objawiały się nadmiernym zużyciem pamięci.
Uff, wreszcie udało mi się z grubsza dojść do porządku z inteligentnym rozmieszczaniem etykietek tekstowych!
Zwrócił mi na to uwagę ostatnio Rekrutacja pokazując OpenTopoMap, gdzie nazwy nie są walone zawsze w centrum, tylko nieco przesuwane tam, gdzie jest mniejszy tłok. Niestety ich styl kodu jest mało czytelny, ale zauważyłem, że przecież we francuskim stylu także nazwy są w miarę możliwości odsuwane na boki - a to jest praktycznie fork osm-carto, więc znacznie łatwiej znajdować podobieństwa i różnice.
Podejrzana opcja to:
text-label-position-tolerance
ale dokumentacja Mapnika jest strasznie sucha i nawet Mateusz zwątpił jak o niej przeczytał, bo napisali tylko, że dotyczy linii. Ale skoro już miałem naoczne dowody, że to się da zrobić, to pozostało jednak sprawdzić, bo przecież taki obszar z nazwą de facto wyznacza zamknięta linia (czyli jego granica), więc być może niepotrzebnie się obawialiśmy.
Mnie najbardziej zależy na poprawkach na niskich skalach, bo np. nazwy województw zakrywają dość dokładnie nazwy miast wojewódzkich - w tym Warszawy, która jest widoczna dopiero od poziomu przybliżenia 8. Ale ponieważ dane całego świata, nawet odfiltrowane z drobiazgów, nadal wczytują się długimi godzinami, zastanowiłem się, czy może jeszcze jakieś napisy z nazwami obszarów występują na poziomie mikro. No i przypomniałem sobie, że przecież choćby nazwy budynków, które czasem są zasłaniane przez POI leżące w ich obrysie albo nazwy sąsiednich budynków!
A to już można szybko przetestować - i rzeczywiście, udało mi się znaleźć przykład, że to naprawdę działa:
https://github.com/gravitystorm/openstreetmap-carto/issues/1661
Oczywiście trzeba będzie znaleźć więcej takich przykładów, ale przynajmniej już wiadomo, że da się naprawić wyświetlanie miast na niskich i średnich poziomach przybliżenia, które moim zdaniem jest w tej chwili beznadziejne.
[EDIT:] No niestety po zastanowieniu nie do końca mam pewność, że to akurat ta opcja działa w tym wypadku, ale za to znalazłem kolejną rzecz lepiej zrobioną we francuskim stylu niż w osm-carto, więc spróbuję to wykminić i wdrożyć u nas.
Osm2pgsql took 96694s overall
…czyli w sumie prawie 27 godzin. Właśnie się wczytuje do TileMilla, ale trwa to też długo - bardzo by pomógł dysk SSD, bo to głównie dysk jest wąskim gardłem - jeszcze pamięć może, ale procesor to najmniej.
Mniej wiecej zgodnie z tym ile sie spodziewalem. Polecam uproszczenie danych jesli maja sluzyc renderowaniu na niskich zoomach, np. przez ST_Simplify(), po tym na prawde powinny sie dac wyeksportowac i zaimportowac na o wiele slabszej maszynie.