area:highway

Zgoda, ale to zależy od rozmiarów. Wąskie paski dzielące pasy na drogach szybkiego ruchu to dla mnie z pewnością traffic island. Zwłaszcza, jeśli są na nich barierki lub inne elementy redukujące skutki zderzenia.

Jest jeszcze jeden aspekt.
W większości kraju mamy u nas porządek i takie wysepki są lekko podniesione, posiadają krawężnik przede wszystkim. W tym sensie oprócz bycia trawnikiem są również wysepką.

Jeśli pojechać np do Indii, to zdarzają się obszary między pasami ruchu, na które możne spokojnie wjechać. Driga jako taka to nieutwardzona powierzchnia i koleiny. nie ma powiedziane gdzie taka droga się kończy. W pewnych miejscach jest trawa i tyle.

Stosująć landuse=grass oraz a:h=traffic_island jesteśmy po prostu bardziej precyzyjni.

dobrze, rozumiem, ale mam nadzieję, że nie będzie ścigania osób które będą ograniczać się do landuse=grass? :wink:

i prosiłbym jeszcze o odpowiedź na pytanie czy bez Marmilla dałoby radę dodać do tabeli a:h na wiki wzory renderowania poszczególnych elementów?

Jasne że nie :slight_smile:
Łączy nas wspólna pasja, robimy razem coś dobrego. Te dyskusje są tylko po to, jak zrobić coś najlepiej. A w różniczch zdań nie ma nic złego, te dyskusje popierają projekt do przodu.
Jestem np. zdania że Twój pomysł dot. tuneli i nie tylko, powinien zostać uwzględniony w przyszłym renderingu.
A im więcej w tym celu zmapujemy, tym większa będzie siła naszych argumentów.

Co do pracy wykonanej przez Marimila: niestety nie mamy na dzisiaj takiej możliwości.
Można by się spytać kolegów z Francji którzy robią coś podobnego, albo postarać się dotrzeć do kodu źródłowego i poszukać kogoś, kto by to u nas w kraju kontynuował…

Można by spytać bezpośrednio Andy Allana czy by się tego nie podjął:

http://www.thunderforest.com/

http://www.thunderforest.com/about/

a:h jest dyskutowane zdaje się mocno na zagranicznych forach. Zrobiłem wiele a:h po czym zająłem się dziedzinami, które leżały.
Wiele w specyfikacji a:h mi się nie podobało więc czekałem aż się to przegryzie.
Nie wiem czy to jest ten czas aby przypomnieć zasady, jak i podać co w końcu się przebiło.
Jeśli nie teraz to trzeba to będzie zrobić w przyszłości, albowiem obecne tempo nie tylko nie nastraja optymistycznie ale i każe się zastawiać nad sensem.

Zasadą na OSM jest mapowanie zgrubne oraz najważniejszych obiektów, aby z czasem gdy pewne dane zaczynają być użyteczne dodać do nich bardziej szczegółowe i bardziej dokładnie wrysowane.
Tu idea a:h kłoci się z tą główna zasadą OS<, albowiem tam gdzie zdjęcia są dokładne należy rysować to dokładnie i wszystko, a tam gdzie zdjęcia są kiepskie to idea a:h wymusza gęstość node około 10 razy większą, co oznacza syzyfową pracę gdy wiadomo, że 90% node trzeba będzie przesunąć gdy podkład będzie lepszy.
Dokładność a:h zdradza też miejsca gdzie dobre zdjęcia orto dostają z czasem nową kalibrację. Tu dylemat czy powtarzać taki ogrom pracy czy robić a:h w nowym miejscu.

Pytanie brzmi czy jeśli te pozostałe 10% obiektów “liniowych” i innych pamiętających binga, czeka na usunięcie błędów kalibracji binga, które są kilkakrotnie większe niż błędy na a:h, to czy nadszedł czas na mapowanie powierzchniowe.
Jeśli brakuje ludziom czasu na wyrównanie obiektów wrysowanych kilka lat tem , to jak można liczyć na porządek i systematyczne zwiększanie ilości danych a:h, jeśli ten sposób mapowania spowalnia mapawanie rejonu 10x?

Zatem uznałem, że popełniono spory błąd nie dokonując szacunku czasu pracy i efektów.
Wyjściem z pata byłoby uproszenie specyfikacji do rzeczy najważniejszych i uciszenie walidatorów aby nie zajmowały się duperelami.
Marek pisał mi kiedyś, że wiele rzeczy już nie jest istotnych, ale tematu nie drążyłem i nie do końca uwierzyłem w tę poprawę, sądząc, że może wtedy nie wszystkie bariery wskazałem lub nie byłem zrozumiany, bo nie pisałem szczegółowo.
Teraz nie wymienię ich, bo wiele już z a:h zapomniałem ale zanim wrócę do a:h to te wątpliwości będą musiały być rozwiązane, bo nawet jeśli inni tych barier nie zauważają bo np mniej się angażowali w a:h, to pozostanę przy zdaniu, że rzuciliśmy się na zbyt głęboką wodę czyli tracimy czas na rzeczy drugorzędne, co źle wróży dla kontynuacji idei a:h.
Mówiąc inaczej te 65.000 a:h to jest kropelka w morzu potrzeb a bez efektów pracy nie ma mobilizacji.
Nawet jeśli będzie dobra wizualizacja, to na dziś nie wierzę, że może to dodać mocy przerobowych, bo ich po prostu nie mamy, a z każdym rokiem pracochłonność osm się zwiększa.

Nie chodzi tylko o zapał ale mamy złe narzędzia. Przykładowo “nadgorliwcy” a:h mapowali chodniki przyklejając je do budynków. parkingów, trawników mimo że te już wrysowane obiekty nie miały właściwej geolokalizacji.
Pisaliśmy już o tym jak łatwo poprawia się "złą lokalizację " obiektów liniowych czy poligonów nie łączących się z sąsiadami, a jak pracochłonne jest odklejanie poligonów od dróg czy między sobą, aby wcisnąć tam drobniejsze obiekty pominięte przy mapowaniu zgrubnym.

Takim przykładem jest tracer, który służy do wrysowywania i przestawiania budynków. Ideą jego jest przyśpieszanie pracy i potrafi on po jednym kliknięciu odkleić poligon budynku i przestawić go we właściwe miejsce.
Czyli zamiast klikać w 4-6 nodów aby je przesunąć można to zrobić kilka razy szybciej .
Na szczecie mało jest trawników i parkingów sklejonych z budynkami. Używanie tracera w takich wypadkach powoduje że obrysy budynku i trawnika się przecinają co podważa sens używania tej wtyczki. Natomiast tam gdzie ktoś robi a:h idzie kwartał za kwartałem i skleja je z budynkami.Dotyczy to głównie starej zabudowy czyli centrów (a tam się rysuje a:h) gdzie trawniki nie separują chodników od elewacji. Czyli takie wrysowanie a:h złączonych z budynkami zniechęca do poprawiania krzywych budynków i najprawdopodobniej będzie wymagało przesuwania a:h gdy będzie wiadomo do czego one będą służyć.

No i tu pytanie do czego te a:h, bo od tego zależy jakie obszary a:h będziemy mapować.
Na razie do niczego, bo jest ich za mało. Według mnie jest ich mało bo zastanawiamy się nad wieloma kwestiami np. czy wystarczy trawnik czy podbijamy go wysepką.
Mapowanie w a:h chodników i wyjazdów z posesji rozwala sens mapowania jezdni.
Mamy wierzyć że render wkrótce wykorzysta a:h skoro nie ma pomysłu na aplikację, a tymczasem render liniowy czeka 13 lat na dogonienie map papierowych.
Nawet obiekty drogowe (OSM to mapa drogowa) jak pasy rowerowe w jezdni, nie mają szans na renderowanie. Szlaki turystyczne to też drogi a ich render ma dawać to co kategoryzacja dróg, albowiem szlak to optymalna trasa. Ktoś uznał, że szlaki coś na wioskach i w lasach zasłaniają, a w miastach choć szlaków mało to a:h=footway ma być ważniejsze niż przebieg szlaku?

Specyfikacja w a:h dla skrzyżowań była niezrozumiałą co do idei i co do techniki. Pogorszyło to jeszcze wprowadzenie skrzyżowań typu Y.
Szerokość jezdni to zwykle 6,5-7 m a chodników 2-6 m. Jeśli drogi (i chodniki) liniowe będą odchodzić od jezdni w prawo i w lewo co 10-20 m a węzły krzyżujących się chodników będą leżeć co kilka metrów to ilość skrzyżowań i ich powierzchnia przekroczy powierzchnię jezdni i chodników czyli podważy sens nadawania kluczowi a:h wartości skopiowanych z odcinka drogi
Czyli a:h sprawdza się dla dłuższych odcinków gdzie poligon jest wąski a długi, a nie gdy zbliżony jest do kwadratu, litery T lub Y. Żadna nawigacja tego nie obsłuży a doprowadzi to do pocięcia dróg linowych na 5-10 razy większą ilość odcinków, co też spowolni np.wyznaczanie trasy

Obrazowo problem można ukazać tak że gdy wieś łańcuchowa ma 1-2 km długości to łatwo było wrysować liniową drogę (np 30-50 nodów) i z czasem dorysować lub zrezygnować z podjazdów do 300 domów.
Rysowanie jezdni jako a:h zwiększa ilość nodów 2,5-3 razy. Wrysowywanie wysepek , SBR (Stref Bez Ruchu) może to podwoić.
Dodajemy po obu stronach chodniki co już samo w sobie potraja ilość nodów w stosunku do jezdni, a do tego dochodzą zebry ,drogi rowerowe itd.
Załóżmy, że zamiast w dzień rysujemy to w 10 dni.
Teraz co 20 m wyjazd z posesji zmusza do założenia kilku skrzyżowań. Jedno na jezdni , drugie na chodniku, trzecie na ścieżce rowerowej.

Mieliśmy w oryginale jeden nod na skrzyżowaniu podjazdu z np. primary i gdy był chodnik czy ddr to dodawaliśmy drugiego noda albo olewaliśmy.
Teraz musimy wstawić nawet kilkadziesiąt nodów na odcinku 20-30 metrów czyli co posesję.
Gdy poprawia sie kalibracja podkładu, możemy łapać obrysy budynków i przesuwać je pojedynczo co jest łatwą operacją nawet dla nowego.
Sieć a:h to posklejane wiele poligonów i wiele nodów i trudno to poprzesuwać hurtem czy po kilka.

Zatem wiedząc do czego a:h ma być wykorzystane możemy skupić się na jezdniach i placach pedestrian, aby sieć a:h szybko zespolić.

Nie bardzo widzę np. sens zastępowania chodników wrysowanych jako area=yes na a:h.

Można sobie wyobrazić ile zamieszania zrobi nowicjusz.
Ile kłopotu robi jedno zaciągniecie.
Czyszczenie walidadorem zajmuje tyle samo czasu (50/50 %) co mapowanie, a nawet może ponad 60%.
Walidador marimila odświeża się o godzinę co wobec tej ilości błędów nie jest komfortowe.
Przykładowo miesiąc sprzątania uniemożliwiał mapowanie i przez swoją “syzyfowość” wyczerpywał psychicznie. Po czym nowicjusz wymalowywał chodnik i rozwalał 20-30 kawałków a:h i już brakowało ochoty i na poprawki i na uczenie go a:h.

Nie wiem jakie są ostatnie ustalenia ale specyfikacja wymaga uproszczeń. Największe oszczędności zrobi zastosowanie innych reguł poprawności dla chodników i podjazdów, a innych do jezdni.
Należy ustalić czy skomplikowane skrzyżowanie ma być multipoligonem z wieloma inner, czy wystarczy nakładać łaty czyli oblepiać wysepki jezdniami a:h.
OSM ma być prosta, bo nowi muszą zastępować odchodzących.

Podsumowując.
Idea a:h to 10x większa pracochłonność dla starych i wielka bariera dla nowych.
Być może to nie jej czas wobec ilości białych plam.
OSM dziś odstrasza nowych skomplikowaniem, a a:h to może spotęgować.
Za mało informacji na temat możliwości i szans wykorzystania.
To co teraz napiszę nie należy brać dosłownie, bo za mało mam danych.
Wygląda to na robienie pod render czyli robienie czegoś czego inni nie mają, gdy tymczasem render OSM spóźnia się wiele lat aby uzyskać to co inni mają od dawna lub od zawsze.
Dobry strateg nakazałby odwrót aby nie skończyło się klęską. Należy zmierzyć siły i skoncentrować je tam gdzie będzie zauważalny efekt.
Wadą OSM jest to, że punktowy sukces jak to nazywam “kolorkowością” mapy, stwarza fałszywy obraz, że kompletność danych jest duża.
Kto maluje w 3D, a:h, budynki i laduse, wie jak każda z tych technik gryzie się z sąsiednimi i jak jest pracochłonna.
Wizualizacja marimila walidowała tylko kilaka miast poza Polską. To spora bariera i generowanie błędów.Teraz się okazuje, że bez niego nie można poprawić walidadora czyli trudno będzie uprościć specyfikację a:h.
To ten sam problem czyli podejmowanie pracochłonnych wyzwań zbyt małymi siłami.
Do OSM na dziś mogą przyciągnąć tylko szlaki więc cieszę się, że rozmowy z PTTK ruszyły.

a:h jest szansą dla nowych, bo znany jest syndrom rysowania po wejściu na OSM, trawniczków i chodniczków, ale to musi być proste.

@Rowers2 mylisz forum z gazetą, a nie wchodzimy tu czytać artykułów na kilka stron tylko wymieniać się pomysłami i uwagami, twoje filozofowanie zamula dyskusje, więc musisz się liczyć z tym że część osób nie będzie w ogóle tych wypracowań czytać

Ten tekst akurat przeczytałem i zrozumiałem, uwagi wydają mi się sensowne, ale nie mam jeszcze zdania na ten temat.

Na końcu jest sekcja TL;DR (od słowa “Podsumowując”), która nieco rozjaśnia.

@Tomasz_W Ależ mam świadomość że każdy z nas ma tu inne potrzeby i dlatego większość maperów ma w nosie a:h i palcem nie kiwnęła.
Ten długi tekst jest zaprezentowaniem mojego stanowiska, bo jak kiedyś sprawdzałem to najwiecej w PL a:h popełniłem więc i miałem wiele obserwacji.
Wydaje mi się że gdy marek cały czas stara się zaktywizować to w końcu i ja powinienem swoje uwagi przekazać.
Szczególnie że marek oczekuje, że ja wrócę do a:h i np. odwalę kawał roboty ale nie może to być sztuka dla sztuki, która odbędzie się kosztem zatrzymania innych prac.
Zatem jeśli mam na to poświęcić 100 czy 1000 godzin to muszę poznać sens rozwijania a:h, szczególnie gdy mój poprzedni bilans wypadł bardzo źle, bo robiliśmy na hurra.
Sądzę, że moje uwagi będą bardzo cenne dla marka, który chce aby projekt po roku odżył.
Nasze forum jest suche i większość postów dociera do ludzi z przygotowaniem informatycznym lub podpowiada tagi nowym.

Technokratyczne podejscie zaprowadziło nas w ślepą uliczkę gdzie nadzieje wiązaliśmy z wizualizacjami marimila a teraz stoimy.
To w żaden sposób nie przełożyło się na render czy na aplikacje np. tę z firmy marka.
Teraz na dodatek nic nie możemy zmienić w specyfikacji bo nie mamy jak tego zwizualizować na próbę.
Zatem nie widzę sensu toczenia kolejny rok dyskusji jak ty piszesz “polegających na wymienianiu się pomysłami i uwagami”.
Od tych pomysłów to głowa boli i renderujemy pasy parkingowe, zatoczki autobusowe, miejsca dla taxi itd.
Pomysły były wdrażane pośpieszenie co skomplikowało a raczej zrobiło bardzo pracochłonnym takie mapowanie i generowało wiele błędów. Fajnie że dawało się szybko to zwizualizować ale gdy pełniłem tych a:h wiele, mogłem jako jeden z nielicznych oszacować pracochłonność.

Czyli co się sprawdzało w małej skali np. w centrum jednego miasta czy na jednym osiedlu, nie dało się przenieść na skalę ogólnokrajową.
W tej małej skali a:h jest zupełnie nieprzydatne, bo nikt tego nie zamierza wykorzystywać.
Pragnę zwrócić uwagę, że nie tylko forum jest suche i pisze tu garstka, ale i wiele osób odchodzi od OSM bo nie realizuje ono nadziei jakie w nim maperzy pokładali. Kocio stara się rozruszać forum przekazując ciekawostki z tym, że z tego i tak głównie mogą korzystać informatycy.
Marek promował 3D i a:h, a to oznacza, że skromne siły rozbijane są na wiele frontów.
Widzę mocną specjalizację kolegów i to jedyny sposób na sukces w konkretnym temacie. Oznacza to, że coraz trudniej będzie mobilizować kolegów do jakiś akcji, bo nielicznych zaangażowanych maperów trzeba by odrywać od zajęć, które są na wysokim stopniu realizacji.
Nie możemy się też licytować, że np. Nepal jest ważniejszy od 3D itp.

Jednym sposobem na mobilizację jest pokazanie efektów, a tych brak.
Drugi sposób to zwiększanie społeczności, ale tu decyduje jakość forum.
Raz. że jest mocno ukryte, dwa że atmosfera odrzuca każdego kto tu zagląda, a trzy że nowicjusza odstrasza sucha tematyka, której nawet nie liznął, więc nie łapie o czym gadamy.

Zatem najbardziej mnie interesuje zdanie marka, bo on zna zainteresowanie zagraniczne głównie z Niemiec i Rosji. Włączyłem wizualizacje marimila błędów w a:h i widzę że niewiele a:h przybyło oraz jest bardzo dużo błędów.
Podejrzałem sobie np kawałek autostrady i widzę że pół pasa rozbiegowego ma jedną wartość (shoulder) a reszta inną. Shoulder nie ma tam związku ani ze znakami poziomymi ani z krawędzią jezdni. Jaki sens oddawania takich danych o złej geometrii?

Na wizualizacji błędów aż kolorowo mimo że mija rok od ustalenia jak to robić, a to znaczy że maperzy nie rozumieją jak to robić a innym się nie chce tego sprzątać.
Błędów jest mnogość nawet tam gdzie w a:h były mapowane tylko jezdnie. Mapowane były głównie autostrady i obwodnice gdzie mało skrzyżowań. U mnie jakiś Niemiec pousuwał linie chodników bo są a:h. To ta sama gorliwość co z usuwaniem rzek bo są riverbanki.
A:h wygenerowało tyle linii że zastanawiam się czy ten chaos nie zniechęca nowych do mapowania.
Z tego wniosek, że pisanie o technice mapowania nie nauczyło mapowania, a brak pisania ogólnie o idei, spowodował, że ludzie się zniechęcili i nawet błędów po sobie nie posprzątali.

Mnie wkurzało że gdy kilka tygodni sprzątałem po sobie i innych (do nowych ustaleń), przychodził ktoś kto dorysowywał liniowo chodnik po czym wizualizacja błędów znów mieniła się tęczą.
Unikanie dyskusji z pewnością nie zachęci do mapowania a:h. A ci co nie mapują w a:h z pewnością tego wątku nie czytają. Ja chyba pójdę w ich ślady jeśli w temacie a:h nic się nie zmieni.
Jedno jest pewne, że bez marimila jakikolwiek sposób dyskusji traci sens. Jedyne co możemy zrobić to skoncentrować się na tym co nie budzi wątpliwości zamiast komplikować specyfikację i mnożyć błędy.

Kocio stara się rozruszać forum przekazując ciekawostki z tym, że z tego i tak głównie mogą korzystać informatycy.

Cóż, robię to bo to mnie samego interesuje i po prostu tym się dzielę. Ale też prawda jest rzeczywiście taka, że przekazuję tylko to, co się dzieje, a to są głównie drobiazgi techniczne. Z wizjami jest krucho, o czym już kilka razy pisałem, a OSM rozwija się siłą rozpędu na razie. Brakuje inicjatyw odpowiadających na potrzeby zwykłych ludzi (sam bym kilka chętnie powitał). Upatruję problem w zbyt szybkim usunięciu się lidera na bok i braku następcy - ja bym to widział na razie jak demokrację typu debianowskiego, a nie obecną anarchię.

Po zastanowieniu wydaje mi się, że zasadniczo masz rację.

Większość błędów w a:h pojawia się w związku z tym iz brak jest połączeń z liniami przecinającymi a:h i junction. Osoby dodające nowe a:h zapominają o tym - tak mam w Szczecinie no i podczas uzupełniania innych danych mających jednak wpływ na nowe błędy w a:h.

Co do pasów kierunku na jezdni pokazały sie na zoom 18. Szkoda że nie widać pasów przejść przez jezdnię. Czasai wracam do a:h ale - jak to zauważono siadło bo … nie ma kto tym zarządzać; brak jakichś konkretów co do zastosowania - mi osobiście i nie śmiać mi się tu ze mnie - to wizualizacja przebiegu ulicy czy dróg dla rowerów. Jedyne miejsce to osmapa gdzie mogę część naszej pracy zobaczyć.

Ludzie potrzebują dokładnej, aktualnej, dobrze działającej mapy. Potrzebują ich w zasadzie w dwóch sytuacjach: kiedy jeżdżą samochodem do nawigacji oraz kiedy podróżują do orientacji w terenie i szukania atrakcji turystycznych. Reszta zastosowań to mniejsze i większe nisze. Maps.me załatwiło na razie problem łatwej w obsłudze, szybkiej i lepszej od google maps aplikacji OSM do nawigacji samochodowej. Obecnie potrzeba numer 1 to dobra aplikacja do turystycznych map topo. Kiedy taka aplikacja się pojawi to i jakość danych zacznie się z czasem poprawiać. Jestem optymistą. Moim zdaniem bitwa o mapy właśnie się rozstrzygnęła - i to my wygraliśmy :slight_smile:

Też tak myślę.

Uważam, że chcemy (ludzie skupieni wokół OSM) za dużo i za szybko. Nie ma co się frustrować na tak wczesnym etapie. Tak, uważam, że ten projekt jest na wczesnym etapie. W tym momencie najważniejsze jest powiększenie bazy użytkowników, z których dojdzie promil specjalistów, parę procent mapperów, procent psujów i reszta użytkowników.
Najważniejsze by zachować balans w tej całej zgrai i nie obrażać się o byle co, bo chcąc nie chcąc wszyscy muszą współdziałać.
Będzie więcej ludzi patrzących na OSM to i będzie szybciej i więcej błędów wyłapywanych. Przede wszystkim to należy tłumaczyć nowym, że są członkami społeczności i że jeśli każdy zadba o wyrysowanie swojej gminy czy dzielnicy to nie ma takiej mapy komercyjnej, która by dorównała dokładnością OSM.
A Osmand jest taki bardzo zły do szlaków i TOPO? Wydaje mi się, że jeśli już to dane w nim bywają zawodne bardziej niż sama aplikacja.

Jest masakrycznie zły. Jego interfejs jest jak z dowcipów o linuksiarskim dizajnie. Zainstalowanie poziomie i cieniowania wymaga 30 minut grzebania w menu i ściągania dodatkowych plików i wtyczek. Maps.me wykosil Osman da bo dał tylko to co potrzebne w ładnym i prostym opakowaniu. Mam cicha nadzieje ze ktoś go sforkuje i zrobi Maps.topo :slight_smile:

Otóż to. Trzeba nam przekroczyć barierę 100.000 elementów by móc cisnąć na ludzi rozwijających rendering.
Pamiętajmy że prawie nikt nie ma tak dobrej sytuacji do mapowania jak my dzięki Geoportalowi. Dlatego najwięcej a:h powstaje w Polsce. Myślę, że dobrze by było skończyć jakieś duże miasto; Szczecin lub Wrocław, tak by mieć wizytówkę do pokazywania.

No fajnie by było - ale trzeba by chyba najpierw używać jak najprostszego sposobu tworzenia a:h, jasnego jego prostego sposobu tworzenia. Błędów jest masa te trzeba poprawić, ale tez nowi musza (ja też) nauczyć się to robić poprawnie. Na podstawie własnych błędów które wytkną mi inne osoby a ja się o to nie obrażę.
Musi to też miec swoje odwzorowanie w pokazywaniu tych efektów pracy na odpowiedniej stronie. Tylko nie tak jak z obiektami 3D gdzie mamy do wyboru dwie strony ale każda nasza prace pokazuje … inaczej :frowning: i nie wiesza jak to robić by tu i tu było poprawnie. Połączyłbym strony z 3D z a:h - wtedy było by zajesuper i byłoby może to pomocne w przyciąganiu ludzi do takiego mapowania. Ja czekam na lepsze podkłady ze Szczecina bo obecne są dość już stare. Ale staram się.

zachęcam do dodania obszarów dróg w Starym Mieście w Poznaniu, od kilku miesięcy zajmuję się tym terenem i za 1-2 tyg powinienem skończyć; oprócz miejsc gdzie ze względu na remonty lub nieakutalny podkład nie mogłem dodać obszarów chodników to wszędzie indziej są zrobione dzięki czemu wystarczy tylko wzdłuż nich “doklejać” obszary dróg
http://www.openstreetmap.org/relation/1849136

tylko błagam, nie zamieniajcie obecnego standardu chodników z area=yes na a:h, rozumiem wasze argumenty, ale dopóki a:h nie jest przyjęte, a na Mapniku wyświetla się stary sposób tagowania, to jego zamienianie na proponowany standard jest niszczeniem mapy, jeśli a:h zostanie wdrożone, to i tak będzie trzeba zrobić zamianę tych tagów na całej mapie automatem, więc ręczne zmienianie tych tagów jak robili niektórzy w Poznaniu to kropla w oceanie i strata waszego czasu :slight_smile:

Ja dodaję do Twojego Taggingu który jest widoczny na obecnym Mapniku tag a:h. Dotyczy to tylko chodników.
Wiem, że są ludzie którzy wściekają się, bo tradycyjne routery mają problem z area=yes dla footway. Niemcy dają za to bana albo usuwają takie elementy, ale ja uważam, że to trochę przesada. Trzeba rozwijać mechanizmy routingu dla obszarów. Wypróbuj Tomku, jak działa OSMand dla routingu pieszego w Poznaniu tam gdzie masz zmapowane footway z area:yes. Może nie jest tak tragicznie.

D3mol3k: słusznie. Twoja uwaga: Połączyłbym strony z 3D z a:h, jak najbardziej tak. Mam nadzieję że do tego dojdzie, tak samo jak do zmodyfikowania standardu S3DB za którym robię lobbying już od dawna.

Kocio: serdeczne dzięki za lobbying dla a:h na forach! To potrzebne. W końcu się z tym przebijemy. Twórzymy dalej fakty.

Podtrzymuję swoje zdanie, to jest tagowanie pod render. Żaden soft nie ma szans ogarnąć o co chodzi. To że dużo pracy w coś włożono nie znaczy, że jest poprawna. Jak routing ma ogarnąć sytuację kiedy linia nakłada się na obszar i to w nie do końca zdefiniowany sposób? Samo area=yes nic nie mówi, bo dokładnie tak samo są otagowane właściwe place, bez osi poruszania się. Własnie dlatego powstał area:highway który zawiera także szereg reguł dotyczących łączenia z reprezentacją liniową, aby wszystko było jednoznaczne.

No właśnie to jest to, co nazywam “tagowaniem pod trasowanie”. Bo przecież nie każdy silnik sobie radzi z trasowaniem po obszarze. Ale dlaczego w ogóle mamy coś robić z danymi, skoro to nie tu leży problem?

Oś jezdni czy chodnika może i istnieje geometrycznie (w sensie da się ją wyznaczyć jakimś algorytmem, lepiej lub gorzej), można też traktować ją jako uproszczenie kształtu, ale jak mamy wyrysowany faktyczny kształt, to oś jest już wyłącznie jego starszą wersją. Tak samo jak budynek oznaczony jako punkt po wyrysowaniu jego kształtu też nie powinien zostać. A na placu dla pieszych w ogóle nie ma osi, można tylko na oko albo analizą częstości jak ludzie chodzą. To pokazuje jasno, że a:h jest prawidłowym otagowaniem, a linie już wtedy na pewno nie.

Jednak uważam, że warto uwzględniać czynnik praktyczny. Dlatego nie każde tagowanie pod wyświetlanie albo trasowanie jest dla mnie złe. Warto jednak mieć świadomość szerszego kontekstu.

Nie za bardzo rozumiem. Nie tyle nie każdy silnik routuje po obszarach, co żaden - co najwyżej po krawędzi, co tutaj tylko pogarsza sprawę. Moim zdaniem semantyka tworu “linia highway=pedestrian + obszar highway=pedestrian area=yes” jest błędna. Bez strasznie zawodnej heurystyki nie ma łatwego sposobu na odróżnienie kiedy coś jest bona-fide obszarem, a kiedy dodatkowym obrysem.

No i właśnie dlatego pragmatyczni Niemcy nie tagują highway=footway plus area=yes.

Z drugiej strony rozumiem, że ludzie chcą widzieć wyniki własnej pracy na mapie. Sam popełniłem parę highway=service z area:yes, bo chciałem to widzieć na mapie.

Bardzo to wszstko irytuje bo zamiast mieć rysowane na mapie głównej poprawne rozwiązanie, wielu mapowiczy robiących naprawdę dobrą i dokładną robotę, musi uciekać się do takiego wybiegu.

Proponuję zrobić nalot na Londyn i zmapować im parę obszarów ulic. Ciekawe do czego to doprowadzi… :wink: