O widzisz tego nie wiedziałem, trudno. Jeśli a:h nie będzie to zawsze taki obszar będzie można oznaczyć area=yes + name=*
Namawiam Marka aby zmienił specyfikację i aby walidador sprawdzał przecięcia poligonów z liniami tylko dla głównych dróg.
Zatem podjazdy jako service, footway i może cycleway. ale skoro render ma obsługiwać zebry i przejazdy rowerowe to może tego akurat nie trzeba.
Wyobraź sobie jaka kaszana robi sie gdy na gęstej sieci chodniczków wokół trawniczków majacych kilka metrów szerokości na każdym przecięciu footway a nawet wydeptanych path trzeba rysować poligon i sprawdzać czy ma wszystkie punkty wspólne i sąsiednimi poligonami i przecinającymi je way.Często z way ma punkt wspólny tylko jeden poligon, a sąsiad nie i pod JOSMEM tego nie widać, bo jest węzeł tam gdzie powinien być ale łączy tylko dwa obiekty zamiast trzech.
Często dochodzi do pomyłek i nadaje się a:h tag od drogi o nizszej kategorii,
To podnosi pracochłonność x10 w stosunku do mapowania liniowego i to właśnie zabija metodę a:h.gdy co 10 metrów jest skrzyżowanie, bo albo w lewo prowadzi podjazd albo 5 m dalej w prawo?
Często długość a:h przez to jest mniejsza niż szerokość.
Sprawa jest prosta.Skoro maperzy mogą decydować za pomocą layer, który obiekt ma się renderować na którym , to tak samo powinni dostać możliwość przesuwania napisów w dogodne miejsce. A krótkie odcinki dróg mogłyby dostać tag zakazujący renderować na nim nazwę dla wskazanych zoomów.
Dodatkowo dziś słabo wykorzystuje sie kolorystykę i pogrubienie czcionek.
Render sam próbuje ustalić jakie obiekty są walniejsze czy to według klucza, czy według dodatkowych tagów ,czy też zasłaniania.
Kocio pisał ze rozsunięto nr adresowe od nazw budynków ale ja nie zauważyłem,To chore jest aby mieć do 20 zoomów i aby odgórnie decydować które dane będą wyświetlane z obrysu.
Podobnie skoro czcionki są małe i np nazwa wielkiego lasu jest tylko w smrodku to maperzy powinni mieć mozliwość dodania tej nazwy do punktów i powielenia jej aby na każdym ekranie nazwa lasu się wyświetliła a na dużych ekranach nawet 2-3 razy
Ja bym tak się nie trzymał definicji zoomów - to jest dane tylko dla konkretnego typu map, nie jest to wielkość fizyczna typu skala, tylko umowna, więc tu w ogóle nie widzę możliwości ręcznej kontroli.
Problem posiekanych na kawałki dróg moim zdaniem należałoby raczej załatwić za pomocą relacji (czyli “te wszystkie kawałki z różnymi parametrami tworzą jedną drogę o wspólnej nazwie”). To miałoby znaczenie nie tylko wizualne - to także kwestia wyszukiwania obiektu o tej nazwie, linków z Wikipedii albo możliwości analizy danych.
Nie rozumiem co masz na myśli? To jeden problem czy dwa różne? I co jest nie tak z ustalaniem ważności?
Kolorystyka moim zdaniem jest wykorzystana na maksa - problem nowej kolorystyki dróg wyraźnie to pokazał, a i potem się z tym coraz częściej zderzamy, więc zupełnie się nie zgadzam. A czcionki - co niby miałoby być pogrubiane?
Nie rozumiem co masz na myśli i nie umiem sobie przypomnieć nic, co bym pisał o odsuwaniu.
Na jakim “ekranie”? Przecież to też nie jest wielkość fizyczna i każdy ma inny, nie widzę opcji żeby móc to ręcznie skalibrować. Automatycznie można, ale nie w osm-carto czy innym statycznym stylu, to już kwestia stylów wektorowych, obliczanych po stronie klienta.
Oczywiście, że tak!
Poszedłbym dalej w tym kierunku - tak samo należy potraktować liniowo zmapowane ulice. Wszystkie kawałki w relację i to relacja ma nazwę, a nie kawałki - w ten sposób to render będzie decydować, gdzie wyświetlać nazwę, a wyszukiwarka znajdzie i pokaże jedną ulicę, a nie stopińdziesiont kawałków. Skoro mozna tak traktować drogi krajowe, to czemu nie ulice?
I jedno z drugim można i należy połączyć, i.e. liniowo zmapowana ulica i a:h tej ulicy to powinna być jedna relacja.
Jest taka relacja i nawet dość powszechnie używana, choć raczej do określania przynależności budynków:
https://wiki.openstreetmap.org/wiki/Relation:street
https://taginfo.openstreetmap.org/relations/street#roles
Same ulice to tylko 50 tys.
Jest też taka relacja, nawet bardziej popularna, ale tym bardziej wygląda mi na bardziej adresową, czyli dla budynków:
https://wiki.openstreetmap.org/wiki/Relation:associatedStreet
https://taginfo.openstreetmap.org/relations/?rtype=associatedStreet#roles
Tu ulice mają niecałe 0,5 mln wystąpień.
No właśnie o tym cały czas mówię by użyć formy nadrzędnej nad pojedynczymi odcinkami dróg, rzek i innych poćwiartowanych obiektów. Niech to będzie polygon jeśli to ma załatwić temat 
Mhm, czyli znowu rozmawiamy o mapowaniu pod render…
Nie wiem skąd wziąłeś ten wniosek.
To by załatwiło możliwość sensownego renderowania, ale tylko przy okazji - przecież napisałem co jeszcze by to dało. Ulica np. Dworcowa jest jednym obiektem, a odcinki są czysto technicznym rozwiązaniem, które załatwia nam inne rzeczy, ale psuje zasadniczy sens.
O każdym jednym poolygonie w bazie można powiedzieć, że to mapowanie pod render, gdyż jest to nic innego jak pomoc dla rendera by łatwiej wyświetlić obiekty podając mu na tacy relacje pomiędzy nimi.
Dla przykładu jak las się składa z 20 kawałków i do tego ma wycięte wewnątrz kolejne obszary, które są częścią polygonu to to też jest mapowanie pod render. Nie rozumiem czemu w przypadku dróg nagle taka pomoc dla rendera miała by być nagle zła.
Jak to umowna?
Nawet konkurencja operuje zoomami i wydawało mi się,ze widziałem wzory które wiążą poziom zooma z odleglejszą czyli skalą mapy.
Ale nawet gdyby założyć że osm ma swoje definicje zoomów to przecież każdy maper oglądając konkretnego zooma na komputerze stacjonarnym widzi konflikty wynikające z gęstości danych.
Style mobile przeliczałyby sobie tag zoomowy w zależności od przyjętej PPI(DPI) urządzeń mobilnych.Zatem autro mógły otagować tylko te zoomy które go rażą, a wysokie zoomy rozkładałyby napisy automatem
Wg mnie relacje zabijają OSM.
Zarówno JOSM nie daje sobie rady z relacjami np utrudniona jest praca na nich czy podgląd historii, kopiowanie tagów między relacjami.
Podobnie wtyczki wykładają się na relacjach, zatem tworzenie nowych relacji gdy nie opanowano starych może narobić problemów.
Brakuje np. dobrej relacji dla budynków rozróżniającej kompleks wielu budynków od zbioru building:part.
OSM to mapa wielopokoleniowa na której i tak tagowanie staje się coraz bardziej skomplikowane.W miarę zwiększania ilości danych coraz większego znaczenie nabiera aktywacja nowicjuszy czyli lokalnych maperów.Oni mają szanse namieszać w relacjach lub się zniechęcić i odejść.
Mamy masę konfliktów z renderem i nikłe szanse aby je rozwiązać w najbliższym czasie.
Nie dziwi że informatycy wierzą w programowe rozwiązywanie problemów ale to tylko brnięcie dalej w ślepą uliczkę i odbierania prawa do malowania mapy ludziom.
Na mapach robionych gęsim piórem udawało się zmieścić więcej danych.
OSM to mapa globalna i nie uwzględnia regionalizmów.
W pewnych rejonach maperzy mogą chcieć aby jedne dane były reprezentowane przed innymi
Na tym etapie dyskusji nie rozróznialbym ile to problemów bo generalnie napisy leżą totalnie na OSM.
Pisałem ze kartografia to sztuka pogodzenia napisów i ikon.
Gdy OSM i mapy papierowe mają multum ikon to jednak w kwestii napisów różnimy sie całkowicie zarówno co od wielkości czcionki. ukosie, rodzaju czcionki, podkreśleniom, pogrubieniom, kolorze czcionek, przeźroczystości, przecinaniu różnych napisów, replikacji na dużym obiekcie, położeniu początku napisu, odsunięciu od obiektu, zmieszczeniu sie w obrębie poligony.
Poz tym porównaniem nie ma u nas dynamicznego strącania napisu przy konfliktach, mei ma reprezentacja kropką czy innym znakiem że napis został ukryty. Ustalanie ważności tzn., że autor stylu podbija globalnie pewne tagi np.tourism=attraction a może w pewnych miejscach maper wolałby podbić historic np. pałac czy pomnik? Generalnie jeśli obiekt jest większy niz ekran to np nazwa lasu powinna być większa czcionką a nie mieścić sie na jednym oddziale leśnym.Zatem chodzi o pewną elastyczność co dla konkretnego terenu jest ważniejsze jeśli obeikty są blisko. Przykładowo ikona zamku, hotelu czy restauracji na tym samym budynku? Napisy będą częściej wchodzić w konflikty niż ikony.Konflikt napis kontra ikona, też może być rozwiązywany różnie
Ponieważ render może sobie sam poskładać taką pociętą drogę w jedną. A multipolygony o których piszesz, to nie to samo - słaba analogia.
Nie wypowiadam sie w kwestii o której wiesz lepiej.Każdy rozumie że jeśli przez setki lat dawało się czarnym kolorem zaprezentować większość tego co dziś mamy na mapie to dysponując paletą kolorów dałoby się dużo więcej.
Do tego rozmaite siatkowanie landuse.Proszę sobie narysować teren wojskowy pokryty scrubem aby zobaczyć ciekawy efekt. Czyli jeśli mamy render w postaci siatki to nawet grubość włókien siatki czy wielkość oczek mogłaby reprezentować jakiś atrybut.
Np. na mapach papierowych droga brukowana rysowana jest tak ze każdy rozumie że to bruk a nazwa drogi może być poza nią.
Nie ma sie co spierać teraz o szczegóły, ale żadne popup-y nie zastąpią mapy na której oczyma podróżnik odczyta która droga jest asfaltowa, nierówna, błotnista, piaszczysta, kamienista, pochyła. Mapy nie należy macać aby dodatkowe informacje wyskakiwały.
Mają się renderować najistotniejsze informacje mające wpływ na wybór kierunki i czas przejazdu .Cała reszta jak POI to tylko otoczka a człowiek nie może klnąc że mapa wprowadziła go na kiepską drogę.
Jest to szczególnie ważne na OSM gdzie render nie odzwierciedla nawierzchni i bywa że porządna droga z tłucznia i piachu rysowana jest jako track gruntowy często bez grade1 a “dachówkowa” droga polna wali po oczach jako unclassified choć auta łamią tam wahacze.
Na osm jest za dużo kolorków służących do wypełniania przestrzeni a za mało rozróżnia sie obiekty o podstawowym znaczeniu dla komfortu podróży. Jedyny dobry render dostały drogi prywatne ale czy to nie marnotrawstwo renderu skoro mozna je było pozamykać bramami?
Zatem nie można się tylko ograniczać do koloru dróg a należy wykorzystywać kreskowania bocznych krawędzi tychże.
My preferujemy refy a np mapy wojskowe na drogach renderują szerokość co przy trackach już wiele mówi
Oprócz kolorów mamy jaskrawość czyli poprawniej nasycenie oraz kombinacje z cieniowaniem czy mikro-ikonkami robiącymi tło.To można jeszcze łączyć ze zmienną czcionką i sposobem rysowania konturów
Musiałem Cię źle zrozumieć. Jakoś miesiąc temu pisałeś że podobne algorytmy jak przy odsuwaniu ikon zostały zaimplementowawszy aby name nie wycięło adresu.Widocznie się za wcześnie ucieszyłem że ktoś ruszył głowa aby połączyć na mapie dwie ważne informacje.Jeśli to zadanie przerasta możliwości to kolejny argument aby przypinać napis ręcznie.
Pisałeś o relacjach więc dlaczego nie może być prostej relacji łączącej napis z obiektem co skutkowałoby połączeniem obu na mapie cienką linią gdy napis byłby odsunięty ręcznie.
Ekran czyli aplikacja decyduje ile kafelków dla konkretnego zooma mieści sie na ekranie.Zatem nie trzeba nic kalibrować tylko uwzględniając różne PPI ekranu komputera napis powtórzyć jeśli obiekt jest większy niż kafle np 6x6 cm .Czyli na wielkim ekranie byłoby to ok 6 powtórzeń w poziomie a na małym mniej bo mniej kafli sie mieści choć mają większa gestosc pikseli na cm.
Upraszczając dziś rozmiar w pixelach urządzeń mobilnych i monitów stacjonarnych jest zbliżony to renderowanie powinno być podobne.
Czyli uproszczeniu nazwa puszczy będzie na każdym kafelku.
Można sie zastanawiać kiedy to będzie bardziej potrzebne np gdy jest jezioro przy jeziorze albo gdy przełęcz dzieli dwa pasma górskie.taka informacja ważna by była dla parków narodowych czy innych bo nakazuje np sposób poruszania sie tylko po szlakach więc używając jakiego praktycznego zooma np16-tego nie wiemy czy wyszliśmy poza rezerwat czy jeszcze nie.
Ponieważ są różne gęstości pikseli na monitorze stacjonarnym celowo nie podaje się skali mapy a tylko podziałkę kilometrową.
Zatem jeśli ktoś ma ustawione więcej DPI to ma wszystkie napisy mniejsze ale puszcza byłaby mniejsza wiec ilość powtórzeń nazwy nie zmieniałaby się z rozmiarem na ekranie tylko zależałby od tego na ilu kaflach obiekt się mieści.
Podawalibyśmy to dla stylu podstawowego a autor stylu mobilnego stosujący inne gęstości czyli rozmiary kafli, stosowałby swój mnożnik jeśli uznałby, że napisy są za gęsto. Przecież to podobny mechanizm jak replikacja nazw ulic.
Skoro może to szkoda, że tak nie robi zwłaszcza na rozdzielonych pasach jezdni
A dlaczego JOSM nie zakłada sobie automatycznie relacji przy dzieleniu dróg?
Dlaczego nie można wykorzystać historii drogi która jest cięta na coraz mniejsze kawałki do obsługi wielu relacji?
Jeśli dziś render nie wie, które kawałki ulic wyrzucić z renderu nazwy ulicy, to nie sądzę aby zmądrzał obsługując relację.
Wydaje mi się, że nie należy skupiać się tu tylko na ulicach, bo te akurat mają niezły render nazw oraz mają zarezerwowane miejsce pod nazwy.
Problem umieszczania napisów aby nie powodowały konfliktów jest dużo szerszy i będzie narastał gdy ciekawych danych będzie przybywać a ich różnorodność spowoduje że mogą być reprezentowane tylko przez name.
Czyli częściej będzie bolesny brak napisów niż ich nadmiar czy chaotyczność.
Poziomami zooma operujemy w stylu, bo tu sobie przyjęliśmy co który poziom oznacza. Ty postulujesz tagowanie, a fizycznie zoom jest kompletną abstrakcją. Dopiero skala mapy jest fizyczna, więc można by te hinty tagować - o ile zasady projektu na to pozwalają.
Nie widzę żadnej konkretnej propozycji jak to załatwić. Tagowanie zgłoś na listę Tagging, bileciki o wyświetlaniu na osm-carto, inaczej szanse nie są nikłe, tylko dosłownie żadne.
Jakkolwiek rozumiem, że relacje utrudniają życie, to raczej stawiałbym na ich lepszą obsługę, bo nie widzę innego rozwiązania.
Dużo więcej, to tylko jeden z aspektów.
Ja nawet nie wiem co masz na myśli. Gdybyś choć jednym z problemów zajął się konkretnie i go pilotował, to by był pożytek, a tak to nie widzę żadnego. To jest forum dyskusyjne i możemy sobie pogadać do syta, oczywiście, wiec nie mam nic przeciwko, ale ani forma, ani miejsce tego zgłoszenia nie pomogą w twoim bólu.
Jest ukrywanie napisów oraz ikon, gdy na siebie nachodzą.
Jeśli mamy uwzględniać ekrany albo cokolwiek dynamicznego, to znowu mowa o stylu wektorowym, bo statyczny tego nie jest w stanie obsłużyć, więc proponuję osobny wątek na życzenia co ma robić styl wektorowy jak kiedyś będziemy w stanie go mieć. Na pewno nie w tym wątku.
Może tak samo posklejać sobie ileś kawałków parku narodowego z tą samą nazwą. Ale nie tylko render - tak samo dowolna analiza obiektów. Dlatego relacja w bazie ma sens - jasno na poziomie danych mówimy, że to jest jeden obiekt, a nie przypadkowa zbieżność nazw. Uparłeś się na render - a wyszukiwanie ulicy jak ma pokazać wynik, to co pokaże - który wycinek drogi i dlaczego nie wszystkie, skoro ulica nie jest tylko swoim kawałkiem?
Nie wiem - ja szukam zwykle adresu (takiego z numerem domu itp.) i nie doświadczam takich problemów.
To, o czym teraz piszesz, jest mapowaniem pod wyszukiwarkę - dodajmy relację, bo wyszukiwarka pokazuje tylko losowy kawałek ulicy … a kysz! 
Nadal można jednym kolorem:
Ale paletę zużyliśmy właściwie całą i ona faktycznie pokazuje dużo więcej niż jeden kolor. Tylko więcej trudno już wycisnąć z kolorów, bo doszliśmy do granic ludzkiej percepcji kolorów i wzorów. Owszem, są liczne odcienie, ale np. jak nie sąsiadują ze sobą bezpośrednio, to nie umiem odróżnić landuse commercial od retail, choć niby są to inne kolory. Podobny problem jest z odróżnieniem terenu budowy od budynku w pewnych warunkach, choć też się różnią na palecie:
https://github.com/gravitystorm/openstreetmap-carto/issues/2353
Z kolorami doszliśmy już naprawdę do ściany.
Przypomnę, że osm-carto jest stylem uniwersalnym. Kod do obsługi dróg jest już w nim ogromny, bo drogi są istotnym elementem mapy, ale jednak to nie jest styl transportowy, tylko do wszystkiego. Jest dyskusja o mapowaniu dróg ubitych i nieubitych i od 3,5 roku nie wiadomo nawet jak to miałoby właściwie wyglądać, tylko jest festiwal, że to jest ważne:
https://github.com/gravitystorm/openstreetmap-carto/issues/110
Może i ważne, ale do jazdy jest specjalne oprogramowanie, które uwzględnia takie rzeczy. Mapa ogólna nie służy do wyszukiwania i prowadzenia. Dopóki te dwie funkcje dały się pogodzić, to proszę bardzo, ale już się nie daje i drogocentryczność nie ma racji bytu.
Może chodziło ci o dodanie wyświetlania numeru:
https://github.com/gravitystorm/openstreetmap-carto/pull/2351
To wymaga dynamicznego stylu wektorowego. W rastrowym osm-carto to nie zadziała - zły wątek.
Jeśli chcesz uwzględniać ekrany, to nie wystarczy podać stylu, ale trzeba jeszcze uwzględnić jaki ekran ma użytkownik - ja mam inny, a ty inny. Dlatego to wymaga dynamicznego stylu wektorowego i nie da się zrobić w statycznym.
Pokazałem kilka przykładów - skoro jest na raz pod render i pod wyszukiwarkę, to może jednak po prostu jest to ogólny problem?.. Bo moim zdaniem pod wszystko, gdzie mówimy o obiekcie “ulica”, czyli problem jest w reprezentacji danych. Dopóki jest jednoczęściowa, nie ma problemu - wiemy jaka jest, jaką ma długość, skąd dokąd przebiega itp.:
http://www.openstreetmap.org/way/28008126
Ale jeśli jest bytem złożonym, to potrzebuję tego obiektu, a nie się domyślać z czego jest złożony, bo mogę popełnić błąd. To na pewno nie jest ulica Marszałkowska, o którą mi chodzi, to może być nawet zupełnie inny odcinek niż mam na myśli:
http://www.openstreetmap.org/way/305333775
Więc jeśli chcę mieć taki obiekt:
https://pl.wikipedia.org/wiki/Ulica_Marsza%C5%82kowska_w_Warszawie
to łatwo zauważyć, że na mapce nie jest cały. I to jest właśnie to, że fizyczny obiekt nie ma reprezentacji w bazie. A potrzebuję tego obiektu, wszystko jedno do czego - choćby do zrobienia statystyki ulic w mieście, czyli kolejne zastosowanie, gdzie obecne dane nas zawiodą, bo są z powodów technicznych pocięte na kawałki.
Zbyszek proszę cię, ale się czepiasz i to do tego nie rozsądnie. Tak samo jak szlak nadrzędny składa się ze szlaków podrzędnych tak samo droga składa się z odcinków i najlepszym znanym sposobem podpowiedzenia aplikacji, że ma doczynienia z całym odcinkiem jest spięcie jej relacją. Nie ma w tym nic nadzwyczajnego. Dałem ci przykład z lasami, gdyż jest to dokładna analogia dla obszaru drogi i chętnie usłyszę czym się różni jedno od drugiego co by dyskwalifikowało taką relację w przypadku dróg.