area:highway

Marimilu, a co powiesz o tym: http://wiki.openstreetmap.org/wiki/Key:road_marking
Chodzi mi o rysowanie linii tak jak w tamtejszym example z Kansas.

Pozdrowienia,
Marek

To co ja myślę, to jedno. Powinno to być relatywnie proste. Strzałki w sumie też.
Pytanie, co na to pozostali. Jest trochę dziubania. :wink:

Z powierzchownych oględzin wygląda na to, że u nas tego nie ma. Gdyby ktoś zechciał zrobić jakiś mały przykład gdzieś w PL, to byłoby łatwiej coś zaprojektować.

Zabiore sie za to na dniach.

O ile można by to wykorzystać w przypadku obszarów skrzyżowań jak np. ta linia o tyle rysowanie każdej strzałeczki, kreseczki czy linii oddzielających pasy ruchu jest złym pomysłem.

Marku, mamy jakiś pomysł jak sobie radzić w przypadku gdy liczba pasów ruchu zmienia się? Bo to jest bardzo prosty przypadek dla jednego obszaru:
Jednak w przypadku gdy pojawia się nowy pas ruchu on zazwyczaj pojawia się stopniowo. Stosując tę metodę te pasy na styku obszarów po prostu się nie zejdą.

d3mol3k, coś ty tutaj odwalił? :open_mouth: http://www.openstreetmap.org/#map=19/53.42872/14.50014
I z tego co widzę, to nie jedyne skrzyżowanie na którym narobiłeś bałaganu.

Darku, to sluszna uwaga. Jedyna mozliwosc, to rysowanie jako oddzielnego a:h obszaru na ktorym nastepuje zmiana ilosci pasow. Odcinek musi zawierac informacje o zmianie ilosci pasow. teoretycznie mozna by ekstrahowac ta informacje z turn:lanes. Mam teraz tylko Internet via smartfon, na dniach dorzuce szkic do tego pomyslu.

Ja to widzę tak: nie możemy wymagać od rysujących, żeby dzielili obszary i linie w odpowiednim miejscu. Już teraz widać po rysujących, że jest wielka dowolność w interpretacji wytycznych. Druga sprawa, wprowadzanie danych w wielu przypadkach będzie niezależne - jedni będą rysować linie, inni obszary (niekoniecznie w tej kolejności). Niektóry nie będą mieli świadomości istnienia a:h.
Jakimś rozwiązaniem (nie wiem czy sensownym, nie wiem czy się da) mogłoby być dzielenie danych na poziomie tworzenia tabel pod wizualizację (linii po obszarach, obszarów po liniach).

Wrzuciłem na wiki parę szkicy, jeszcze bez komentarzy:

http://wiki.openstreetmap.org/wiki/Proposed_features/area_highway/mapping_guidelines

Co mam jeszcze uzupełnić, jakie przykłady dodać?

@marek
Jeśli chodzi o ostatni przykład…autostradowy.
Ja bym to tak zrobił: https://wiki.openstreetmap.org/wiki/File:MotorwayCrossing.jpg, tu z dodatkowym oznaczeniem gdzie idzie a:h+junction https://wiki.openstreetmap.org/wiki/File:MotorwayCrossingWJ.jpg.

Jeszcze jakieś/jakiś zrzut ekranu z wymodelowanym skrzyżowaniem i włączonymi zdjęciami satelitarnymi mocno pomogłoby nowicjuszom a:h. :slight_smile:

Masz rację. To dużo precyzyjniej.
Wymień ten obrazek na Wiki jeśli mogę Cię poprosić.
Czy ktoś z Was mógłby wspomóc stronkę wiki szkicem rozrysowującym standardowe skrzyżowanie z podziałem na pola:
a:h=emergency/footway/cycleway/traffic_island its?

Najwyraźniej a:h staje się trendy, bo nie tylko jest już ponad 26 tys. zastosowań, ale także mapka rozkładu wygląda na dość równo rozsianą po Europie (która jest ogólnie najmocniejsza w OSM) i zdobywa przyczółki w reszcie świata:

http://taginfo.openstreetmap.org/keys/area%3Ahighway#map

