Popełniłem taki mały szkic jak mógłby w przyszłości wyglądać zoom level 19 z area:highway:
http://wiki.openstreetmap.org/wiki/File:MockupAreaHighwayWithStreetMidlines.jpg
Możesz dorzucić do bilecika na osm-carto. Tymczasem jest taka ciekawa uwaga, w którą niestety nie udało mi się wgryźć na tyle, żeby ją zrozumieć:
https://github.com/gravitystorm/openstreetmap-carto/issues/180#issuecomment-246173053
Proste, kolory muszą się nieco różnić by odróżniać można było, co jest wyżej a co niżej.
Dopisałem tabelę kolorystyczną, w wolnej chwili zrobię jakiś mockup jak by to wyglądało w praktyce…
- A nie zakładaliśmy w dyskusji nad wyglądem a:h że linie dróg będą pod obszarami, a wyświetlane będą tylko nazwy ulic, coś mi umknęło? Jeśli tak to jakie jest uzasadnienie półprzeroczystych linii?
- Czemu powstaje jakaś nowa wizualizacja odmienna od tego nad czy wspólnie tu wszyscy dyskutowaliśmy ulepszając wizualizację na OSMapa.pl/w/area (brak wzorku asfaltu, tylko prosty kolor) ?
różnica kolorów jak najbardziej, ale myślę że lepiej żeby się ograniczała tylko do nakładających się warstw a nie całych obszarów hen hen daleko dalej, bo wtedy wygląda to na jakąś inną kategorię drogi i może wprowadzać w błąd 
Może po prostu przedstawię szkice kolorystyczne by było łatwiej zrozumieć, o czym mówimy. Tak, różnice kolorystyczne mają być tylko na odcinkach mających dodatkowy tag layer=1, layer=2, layer=-1 itd…
Poza tym można też rysować mocniejsze obrysy. Trzeba to wypróbować.
Także z tunelami.
Warto pamiętać, że szarości są już używane do obrysów mostów, peronów oraz miejsc modlitwy (obszary nie będące budynkami).
Dorzuciłem się do dyskusji: https://github.com/gravitystorm/openstreetmap-carto/issues/180#issuecomment-246173053
Generalnie myślę, że nawet jeśli jakieś wartości kolorystyczne są już używane, np. do miejsc modlitwy, to jednak ze względu na geometrię będzie można takie obiekty łatwo rozróżnić. Ulice są zazwyczaj dłuższe niż kościoły.
Fajnie, że bezpośrednio się tam odzywasz, bo ja nie mam tak dużego zrozumienia detali a:h, a ciebie trudno w tym przebić. =}
Ja się cieszę, że jest to w miejscu gdzie komunikują się ludzie podejmujący decyzje.
Gdyby dodać do a:h kontury dla asfaltu i chodników i ścieżek rowerowych, to nie trzeba by różnych kolorów dla level=*
Patrz:
http://wiki.openstreetmap.org/wiki/File:MockupAreaHighwayWithStreetOutlines.jpg
Czy jest możliwość by na warstwie surface v2.1 drogi dla rowerów z surface=asfalt miały kolor czerwony - bo na razie maja ciemny - “czarny chropowaty”?
http://osmapa.pl/w/area/?lat=53.42667&lon=14.56509&zoom=18&ol=Qqs
Co do kwestii że coś będzie trzeba poprawić za jakiś czas z przebiegiem elementów a:h - trzeba to będzie zrobić drogi się zmieniają, tak ich przebiegi jak i ilości pasów. Co jakiś czas trzeba wracać w te miejsca i aktualizować; a-h także. Niestety świat sie zmieni i cholera idzie do przodu. Na razie według mojej oceny mamy wizualizację naturalnych elementów występujących na mapie. Przebieg drogi i jej kształt (ulica,chodnki, trawniki) wygląda ciekawie . Pisze to jako laik który zna tylko google maps; osmapa.pl i openstreetmap.org. Szkoda tylko że szukając informacji na tych stronach będąc w terenie czy przygotowując się do wyjazdu (nie wyszukując ich w programach nawigacyjnych) muszę - jako laik - skorzystać ze strony mapy od wujka Googla bo tam mogę zobaczyć info o interesującym mnie punkcie poi - choćby restauracja.
Myślę że kiedy będziemy mogli połączyć mapę z 3D z a:h i klikalnością punktów poi na mapie wtedy ludzie chętniej skorzystają z “naszych” map i przybędzie maperów. Naprawdę czekam kiedy będzie warstwa klikalna na osmapa.pl czy openstreetmap.org.
Jakby co przepraszam za mały offtopic 
Dyskusja na temat area:highway idzie na gravitystorm dalej i to dość intensywnie. Mapujcie dalej, być może w tym roku coś się z tego urodzi…
Dawno tu nie zaglądałem. Nie sądziłem, że temat area:highway jeszcze ożyje 
Kiedyś napisałem skrypt SQL do a:h, który był odpowiedzialny między innymi za pobieranie danych z linii i obsługę walidacji błędów. Tak, chodzi o ten walidator na wizualizacji marimila. Walidator o którym mało kto wie, a jak już wie to go nienawidzi, bo mu koloruje obszary na wszystkie kolory tęczy 
Pobieranie danych z linii można było zaobserwować również na wizualizacji marimila na warstwie “c) surface v2.1”. Od razu mówię, że nie mam dostępu do serwera, więc niestety nie mogę pomóc w kwestii poprawek czy kontynuowania prac nad tą wizualizacją. Dostęp miał marimil, a ja mu tylko podsyłałem aktualne wersje skryptu.
Co do skryptu, to nie ma on żadnej dokumentacji, nie jest najlepszej jakości, ale działa. Byłbym zaskoczony gdyby ktokolwiek zrobił z niego jakiś użytek. Ale gdyby jednak ktoś się chciał pobawić lub pooglądać, to udostępniam skrypt pod tym linkiem: ahp_script
Nie planuję dalszego rozwoju tego skryptu, bo nie mam już na to tyle czasu co kiedyś.
Co do tematu a:h, to większość swoich uwag napisałem już w tym temacie dawno temu, kiedy jeszcze cały koncept własnej, pełnej specyfikacji miałem w głowie. Niestety nie spisałem tego wszystkiego i teraz już zwyczajnie nie pamiętam szczegółów technicznych.
Jakby trochę pomarzyć to jak mógł wyglądać rozwój projektu a:h?
-
przetwarzaniem surowych danych, pobieraniem danych z linii i tworzeniem wirtualnych obiektów, jak. np. linii pasów ruchu itp. mógłby się zajmować program osm2pgsql. Nie jestem pewien ale chyba to on jest wykorzystywany przez Mapnik.
-
sam area:highway mógłby być nowym logicznym typem danych - obszarem z określonym kierunkiem (w tym poście opisałem to dokładniej)
-
jako logiczny typ danych mógłby się doczekać obsługi przez edytory, tak żeby edytor sam dbał o punkty wspólne i podział obszarów w przypadku pocięcia linii na kawałki. Wykluczyłoby to większość błędów, które można popełnić przy mapowaniu a:h
-
co do stylu wyświetlania to ja bym to raczej widział tak jak w pierwszych wizualizacjach marimila, przykład + do tego wyświetlanie pasów ruchu w kolorze obrysów danej kategorii drogi. Moim zdaniem całość byłaby bardziej spójna wizualnie niż mieszanie obecnego stylu mapnika z realistyczną teksturą asfaltu.
Jednak będąc realistą, to jeżeli a:h doczeka się renderingu, to pewnie będzie to proste wyświetlenie na podstawie wartości tagu. Co w perspektywie doprowadzi do tego, że a:h nie będzie się nadawać do niczego poza prostym renderingiem na bliskich zoomach.
W każdym razie życzę powodzenia wszystkim tym, którzy się jeszcze tym tematem zajmują
Darku, a mógłbyś zrobić/ uzupełnić dokumentację i wrzucić link do niej razem z Twoimi uwagami po angielsku tutaj:
https://github.com/gravitystorm/openstreetmap-carto/issues/180#issuecomment-246173053
Dyskusja jest ożywiona, więc dodanie linku do Twojego kodu będzie z pewnością mile widziane.
Im więcej nas będzie robiło lobbying za projektem, tym lepiej.
Przyznaję że nie chcę wszystkich uwag i sugestii wrzucać sam,
tak, żeby wśród angielskich kolegów nie powstało wrażenie że lobbuję sam za sobą.
Ciekawe: Kolega Marco Boeringa stworzył renderer area:highway pod ArcGis wszystkie przykłady które pokazał są… ze Szczecina.
Gratulacje!
area:higway złamało ważną zasadę na OSM, przechodzenia od mapowania zgrubnego do dokładnego. Jest zbyt szczegółowe i to je prawdopodobnie zabije poprzez zniechęcanie pracochłonnością.
Jedynym ratunkiem jest uproszczenie specyfikacji do zadań jakie a:h może podjąć w najbliższym czasie.
Należy działać dwuetapowo tzn. jeśli rendeing obszarowy jest łatwiejszy do wprowadzenia niż navi, to należałoby zrobić to co łatwiejsze aby wystąpił efekt skali, a resztą zająć się gdy będzie do czegoś potrzebna.
Wiele elementów zostało wprowadzonych bez podania powodów.
Walidador tworzy tęczę koncentrując się na trzeciorzędnych błędach.
W efekcie mapowanie zajmuje 40% czasu a czyszczenie walidadorem 60%.
Najgorsze jest to, że bardzo łatwo zakłócić już wyczyszczone walidadorem obszary gdy np. nowicjusz narysuje chodników lub dróg serwisowych jako podjazdy pod każdy dom jednorodzinny.
Zatem albo walidadory powinny być dwa, albo w jednym powinny być opcje wyłączania duperelków.
Pominę tu rozważania na temat podstawowego błędu wiki i wszelkich plików pomocowych tzn. ilość informacji niedopasowaną do różnych poziomów wtajemniczenia.
Powinien być najpierw plik po ludzku wyjaśniający ideę tak aby nawet nowy maper zrozumiał czemu ma to służyć na podstawie najprostszych przykładów, a stamtąd linkować do wersji dla zaawansowanych.
Zwykle ten co pisze pomoc jest mocny w temacie i nie chce sie zniżać do opisywania rzeczy trywialnych.
W efekcie ludzie robią coś czego do końca nie rozumieją i przez to generują masę błędów.
Jeśli staramy się od razu łączyć mapowanie pod render i pod navi, to ani nie wiemy co chcemy renderować a już kompletnie jakie funkcje zapewnić dla navi. Oznacza to że zarówno tagi pod render jaki i tagi i sposób kreślenia pod navi będzie w przyszłości zmieniony.
Oznacza to, że trzeba będzie przerabiać co jest zgodne z ideą OSM że będzie sie już pracować na wrysowanych obiektach czyli praca pójdzie szybko. Jednak elementy jakie będą poprawiane powinny mieć też pena hierarchię aby nie robić wszystkiego na raz gdyż będzie brak systematyczności i widocznych efektów.
Gro błędów jakie dziś robimy to błędy przecieć czyli zła współpraca szkieletu poligonowego z liniowym.Im większa tarcza skrzyżowania tym ma więcej puntów stycznych ze szkieletem liniowym. Na takiej tarczy jest masę wysepek i SBR (stref bez ruchu) co zamula i często trzeba łapać każdy z punktów aby sprawdzić czy jest wspólny z dwoma obszarami.
Tu JOSM się nie sprawdza, bo w szkielecie liniowym węzeł łączy dwie linie więc widać brak węzła lub postawienie go obok punktu przecięcia linii.
Zdarzają się błędy połączenia kilku poligonów np. oddziałów leśnych, ale taki błąd niczego nie psuje więc mało kto to sprząta, bo render sobie radzi.
Natomiast przy a:h węzeł łączy co najmniej jedną linie i dwa poligony, toteż najczęściej samym wzrokiem nie da się zauważyć że węzeł łączy linię tylko z jednym poligonem.
Pytane czy to trzeba walidować skoro a:h=track łączy się w jednym punkcie z h=track, więc jakikolwiek program wie który poligon z którą linie jest skojarzony a służyć to będzie zapewne do nadania kierunku jazdy po a:h. Tu brak wyjaśnienia czym takie nawigowanie miałoby być lepsze od nawigowani według linii.
Nie wiadomo dlaczego linia wewnątrz a:h nie może być przecięta. Cięcie a:h na kawałki, bo program nie może odczytać że ma dwie linie wewnątrz poligonu?
Dla mnie to niepojęte aby ręczną pracą zastępować to co programowo jest oczywiste.
A teraz to co najbardziej spowalnia mapowanie w a:h.
Jezdnia ma zwykle po 2 pasy dla każdego kierunku czyli średnio 13 m, a skrzyżowania są co 150-300m zaś na tej prostej rzadko robi się zebry, bo umieszcza się je na skrzyżowaniach. Mamy zatem a:h jako prostokąt 13x200m= 2600m2 jako jeden rodzaj a:h i jako jeden obiekt typu poligon wymagający tylko 2 punktów stycznych ze szkieletem liniowym.
Jeśli zaczniemy po obu stronach takiej jezdni rysować chodniki wraz z siatka chodników prostopadłych i ukośnych, to tworzymy po 5-10 mikroskrzyżowań a każde z nich ma 4 węzły z liniami.Takie skrzyżowania na chodnikach szerokich na 2 metry mają zatem 4 m2 czyli prawie tysiąc razy zmniejszą niż poligon jezdni. Czyli sztucznie dodaliśmy sobie 10 skrzyżowań do walidacji. Na to nakładamy drogi serwisowe jako podjazdy np. co 20-30 m, czyli siekamy jezdnię na 20 poligonów jeśli mamy 20 domów.
Wycięcie z a a:h=residential długiego na 200 m, 10 skrzyżowań z podjazdami o wymiarach zbliżonych do prostokąta np 13x15 m powoduje że a:h=residential kurczy się z 200 m do 50 m i to w kolejnych 10 odcinkach. Czyli z jednego a:h robi nam sie 10-20 poligonów chodnikowych i 10-20 poligonów na jezdni. Syzyfowa żmudna robota wymuszająca kontrolę nad 100 punktami przecięć.Walidacji ciągłej nie mamy toteż co godzinę łapiemy się że nie wszystkie błędy skasowaliśmy.
Robimy coś co spowalnia pracę i być może żadnemu programowi do niczego nie będzie potrzebne.
To poważny błąd, bo ilość błędów zniechęca do mapowania, szczególnie, że może paść zarzut o niechlujności.
Z rozmowy z Markiem wynikało, że nie należy się przejmować walidowaniem chodników i podjazdów. Chciałbym to zweryfikować na forum aby nie dochodziło do kłótni, szczególnie gdy ktoś do wyczyszczonego walidadorem obszaru domaluje kolejne chodniki czy podjazdy.
Czyli albo upraszamy specyfikację, albo też ustalamy zasadę zgrubnego mapowania aby choć rendering zmierzał ku kompletności co wymaga poprawienia walidadora.
Tak jak jest nie da się mapować,tzn. można ale na małą skalę.
“Wiele elementów zostało wprowadzonych bez podania powodów.”
→ Jakich konkretnie?
“area:higway złamało ważną zasadę na OSM, przechodzenia od mapowania zgrubnego do dokładnego. Jest zbyt szczegółowe i to je prawdopodobnie zabije poprzez zniechęcanie pracochłonnością.”
→ Takiej zasady nie ma. Już wcześniej mieliśmy micromapping.
Popatrz na Ełk http://www.openstreetmap.org/#map=19/53.82751/22.35143 lub Poznań.
Koledzy którzy to mapują, skoncentrowali się na swoim własnym podwórku mapując bardzo szczegółowo.
"Walidador tworzy tęczę koncentrując się na trzeciorzędnych błędach. "
→ Tak, to prawda. Wg. mnie powinien zaznaczać następujące błędy:
1. Wewnątrz area:highway nie ma drogi
2. Obwód jest niedomknięty lub zawiera podwójne punkty
3. Droga nie ma punktu wspólnego z obszarem.
“Powinien być najpierw plik po ludzku wyjaśniający ideę tak aby nawet nowy maper zrozumiał czemu ma to służyć na podstawie najprostszych przykładów, a stamtąd linkować do wersji dla zaawansowanych.”
→ Dobra myśl, wprowadzam do wiki linki do przykładów. Tutaj standardowe skrzyzowanie: http://www.openstreetmap.org/way/361005282
“Z rozmowy z Markiem wynikało, że nie należy się przejmować walidowaniem chodników i podjazdów.”
→ Dla wielu użytkowników właśnie trasy rowerowe i chodniki są ważne. Mogą oni zawsze poprawić bądź uzupełnić mapę.
“Czyli albo upraszamy specyfikację, albo też ustalamy zasadę zgrubnego mapowania”.
→ Jak najbardziej! Osobiście staram się rysować w pierwszej kolejności bardzo skomplikowane skrzyżowania i to bym proponował zrobić w skali całego kraju. Mam na myśli skrzyżowania primary road, bo motorway paradkosalnie są bardziej bezpieczne.
O konkretach nikt nie dyskutował tak jakby uznawano, że zostało to przedyskutowane na forum niemieckim czy rosyjskim.Teraz też nie chcę o tym mówić dopóki nie uzyskam informacji na podstawowe pytania.
Chodzi o to, że jeśli coś jest dodane do specyfikacji to powinno być podane po co to, a nie tylko że da się i wnosi nową jakość więc robimy a może się niebawem przyda.
Praktycznie do każdego tagu i każdego sposobu można zadać pytanie.
Np. skoro są skrzyzowania, które nie wiadomo czemu służą, to po co wprowadzono skrzyżowania typu Y itd. Po co a:h przyjmuje value z linii skoro to może sobie zrobić program? W efekcie trzeba było stworzyć dziwną hierarchię, że np. cycleway jest ważniejsza od foofway a pedestrian to nawet nie pamiętam gdzie.
Ależ jest.Można dla każdego obiektu nadać tag ogólny i nie będzie to błędem do czasu aż ktoś uszczegółowi.
Przykładowo building=yes dla kaplicy czy highway=road dla drogi
Spróbuj zmapować a:h=yes aby walidador nie krzyczał. Spróbuj wrysować poligony bez połączenia ich z siatką linii.
Gdy nie połączysz linii przy rysowaniu liniowym to rendering wrysuje tak samo jak przy połączeniu.
Kiedyś przyglądałem się Ełkowi i wielu innym dobrze zmapowanym miejscom.
Nie będę teraz zaglądał tylko odniosę się do małych ojczyzn w okolicy województw jakie mapuję.
W OSM jest piękne, że jedni dziubią swoją wioskę czy miasteczko, a inni robią mapę aby służyła do tego do czego mapa ma służyć.
Jedni robią plan miasta, a inni mapę.
Jedni robią coś pod swoje potrzeby a inni pod potrzeby innych (i swoje).
Nie było tu nigdy dyskusji do czego służy mapa i w jakiej kolejności dodawać obiekty aby mapa w drodze nie zawiodła.
W skrócie mapa musi pokazywać bariery i musi podpowiadać najlepszą drogę. Powinna też pokazywać to co bez mapy byśmy przegapili a potem żałowali, że polegaliśmy na drogowskazach lub navi, a nie zaglądaliśmy do mapy. Nie pora tu na te dyskusje ale można posumować, że ci co krytykują OSM wiedza, że ona nie zasługuje jeszcze na miano mapy i odsyłanie ich do obszaru dobrze zmapowanego tej oceny nie zmieni. OSM wypełnia wiele funkcji a funkcja mapowa jest na szarym końcu z wielu powodów np. z powodu kiepskiego renderingu, który albo celowo jest robiony źle, albo ktoś nie wie do czego służy mapa i jak połączyć kilka funkcji OSM w całość aby nie było, że “co jest do wszystkiego to jest do niczego”.
Dam taki przykład, że za głowę się złapałem gdy zobaczyłem, że jedni maperzy mapują rowy i potoki czyli bariery a ktoś akurat te elementy pomijał w mapowaniu a skupił się na mapowaniu trawy na rowach. Mogę podać wiele przykładów zabawy w kolorki z pominięciem mapowania najistotniejszych obiektów. Nie zmienia to faktu, że większość mapuje najpierw obiekty istotne i duże, a potem duperelki lub odkłada je na później.
Ponieważ podkłady i źródła mamy coraz lepsze, to zasadą OSM było dopasowanie precyzji mapowania do jakości podkładu i ilości braków na mapie.
Czyli najpierw wrysowano drogi po łebkach, a potem je przesuwano i zagęszczano nody oraz nadawano kategorie, refy, szlaki itd
Nie można rysować kawałka drogi skupiając się aby na tym kawałku były wszelkie możliwe tagi a pozostawiając większość drogi innym.
Nie można rysować stawów o średnicy 20 m a zostawić obok zbiorniki o średnicy ponad 200 m. Jest jakaś kolejność pracy wynikająca z faktu, że nie da się w rok wszystkiego zmapować więc mapuje się np. zgrubnie kompleks leśny, główne drogi itd. Nie będę oceniał dlaczego ktoś siedzący na OSM kilka lat robił dokładnie pół gminy rysując np. płoty między willami a olał resztę np. drogi, rzeczki.
Czyli w jednej wiosce ławki a dwie wioski dalej nawet nie ma obrysu miejscowości, kościoła, pałacu czy zamku.Nie można dokładnie przenieść tych preferencji na a:h, ale mógłbym wskazać wiele działań pod zamalowanie wszystkiego, zamiast wrysować powierzchnie jezdni. Przykładowo stoi słupek na środku skrzyżowania i w tagowaniu liniowym jest to mini rondo a a:h tego nie uwzględnia jakby bariery nie było. Natomiast w specyfikacji są duże ronda i już zagwozdka czy można taki pierścień wrysować za pomocą łatek czy musi to być multipoligon. Czyli czy robimy pod render, czy pod jakiś program, który nie wiadomo jak ma się zachować przy rozmaitych value dla a:h.
Czyli jeśli nie wiemy, który program co ma robić, to nie wiejmy czy rysować ciągłą jezdnię czy też co 10-20 m robić skrzyzowania z podjazdami. Zasada na OSM była taka, że rysujemy jezdnie główne a po czasie dodajemy podjazdy.Tymczasem odpalenie walidadorów zmienia styl mapowania, bo już zwykłe zebry pobudzają walidatory.
Nie wiadomo czy zebry powinny wchodzić w obręb skrzyzowania czy nie, ale to efekt tego, że rzucamy się na wszystko zamiast zacząć od rzeczy najwiekszych i najważniejszych.
Przykładowo tagujemy przejazdy rowerowe pod render wizualizacji marimila, zamiast ustalić raz na zawsze jakich tagów używać aby obecny render liniowy i przyszły dla a:h rozpoznawał je jednoznacznie.
Albo ludzie malują w a:h a nie rozdzielają separowanych dróg rowerowych na dwie nitki. Jest to zaburzenie hierarchii danych i kolejności pracy.
Podajesz, że na wiki są linki do przykładowych miejscowości.
Tymczasem jak tam zaglądam to a:h (skrzyzowanie) jest raz jako multipoligon a raz jako łaty.To ogromny dyskomfort przyjąć sposób szybszy i generujący mniej błędów walidadora (np. łaty) a potem aby się okazało, że wszystko do poprawki.
Albo zrobisz pół miasta a potem inni zamiast zrobić drugie pół przerabiają jeden sposób mapowania na drugi choć nie wiadomo czemu to ma służyć.
Jeśli a:h ma służyć nie tylko do zamalowania białych plam a np. do navi. to walidować należy jezdnie wyłączając walidowanie chodników co może przyśpieszyć mapowanie nawet 5 krotnie
Ale jak chcę szybko wymalować 100 km drogi to muszę ciągle wracać do tęczowego walidadora, bo ktoś podrysowywał chodniki lub podjazdy kompletnie nie zwaracajac uwagi na a:h do czego miał prawo.
Ustalmy co to jest zgrubne mapownie w a:h, aby nie było zarzutu o niechlujstwo i aby wyglądało to na zasadę najpierw mapuję duże obiekty i ważne np. dla renderingu, a na drobiazgi przyjedzie czas.
Nie można zachęcać do rysowana a:h z pominięciem wysepek po potem tego nikt nie wyłapie, ale można olać podjazdy i chodniki tylko co z walidadorem?
Być może można olać zebry, bo to można wyłapać wzrokiem i dodać później.
Podałem niedawno konflikt pomijania wysepek azylowych przy rysowaniu jezdni jedną linią, bo to się bardzo gryzie z a:h.
Zanim się zacznie rysować w a:h trzeba zrozumieć sens, czyli co robimy i dla kogo, oraz w jakim tempie i jak spójnie np. koncentrując się na małym obszarze.
Wygląda, że nie wiemy do czego a:h będzie słuzyć w navi, więc nie wymyślajmy co jest niby nieodzowne.Wiemy, że zależy nam mieć dużo a:h aby render się tym zajął.
To róbmy pod render, bo to kilka razy szybciej niż pod navi, a jak render ruszy to potem będzie z górki i ustali się co jest przydatne a co nie.
Na dziś przy tak ustawionym walidadorze i przy braku omówienia specyfikacji musiałbym poświecić 5-10 miesięcy na swoje miasto a tyle samo zabierze mi zrobienie całego miasta w 3D czy wrysowaniu wszystkich budynków w 4 województwach, lub wrysowanie wszystkich szlaków turystycznych.
Mi tam nie przeszkadza render liniowy więc muszę poznać powód, dla którego poświecę 500-1000 godzin na a:h.
Takim powodem jest np. to, że render liniowy przy dzisiejszym tagowaniu nie da rady wyświetlić pasów rowerowych w jezdni.
To jest istotne, a nie jakieś zatoczki dla taxi czy busów.
Tymczasem specyfikacja a:h nawet się nie zająknie jak pogodzić a:h z obecnym tagowaniem pasów rowerowych.
Ponieważ ten post jest długi powiem tylko, że będzie trudno a należałoby zacząć od specjalnego tagu dla a:h dotyczącego pasów rowerowych aby zakneblował walidadory, bo dziś mapuje się pod render rysując na jezdni cycleay co jest oczywiście złe.
Czyli to co miałoby największy sens w a:h jest pomijane milczeniem, a przejazdy rowerowe czyli realne cycleway mają złe szablony tagowania co skłoniło marimila do wizualizowania tagu bicycle=yes na ścieżce rowerowej (sic).
Ponieważ nie śledzę niemieckiego wątku nie wiem co ludzi poza kolorkami tak w a:h pociąga. Wydaje mi się, że Ty jako protoplasta i wizjoner powinieneś napisać coś w formie prologu do książki.
Bez szczegółów technicznych powinieneś napisać po co a:h zostało wymyślone i że nie jest tylko złodziejem czasu. Te wszystkie szkieletowe przykłady na wiki np. te z punktem K1 tylko zniechęcają do a:h, bo sugerują, że to sztuka dla sztuki czyli pomysł dla tych, którzy nie wiedzą co mapować.
Powtarzam, ani OSM ani nikt inny nie umie renderować dróg rowerowych, a te po 30 latach będą już prawie zawsze wyznaczane na jezdniach. Być może ten argument będzie koronnym aby render a:h wprowadzić.
Popieram - na tym etapie moim zdaniem ważne już jest, żeby było widać czy projekt ma szersze poparcie, czy nie. Niby na końcu zawsze przemawia kod, ale ten kod może zostać zaakceptowany lub odrzucony.
Nie chodzi o klakę, tylko o odnoszenie się i uwagi różne, także krytyczne, które mogą pomóc wypracować sensowny styl wyświetlania.
Marek wrzucił na Githuba moje projekty na rozwiązanie zasłaniania przy mostach i tunelach rzeczy z niższego poziomu, więc wrzucę je też tutaj
W granicach obrysu mostu (linia ciągła)/ tunelu (linia przerywana) rzeczy położone wyżej są nałożone z 50% przezroczystością dzięki czemu widać też rzeczy z dołu, problemem jest to że przyklepano prowizoryczne obszary man_made=bridge (co jest fuszerką, bo na most składają się konkretne elementy - drogi, chodniki, wysepki, itd., nie ma czegoś takiego jak pusty most bez konkretnego przeznaczenia) więc nawet jeśli zrobić 50% obszar man_made=bridge to po dodaniu kolejnych 50% elementów mostu rzeczy z dołu znowu staną się niewidoczne; na wizualizacjach nie uwzględniłem a:h żeby bardziej się to odnosiło do stanu aktualnego
Nie rozumiem tego zdania o fuszerce z man_made=bridge. Według mnie jest po prostu budowla transportowa, ani mniej ani bardziej fuszerka niż building=yes (budynek też ma jakieś przeznaczenie).
Przeczytaj moż jednak stronkę wiki:
Dotychczasowy sposób renderingu ulic.
Ulice są reprezentowane jedynie przez linie łamane. (osie środkowe ulicy).
Argumenty przemawiające za takim podejściem:
- Szybki rendering, bardzo dobrze generalizujący wygląd mapy na niższych stopniach zoomu.
Argumenty przemawiające przeciw takiemu podejściu:
- Przestrzeń drogi nie daje się prawidłowo odwzorować jako powierzchnia.
- Zasady renderowania mogą tylko przypuszczać jakie szerokości przyjąc dla generalizowania ulicy width=, lanes=.
- Muszą zostać przyjęte uogólnienia dot. szerokości ulic, te same dla całego świata. Zaawansowane tagowanie z użyciem szerokości ulicy oraz tagu placement=*jest skomplikowane dla początkujących.
- Błędy wynikające z generalizacji szerokości rażą po renderingu tam, gdzie mamy skomplikowane, duże skrzyżowania i dużą ilość pasów.
- Rendering w 19-tym stopniu powiększenia jest niezadowalający. Coraz więcej użytkowników stosuje już mapowanie bardzo szczegółowe. Jednym wyjątkiem nie przedstawianm szczegółowo, są osie ulic.
** Powody stosowania “zasady hydraulika”**
- Dokładniejsza nawigacja dla pieszych i rowerzystów.
- Bardziej szczegółowe mapy: nawigacja z widokiem rzeczywistym skrzyżowań.
- Ulepszanie modeli terenu w 3D z wykorzystaniem skrzyżowań: Obszary te są zazwyczaj płaskie i poziome. Fakt ten może być użyty do bardziej realistycznej wizualizacji 3D.
- Ulepsza wiadomości głosowe dla systemów nawigacji: Obszary skrzyżowań redukują liczbę komunikatów głosowych!
- Kontury ulic są wykorzystywane przez pojazdy jeżdżące autonomicznie.
W przyszłości: szybszy rendering 3D. Dzielenie ogromnych elementów obszary na mniejsze segmenty = mniej dużych elementów w cache = szybsza wizualizacja aplikacji 3D w czasie rzeczywistym.
Kocio,
rozumiem stwierdzenie Tomka w tym sensie, że nie pokazujemy, nie renderujemy na mapie szczegółów dot. mostów, tak jak Tomek pisze; wysepki, drogi, chodniki.