Wyświetlanie na domyślnej mapie

Przeczytałem “Unreleased”, to myślałem, że jest jeszcze w przygotowaniu.

Czy te ostatnie zmiany (use ST_PointOnSurface for building label placement) dotyczą ikonek dla amenity=* lub historic=* ustawionych na obrysie budynku? Właśnie dostrzegłem w kilku przypadkach, że wywędrowały one z centroidu, ustępując tam miejsca numerowi domu, lądując w innym, trudnym do określenia miejscu na obszarze budynku, często zaskakująco blisko jego obrysu.

https://www.openstreetmap.org/#map=19/52.24713/21.01578 (Pałac pod Blachą)
https://www.openstreetmap.org/#map=19/52.24272/21.01629 (Pałac Prezydencki, Hotel Bristol)
https://www.openstreetmap.org/#map=19/52.21499/21.03565 (Pałac na Wyspie)

Wygląda to w tych przypadkach źle, bo zupełnie nie widać, że ikonka dotyczy całego budynku. Dysonans jest zwłaszcza, kiedy wyświetlana nazwa jest jednocześnie nazwą budynku. Gdyby nie ów dodatkowy tag wyświetlana byłaby na centroidzie.

Druga ciekawostka, o którą chciałbym zapytać, to występowanie podpisów do ikonek, które nie są widoczne z powodu declutteringu.
https://www.openstreetmap.org/#map=18/52.15515/21.03062 (Miejska dotyczy apteki, ale jej ikonka jest przesłonięta przez symbol przychodni, który z kolei nie ma podpisu)
https://www.openstreetmap.org/#map=19/52.16120/21.02809 (Mennica Polska dotyczy automatu biletowego, ale jego ikonka nie wyświetla się z powodu symbolu bankomatu, który z kolei nie ma podpisu)

Kłamię, nazwy budynków także wywędrowały na nowe pozycje, wskutek czego wyświetlana jest teraz zarówno cyfra oznaczająca numer domu jak i nazwa budynku.

https://www.openstreetmap.org/#map=19/52.13166/21.05518

Wydaje mi się błędne, aby dwa podpisy dotyczące dokładnie tego samego obiektu znajdowały się w różnych miejscach.

Edit: OK, dziś jakoś jednak znalazłem ślady (1, 2), że ten problem jest znany.

Tu jest bilecik na temat powiązania podpisów z ikonkami:

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

Są dwa zadania czysto programistyczne, które byłoby fajnie załatwić w celu lepszego wyświetlania. Jeśli ktoś jest chętny, to dajcie znać:

  1. Powiązanie napisów z ikonami - https://github.com/gravitystorm/openstreetmap-carto/issues/234

Chodzi o to, żeby nie było sytuacji, kiedy ikonka jest czymś zasłonięta i widać tylko podpis do niej. Trzeba wdrożyć nową funkcjonalność Mapnika do CartoCSS, żeby można było to z kolei używać w OSM Carto

  1. https://github.com/gravitystorm/openstreetmap-carto/pull/3874#issuecomment-529172782 (sensowne centrowanie napisów)

Niedawno porzuciliśmy kod Mapnika, który wybiera miejsce umieszczenia napisu na obszarze, i w zamian zyskaliśmy na prędkości kompilacji oraz na zrzuceniu zbędnego kodu, ale niestety algorytm centrowania napisów z PostGISa jest kiepski.

Jest możliwość, żeby wobec tego zaimplementować nowy algorytm Mapnika w bibliotece OSGEO, której z kolei używa wiele innych projektów. Talaj, który ten nowy algorytm wymyślił i wdrażał w Mapniku (bo poprzedni algorytm Mapnika był podobnie kiepski jak ten obecny w OSGEO/PostGIS), nie bardzo ma czas, więc to może być na świętego Nigdy.

Czy ten algorytm byłby też warty rozważenia?
https://blog.mapbox.com/a-new-algorithm-for-finding-a-visual-center-of-a-polygon-7c77e6492fbc
Jest wersja w C++, 100 linii. Może autor byłby w stanie dołączyć go do GEOS, a więc i PostGIS?

Algorytm Mapboksa był bazą dla wersji pod Mapnika:

[ https://github.com/mapnik/mapnik/blob/master/src/geometry/interior.cpp#L41-L44 ]

Zasadniczo wolałbym właśnie tę wersję, bo jest bardziej dopieszczona, ale różnice nie są wielkie. Kulisy historii są takie, że przyszedłem do Talaja ze zgłoszeniem, że stary algorytm robi czasem ewidentne błędy w OSM Carto:

https://github.com/mapnik/mapnik/issues/3550

na co on najpierw poprawił te niedoróbki, a następnie wykombinował i wdrożył nowy algorytm. Testowałem go mocno:

https://github.com/mapnik/mapnik/pull/3811

a potem przez kolejne miesiące po wdrożeniu nowej wersji Mapnika na serwery OSMF oczywiście wielokrotnie patrzyłem na efekty i były w najgorszym razie przyzwoite, a czasem wręcz bardzo dobre, ale nigdy wątpliwe - jeden błąd został poprawiony po drodze:

https://github.com/mapnik/mapnik/pull/3811#issuecomment-361407576
https://github.com/mapnik/mapnik/pull/3844

Od tej pory jestem zadowolony z mapnikowego rozwiązania. No i historia trochę zatoczyła koło - znowu trzeba naprawiać to samo, tylko w innym miejscu… Na szczęście efekt będzie wtedy dostępny od razu w standardowej bibliotece używanej przez wiele projektów, a w dodatku kod już jest napisany i przetestowany, więc po prostu bardziej warto. Chodzi już tylko o osobę, która się tym zajmie.

Przykład na to, że Polylabel jest trochę za prosty:

https://api.mapbox.com/styles/v1/mapbox/streets-v11.html?title=true&access_token=pk.eyJ1IjoibWFwYm94IiwiYSI6ImNpejY4M29iazA2Z2gycXA4N2pmbDZmangifQ.-g_vE53SD2WrJ6tFX7QHmA#8.6/-15.7742/31.9626

Dla porównania interior (jeszcze nie odświeżone kafelki):

https://www.openstreetmap.org/#map=9/-15.6733/31.7381

Nowa wersja stylu (v4.23.0) zaczyna się wdrażać na serwerach:

https://www.openstreetmap.org/user/Joseph%20E/diary/390751

Gdy na obrysie budynku jest też tag z serii office=* z name=* (może dotyczy to też amenity=* i podobnych POI-ów), nazwa ta na poziomie 17 wyświetla się większa (jak dla nazwy budynku) niż na poziomach 18-19 (jak dla POI-a, razem z symbolem).

https://www.openstreetmap.org/#map=17/52.15079/21.02431
https://www.openstreetmap.org/#map=19/52.15085/21.02445

Już wcześniej tak było np. z nazwami szkół.

Przy okazji mapowania jednego z poznańskich cmentarzy zauważyłem dziwną hierarchię - kosze na śmieci (amenity=waste_basket) mają wyższy priorytet wyświetlania niż większe kontenery na śmieci (amenity=waste_disposal)

Przykład tutaj: https://www.openstreetmap.org/#map=19/52.38585/16.82933

Szkoda też, że mimo gotowych ikonek nie udało się dokończyć tematu renderowania kranów i pomp z wodą, więc mimo, że będą w wielu miejscach zmapowane, to będzie prawdopodobnie kolejny 1 listopada gdzie ludzie nie będą widzieć tych danych na mapie :frowning:

Przypadek. waste_basket i waste_disposal mają przydzielony ten sam priorytet.

Mapując ostatnio pomnik memorial=statue oraz kamień pamiątkowy memorial=stone (historic=memorial) blisko siebie, to name z kamienia zakrywał name z pomnika, który był ważniejszy w tym miejscu. Stworzyłem nowy node dla pomnika, wówczas jego id w bazie OSM miało wyższy numer niż node kamienia i teraz na mapie wyświetla się wszystko jak powinno.

Może kolejność renderingu oprócz priorytetu obiektów bierze pod uwagę ID obiektu?

osm-carto nie uwzględnia tu ID obiektu. Co nie oznacza, że nie może istnieć zależność pośrednia, wynikająca ze sposobu działania bazy danych i mapnika. Wykorzystywanie tego byłoby jednak formą tagowania pod render.

Jeśli uważacie, że waste_disposal powinien się zawsze renderować przed waste_basket, to wystarczy zrobić zgłoszenie. Kod do przydzielania priorytetu już jest, tyle że oba te obiekty dostają w nim tę samę wartość.

Edit:
To powyższe dotyczy tylko przypadku tutaj przedstawionego, czyli gdy oba obiekty są jako węzły. Nie jest to typowa sytuacja, bo najcześćiej śmietnik (wate_disposal) rysujemy jako obszar.
Śmietniki jako obszar są obsługiwane obsługuje inny kod i mają inny priorytet.

Jest problem z renderowaniem - Londyn dosłownie najechał na Warszawę, ale sprawa już jest chyba opanowana:

https://github.com/openstreetmap/operations/issues/340

A nie jest to przypadkiem związane z tym, że połowa Londynu przeteleportowała się ostatnio nad Wołgę ?
Było coś o tym na niemieckim forum => https://forum.openstreetmap.org/viewtopic.php?pid=768219#p768219

Zapewne to właśnie przez to.

Coś podziało się chyba z algorytmem wyświetlającym nazwy państw na zoomie 4 i 5.
W szczególności dotknięta Afryka => https://imgur.com/a/f8iuWzK

Podobne błędy widać też w Polsce w nazwach województw i miast wojewódzkich, na różnych poziomach zoomu.