Wyświetlanie na domyślnej mapie

kocio · July 14, 2017, 11:03am

Wydaje mi się, że zamierzone, bo obszary kolejowe mogą się ciągnąć wraz z torami po pustkowiu, a tu chodziło o wzmocnienie obszarów gdzie są ludzie. Ale tak mnie się wydaje, a spytać najlepiej autora.

wmyrda · July 14, 2017, 11:36am

akurat na z8-z12 to obszarów idących przy torze czy dwóch to nie widać. landuse=railway widać jedynie przy stacjach czy większych torowiskach. Zgodzę się, że jednak jest to pewna niekonsekwencja i byłbym za tym by dostosować kolor l=railway do koloru l=industrial.

Nie korzystam z dockera by mieć plik env. Pod Linuksem korzystam z komendy za pomocą której na innym dysku fizycznym tworzę bazę

time osm2pgsql --create --slim \
        -C 16000 --number-processes 4 -k -m \
        --style /opt/osm/local_style/openstreetmap-carto.style --multi-geometry \
        -U psql -c -d gis \
        --flat-nodes /mnt/3tb/flatnodes \
        /mnt/3tb/poland-170703.osm.pbf

W systemie mam Intel(R) Core™ i3-4130 CPU @ 3.40GHz, 32GB RAM, jeden dysk ma 3TB, drugi 4TB i przy starym carto baza dla Polski zapełniała się jakieś 1,5h a przy przejściu na carto 4.0 gdzie szereg wartości wywalono i pozostawiono je jedynie w hstore byłem zaskoczony gdyż baza utworzyła się błyskawicznie

Maximum node in persistent node cache: 4942987263
node cache: stored: 109129098(100.00%), storage efficiency: 50.93% (dense blocks: 1680, sparse nodes: 100254248), hit rate: 100.26%

Osm2pgsql took 2177s overall

real    36m16,701s
user    25m20,913s
sys     1m33,181s

Natomiast tak się zastanawiam czy mając ustawione 16GB dla cache importu, do tego postgresa work_mem = 64MB maintenance_work_mem = 8192MB to czy te cache to nie za dużo poustawiane i się jakoś to wszystko nie kłuci z 8GB dla NFS, 1GB dla Squida i innymi podobnymi co by oznaczało, że w któryś momencie brakuje mu pamięci w systemie choć logi w monitorix tego nie wykazały

kocio · July 17, 2017, 1:52pm

Trudno mi powiedzieć w czym jest problem, bo sam z braku wypasionej maszyny nigdy nie importowałem kontynentu (tzn. importowałem, ale dopiero po okrojeniu do danych wyświetlanych obecnie na z<8). Mogę tylko polecić gdzie zapytać:

Sam z ciekawości zrobiłem testy porównawcze jak szybko się u mnie importuje w zależności od liczby rdzeni. Różnica jest, ale 4 zamiast 1 daje przyspieszenie rzędu 10-20%, czyli niezbyt wiele. Być może z dyskiem SSD byłoby lepiej.

[EDIT:] W twoim wypadku chyba dałeś za mało work_mem:

https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-WORK-MEM

64 MB to mniej niż u mnie (128 MB), a ja obie te wartości wziąłem z zaleceń dla dużej ilości pamięci.

kocio · July 18, 2017, 4:25pm

Padła propozycja, żeby zastąpić niebieskoszary jako kolor highway=pedestrian kostką znaną z warstwy area:highway:

https://github.com/gravitystorm/openstreetmap-carto/issues/2691#issuecomment-315960063

Przyznam, że spodobał mi się ten pomysł. Nie dość, że nie trzeba by było zgadywać odcieni kolorów, co już jest trudne, bo o dawna nie mamy już wolnych, to łatwiej mi się taka kostka kojarzy z obszarem dla pieszych. Jedyna trudność techniczna jest taka, że nie wiem jak taki wzorek wygenerować do testów.

marek_kleciak · July 18, 2017, 4:28pm

+1!

I walczcie nadal o area:highway!

kocio · July 18, 2017, 4:46pm

Na razie walczę o rilis… =} Bośmy nieopatrznie naobiecywali (zbędną moim zdaniem) zgodność wsteczną z serią v3.x przez minimum 2 wydania, a tymczasem nikt jakoś nie zajmuje się zmianami do v3 i przez to grozi nam paraliż z akceptowaniem i wydawaniem kodu w serii v4:

https://github.com/gravitystorm/openstreetmap-carto/issues/2666

Inne sensowne rzeczy to popchanie do przodu poprawek midzoom+wody (być może zostanie to przepisane na mniejsze fragmenty) tudzież kwestia wyświetlania wież i masztów - wmyrda przedstawił swój kod, za co mu chwała, i nawet ten kod wystawiłem:

https://github.com/gravitystorm/openstreetmap-carto/pull/2671

ale taka szeroka zmiana wymaga jeszcze dużo testów, dyskusji i nanoszenia poprawek. Lepiej na pewno, żeby to poprowadził autor. Gra jest warta świeczki, moim zdaniem.

No i zobaczymy jeszcze co inni powiedzą na ideę wyświetlania kostki.

TomaszWójcik · July 19, 2017, 5:18am

Kocio, skoro pojawił się temat renderowania chodników, może to dobry moment żeby zaproponować renderowanie area:highway=footway/ pedestrian (wyświetlane tak samo jak footway/ pedestrian z tagiem area=yes), rozpocząć dyskusję nad area:highway=cycleway, a w następnej kolejności wysepkami traffic_calming=island/ area:highway=traffic_island? Ty lepiej wyczuwasz te nastroje na githubie
I jeszcze chciałbym się upewnić, czy dobrze zrozumiałem, że bilecik z przeniesieniem barier nad obszary chodników został zamknięty, bo żywopłoty będą zasłaniać drogi? Przecież takich przypadków nie byłoby zbyt wiele, a obecne wyświetlanie wolnej drogi tam, gdzie jest ona zamknięta płotem czy murem wprowadza użytkownika mapy w błąd…

marek_kleciak · July 19, 2017, 5:23am

**+1! **

kocio · July 19, 2017, 9:46am

Nie widzę teraz takiej atmosfery. Fakt, stopniowo robi się coraz więcej elastyczności i decyzyjności, a nawet jest już możliwość techniczna wdrożenia a:h (dzięki wdrożeniu hstore w bazie dostępne do wyświetlania są już wszystkie tagi), ale tu działa tylko długotrwałe zaangażowanie w dyskusje.

To jest problem ludzko-organizacyjny, ale dochodzi jeszcze to, że styl jest już bardzo złożony i zasoby serwerowe nie mają zapasu mocy, więc trzeba pilnować wydajności. Gdyby nie to ostatnie, to już dawno mielibyśmy równolegle wdrożone kilka stylów (w tym z a:h, 3D, indoor i building:part=*) i trwałyby intensywne eksperymenty nad stylami wektorowymi. Być może OSM Polska byłoby w stanie coś pomóc w kwestii znalezienia i utrzymania takiego sprzętu - moim zdaniem to byłoby ważniejsze niż pieniądze w gotówce.

Oczywiście można nadal argumentować i dyskutować nad zrobieniem tego w domyślnym stylu:

https://github.com/gravitystorm/openstreetmap-carto/issues/180

Tak, o ile pamiętam tego się obawialiśmy, że różne przeszkody będą wizualnie sugerować, że nie da się przejechać:

https://github.com/gravitystorm/openstreetmap-carto/pull/2394

Jeśli chcesz podyskutować, to dopisz się tam. Zabrakło argumentów za włączeniem tego kodu, który już jest gotowy, ale jeśli się znajdą, to można to nadal zrobić. Przydadzą się zwłaszcza przykłady, statystyki itp., czyli jakieś dowody na poparcie swojego zdania.

kocio · July 20, 2017, 12:16pm

@Tomasz_W: Bardzo dobra robota z tymi wpisami! Kolejny krok to przypominanie się, ewentualnie propozycja kodu, czyli to długotrwałe zaangażowanie, o którym wspominałem.

kocio · July 21, 2017, 3:30pm

@Mateusz Konieczny, @wmyrda: Czy jesteście w stanie mi poradzić co zrobić z tym problemem? Jestem w stanie zdefiniować wygląd dla wysepek drogowych, ale nie działa to jeśli nie ma dodatkowo tagu “highway”. Strasznie skomplikowane mamy te SQL-owe regułki.

wmyrda · July 21, 2017, 3:46pm

A od kiedy to ja jestem ekspert od SQLa? Co prawda byłem w nim jednym z lepszych na roku, ale to było z 15 lat temu Teraz sam mam problemy z kodem i jak do mnie gość mówi https://github.com/gravitystorm/openstreetmap-carto/pull/2686#issuecomment-314526930 to ktoś to musi wpierw na angielski chociaż przetłumaczyć ^^

rmikke · July 21, 2017, 3:51pm

A jak całe zapytanie wygląda?

kocio · July 21, 2017, 4:05pm

Cały kod warstwy wygląda tak (@wmyrda: zdaje się że to co ci tłumaczył to dodanie wiersza tags do odpowiednich warstw, jak tu poniżej):


  - id: highway-area-fill
    # FIXME: No geometry?
    <<: *extents
    Datasource:
      <<: *osm2pgsql
      table: |-
        (SELECT
            way,
            tags->'traffic_calming' as traffic_calming,
            COALESCE(
              ('highway_' || (CASE WHEN highway IN ('residential', 'unclassified', 'pedestrian', 'service', 'footway', 'cycleway', 'living_street', 
                                                    'track', 'path', 'platform', 'services') THEN highway ELSE NULL END)),
              ('railway_' || (CASE WHEN railway IN ('platform') THEN railway ELSE NULL END)),
              (('aeroway_' || CASE WHEN aeroway IN ('runway', 'taxiway', 'helipad') THEN aeroway ELSE NULL END))
            ) AS feature
          FROM planet_osm_polygon
          WHERE highway IN ('residential', 'unclassified', 'pedestrian', 'service', 'footway', 'living_street', 'track', 'path', 'platform', 'services')
            OR railway IN ('platform')
            OR aeroway IN ('runway', 'taxiway', 'helipad')
          ORDER BY COALESCE(layer,0), way_area desc
        ) AS highway_area_fill
    properties:
      minzoom: 14

rmikke · July 21, 2017, 5:05pm

Obstawiam, że:


  - id: highway-area-fill
    # FIXME: No geometry?
    <<: *extents
    Datasource:
      <<: *osm2pgsql
      table: |-
        (SELECT
            way,
            tags->'traffic_calming' as traffic_calming,
            COALESCE(
              ('highway_' || (CASE WHEN highway IN ('residential', 'unclassified', 'pedestrian', 'service', 'footway', 'cycleway', 'living_street', 
                                                    'track', 'path', 'platform', 'services') THEN highway ELSE NULL END) 
			  || (CASE WHEN tags->'traffic_calming' IN ('island', 'chicane') THEN tags->traffic_calming ELSE NULL END)),
              ('railway_' || (CASE WHEN railway IN ('platform') THEN railway ELSE NULL END)),
              (('aeroway_' || CASE WHEN aeroway IN ('runway', 'taxiway', 'helipad') THEN aeroway ELSE NULL END))
            ) AS feature
          FROM planet_osm_polygon
          WHERE highway IN ('residential', 'unclassified', 'pedestrian', 'service', 'footway', 'living_street', 'track', 'path', 'platform', 'services')
            OR railway IN ('platform')
            OR aeroway IN ('runway', 'taxiway', 'helipad')
	    OR (tags->'traffic_calming' IN ('island', 'chicane') AND tags->'area' = 'yes')
          ORDER BY COALESCE(layer,0), way_area desc
        ) AS highway_area_fill
    properties:
      minzoom: 14

Tylko wtedy same wysepki będą traktowane jako rodzaj highway (dostaniesz dla feature wartości highway_island i highway_chicane).

kocio · July 21, 2017, 5:34pm

Hm, zmieniłem:

	    OR (tags->'traffic_calming' IN ('island', 'chicane') AND tags->'area' = 'yes')

na

	    OR tags->'traffic_calming' IN ('island')

i wyrzuciłem

            tags->'traffic_calming' as traffic_calming,

bo inaczej dostawałem:


YAMLException: can not read a block mapping entry; a multiline key may not be an implicit key at line 857, column 15:
        properties:
                  ^

i… nadal tak samo - wyświetla tylko z highway.

Kurczę, może to efekt przekształceń lua:

https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua

TomaszWójcik · July 21, 2017, 6:20pm

jeszcze co do samego wyświetlania tych wysepek, nie wiem jaki jest zamysł, ale ja myślę, że lepszy byłby kolor o połowę jaśniejszy od tego z wizualizacji a:h + krawędź dookoła, taka jak w przypadku obrysów chodników (proponowałem to w odpowiednim wątku, ale było to już po tym, jak urwał się kontakt z autorem)

kocio · July 21, 2017, 10:55pm

Jak dla mnie szary wygląda fajnie:

https://github.com/gravitystorm/openstreetmap-carto/issues/622#issuecomment-317130373

A jak w dodatku zmieni się kolor wody, to nawet zaniedbane niskie poziomy przybliżenia (pozbawione choćby lasów) zaczynają wyglądać kulturalnie:

https://github.com/gravitystorm/openstreetmap-carto/issues/2688#issuecomment-317144397

kocio · July 22, 2017, 12:24pm

Jest propozycja, żeby pogłosować na najbardziej pożądane zgłoszenia - polecam, dla nas to jakiś wskaźnik co warto zmienić/dodać w stylu:

https://github.com/gravitystorm/openstreetmap-carto/issues/2696

kocio · July 25, 2017, 1:38pm

Potrzeba nieco to poprawić, ale cieszę się, że jest już przygotowany kod do wyświetlania typu lasów/drzew (w sensie liściaste, iglaste, mieszane, bezlistne lub nieokreślone jak obecnie):

https://github.com/gravitystorm/openstreetmap-carto/pull/2708