Myślę, że fajnie by teraz było pociągnąć to tagowanie po najważniejszych trasach komunikacyjnych (typu np. primary w dużych miastach tudzież trasy łączące np. lotniska z centrum), bo mamy już chyba najważniejsze rzeczy poustalane i można bez większego ryzyka tworzyć takie “szkieletowe” sieci zamiast osobnych “wysepek”.

Jak miał bym rysować linie na jezdni, to widział bym to raczej tak jak tu na przykładzie: https://www.openstreetmap.org/relation/5471219#map=19/52.21619/20.86622,
było by to doskonałe dopełnienie do a:h. Wydaje się że było by to lepsze rozwiązywanie niż punkty K.

Czemu właściwie nie?
Rozwiązało by to obszary dyskusyjne przynajmniej. Na długich nitkach autostrady było by to zbędne bo możliwe do rysowania generycznie.

Pytanie do Was: Musimy zdecydować, jak postępować drogami dla rowerów jako obszary, ich skrzyżowaniami, śluzami rowerowymi, drogami dla rowerów i pieszych gdzie nie ma informacji po której stronie jest droga rowerowa a gdzie piesza.

Wydaje się lepsze jeśli bierze się tylko pod uwagę rendering a:h, ogólnie rzecz biorąc jest gorszym rozwiązaniem. Należy pamiętać, że OpenStreetMap nie jest projektem graficznym, tylko kartograficznym. Celem nadrzędnym jest użyteczność danych dla różnych zastosowań, a nie próba graficznego odwzorowania ortofotomapy.
Punkty K są bardzo dobrym rozwiązaniem, ponieważ wykorzystują już istniejące punkty sygnalizacji świetlnej, linii stop lub ustąp pierwszeństwa. Te punkty są wykorzystywane w nawigacjach np. do szacowania czasu przejazdu, mogą również służyć do renderowania linii na jezdni.
Projekt a:h nie jest osobną gałęzią OSM, tylko jednym z elementów. Z tego powodu powinien być spójny z całym projektem i jak najwięcej czerpać z danych, które już istnieją. Nie powinno się tworzyć udziwnień specyficznych tylko dla a:h tylko po to, żeby się ładnie renderowało.

Z innej beczki - zastanawiam się, czemu do tego schematu area:highway wcisnęliście tę nieszczęsną uznaniowość, czyli klasy dróg? Mam na myśli np. area:highway=tertiary, area:highway=secondary itd… Nie można było dać po prostu area:highway=yes + ewentualnie surface=?

Wiesz Zbigniewie, większość tak chciała. Na początku miałem właśnie propozycję a:h=yes, bo wychodziłem z założenia że te dane można wyciągnąć z drogi będącej na danym obszarze.

PS: Marimilu, czy Bawaria znów się wysypała?

Ja myślę, że w a:h powinno być trzymane jak najmniej a dane pobierać z linii (klasa, nawierzchnia, itd.). Problem powraca. Darek-J, jak wygląda sprawa wyciągania danych z linii?

Jeśli będę rysował jakieś a:h to będę dawał właśnie area:highway=yes + surface. Nie widzę potrzeby klasowania obszarów, bo siatki routingu nie da się z tego zrobić.

Tylko dlaczego dałeś to na drodze bez a:h :stuck_out_tongue:

Jeśli chodzi o wyciąganie danych z linii to próbuję to jeszcze trochę zoptymalizować, bo trwałoby to zbyt długo.
Mógłbyś napisać coś więcej o tym w jaki sposób obecnie renderujesz te warstwy? Ja do przekształcenia danych xml (.osm) na bazę sql używam osm2pgsql w trybie slim (potrzebuję tabel ze strukturą logiczną linii i węzłów). Dodatkowo korzystam z typu danych hstore, czyli baza musi to rozszerzenie obsługiwać. W jakiej formie tych danych byśmy potrzebowali aby je wyświetlić?

Dobrze by było jakbym sobie skonfigurował takie samo środowisko jak na serwerze, żeby mniej było roboty z dopasowywaniem skryptów.

Zrobiłem taki w miarę prosty przykład: https://wiki.openstreetmap.org/wiki/Proposed_features/area_highway/mapping_guidelines#Simple_crossing_example. Jakby coś było nie tak, to mówcie :slight_smile:

A jeśli chodzi o używanie a:h=yes zamiast klasy drogi jestem za. Myślę, że przekonałby innych do tego Wasz udany test z sql’em ^^ :smiley: