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ć.