Wyświetlanie na domyślnej mapie

Końskie tagi były niedawno zaproponowane jako kod, ale w wyniku dyskusji odrzucone:

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

A to nie jest tagowanie pod render?

Ja taguję landuse=farmyard + leisure=horse_riding.

To błąd tagowania czy renderowania?

Tu jest most, który jest nad drogą dla pieszych. Teraz to wygląda tak, jakby ścieżka i torowisko były zawieszone w powietrzu lub jakby przebiegały po tym szerokim deptaku. Da się to jakoś poprawić?

W osm-carto drogi się renderują nad obiektami.

Tagowanie jest poprawne.

Dlaczego przestały się wyświetlać nazwy szkół?

Na pewno nie wszystkie i na pewno nie celowo. Przypadki gdzie się to zepsuło warto wrzucić na https://github.com/gravitystorm/openstreetmap-carto/issues/3857 lub do nowego zgłoszenia.

Wtedy gdy jest jako punkt.

To tym bardziej dziwne, że nie wiem skąd ta zmiana, skoro ostatnia wersja OSM Carto wyszła w maju?

4.22.0

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