Witam,
Jestem nowym użytkownikiem. Postanowiłem wykonać mapę miejscowości z której pochodzę, dla której prócz dróg, wszystkich punktów adresowych i kilku budynków nic nie istniało. Na początek spróbowałem nanieść kilka poprawek odnoście już istniejących elementów, za pomocą przeglądarki. Wyszło OK. Zachęcony opiniami innych użytkowników, postanowiłem użyć programu JOSM. Podobnie, ponieważ pierwszy edytowałem raz - wysłałem tylko kilka poprawek. Niestety powstały pewne błędy które nie są widoczne ani w programie JOSM, ani po uruchomieniu trybu edycji w przeglądarce - wtedy wszystko jest OK. Tutaj przykład: https://www.openstreetmap.org/#map=18/50.01852/22.39224. Jak widać odcinki dróg się rozjeżdżają (być może są to miejsca w których dodawałem nowe punkty), droga gruntowa nie łączy się z nadrzędną, kościół jest zwykłym prostokątem a powinien mieć występ od południa. Gdy zmniejszyć powiększenie, wszytko jest w porządku ale pojawiają się błędy w innych miejscach. Jako podkładu użyłem zdjęć lotniczych Geoportalu.
Zmienione dane są w bazie od razu. Ale widoczne na mapie kafelki odświeżają się z tej bazy z jakimś opóźnieniem. Zwykle niewielkim, odświeżysz po paru minutach i będzie widać(*), ale czasem zajmuje im to więcej czasu, zdarza się i więcej niż doba.
(*) Dla każdego poziomu przybliżenia są osobne kafelki, więc może być tak, że odświeżysz i będzie ładnie, oddalisz - a tam już nieładnie. Bo kafelki dla mniejszego przybliżenia jeśzcże się nie odświeżyły.
Jedyne co mi się nasuwa po obejrzeniu mapy (nie patrzyłem na podkład). Na drodze do cmentarza narysowałeś drogę na drodze. To błąd. Przerwij starą i zmień tagowanie odcinka który prowadzi do parkingu.
Dziękuję za odpowiedź. Co do dróg: to nie błąd, tak jest w rzeczywistości: asfaltowa droga prowadząca do nowej części cmentarza i parkingu oraz równoległa droga “polna” odchodząca od nowszej w pewnej odległości, prowadząca przez cmentarz i dalej w pola. Co więcej, drogi są na rożnych poziomach. Droga polna jest położona niżej, w coraz głębszym wąwozie, tak że na cmentarzu ma on głębokość ok 2 metrów. Nie można z jednej drogi przejechać na drugą, poza miejscem połączenia (które widać przy dużym powiększeniu mapy).
Tu mam pytanie czy wąwozy powinno się oznaczać? Moim zdaniem tak, tym bardziej że to coś czego nie widać dobrze nawet na zdjęciach lotniczych. Ale jak sprawdziłem okolice Kazimierza Dolnego, to tam nie są oznaczane.
Mam jeszcze pytanie odnoście adresów. Pewne domy w miejscowości którą staram się edytować nie miały adresów (importowanych prze kogoś wcześniej). Adresów nie ma tez na Wizualizacji BDOT 10K, na stronach Geoportalu. Tam te budynki są oznaczone na szaro jako budynki gospodarcze, a to błąd. Domy co prawda nie są zamieszkane, ale mają swoje adresy. Brakujące adresy wpisałem ręcznie w edytorze przeglądarki. Niestety z jakiś powodów przy ręcznym wpisaniu adresu nie działa wyszukiwanie tych adresów na głównej stronie Openstreetmap. W przypadku importowanych działa prawidłowo. Dlaczego?
Ostatnie pytanie. Używając programu JOSM próbowałem jako podkład ustawić wspominaną Wizualizacji BDOT 10K. Niestety program informuję o niezgodności odwzorowania kartograficznego. Mam ustawione takie jakie jest prawidłowe dla ortfotomapy tj. PUWG EPSG:2180. Co może być nie tak?
Przepraszam. Oczywiście. Na tym fragmencie: https://www.openstreetmap.org/#map=19/50.01758/22.40148 dom nr 27 i 130. Po wpisaniu w wyszukiwarkę “Ostrów 27, Gać” lub “Ostrów 27, przeworskie” (pierwsza wersja zawiera nazwę gminy, druga powiatu), prawidłowo znajduje miejscowość, ale nic po za tym. Po wpisaniu adresów innych budynków, prawidłowo wskazuje ten budynek.
Mam mały problem z overpassem.
Chcę znaleźć zmiany w pewnych elementach w jakimś przedziale czasu, kwerenda wygląda tak: http://overpass-turbo.eu/s/kmm
Jeżeli w kwerendzie nie ma [diff:‘xxx’] to wszystko działa tak jak powinno. W wynikach dostaję informacje zarówno o drogach jak i listę węzłów wchodzących w skład dróg.
Jeżeli w kwerendzie jest [diff:‘xxx’], to dostaję listę zmienionych dróg, ale (tylko w przypadku niektórych dróg) już bez węzłów które się na nie składają.
Pod linkiem wyżej jest widok na element który się tak zachowuje - konkretnie: http://www.openstreetmap.org/way/35066752
Bug, czy czegoś nie rozumiem? Czemu wynikiem operacji >; dla istniejącej drogi jest pusty zbiór?
Dzięki maraf, faktycznie
Czyli to znaczy że węzły składające się na linie też są filtrowane przez diff? W sumie by to pasowało, teraz rozumiem czemu po wyrysowaniu tych danych niektóre linie miały prawidłowy początek i koniec, ale brakowało węzłów w środku. Czyli żeby dostać pełne dane trzeba pobrać listę węzłów np. z OSM API. Trochę słabo w sumie.
Jak dla mnie to JEST bug, a raczej błąd projektowy.
Rozumiem, że najpierw wykonuje się zapytanie, z rekursją itd, a na koniec jest filtrowanie po dacie i rozumiem mechanizm (a przynajmniej tak mi się wydaje). Ale powinna istnieć możliwość dalszej obróbki danych przefiltrowanych po czasie, nieograniczonej już filtrem na czas.
rmikke, też tak uważam. Próbuję zrobić małe narzędzie do monitorowania lokalnych zmian. Myślałem, że poprzez overpassa z delikatną pomocą OSM API będzie łatwiej niż przez minute/hour diffy, szczególnie że nie chodziło mi o monitorowanie na żywo. Aktualizacja 1-2 razy na dobę była by wystarczająca. Ale teraz wychodzi na to, że przez overpassa mogę wyciągnąć listę zmodyfikowanych linii, ale bez ich węzłów, więc muszę odpytać OSM API o pełne dane wszystkich linii. Jeżeli linia była usunięta, to musiałbym zapytać OSM API o historię linii, wziąć ostatnią wersję, a potem odpytać o historię wszystkich węzłów składających się na tą linię, i wziąć ich wersje sprzed usunięcia… Z prostego zapytania overpassa robi się dużo niepotrzebnego odpytywania
No ale trudno… Może naskrobię coś w tej sprawie w weekend.
adas, samego w sobie chyba nie bardzo do tego co chcę stworzyć, ale mnie naprowadziłeś - dzięki! Zajrzałem w kod, na wiki, okazało się że korzystają z augmented_diffs z overpass API, więc w sumie niby z tego samego z czego ja próbowałem korzystać.
To API poza zwracaniem takiego augmented minute-diffu potrafi też pokazać zapytanie overpassa, które tworzy tego adiffa - np: http://overpass-api.de/api/augmented_diff?id=2218136&debug=yes
No i ewidentnie używają adiffa, tak samo jak ja…
…ale wyjście jest w formacie XML OSM. A ja próbowałem to od razu zrzucić do JSONa. Po drodze gubiło informacje o wcześniejszym stanie obiektu i jego nody sprzed np. usunięcia. Wystarczyło wywalić [out:json] i wszystko śmiga.
Czy takie restrykcje są zrozumiałe dla routingu? http://www.openstreetmap.org/way/185988006#map=19/51.09464/16.97931
Na jednojezdniówce jest sens i ciekawi mnie czy ktoś to wykorzystał w nawigacjach na dwujezdniówce.
Jeśli routingi to rozumieją jako zakaz skrętu na 2 razy w pierwszą w jaką się da, to jak sobie radzą kiedy są wymalowane na krzyż pasy do skrętu?
Niestety o ile dla nas ludzi rozumiejących kontekst tego tagu ma to sens, to założę się że żaden silnik do routingu nie zrozumie o co chodzi. Aż zacytuje drugie zdanie z “The Zen of Python” - Explicit is better than implicit.
Ustalono że tag restriction odnosi się tylko do relacji oraz że zawiera obowiązkowo 3 typy elementów. W tym przypadku nie ma ani jednego ani drugiego, więc nie ma mowy o respektowaniu tego typu oznaczenia.
Czyli albo można wyrzucić wszystkie nawigacje albo należy tworzyć relacje zakazu skrętu from/via/ to, nie jako dwie way+node ale może jako via wstawiać środkową drogę (łącznik dwóch równoległych jezdni)?
Jako element via można wstawić jeden węzeł lub teoretycznie nieskończoną liczbę linii. Chociaż przyznaję że chyba nie wszystkie nawigacje obsługują wiele elementów via.
Co do wyrzucania nawigacji, to każdy może (posiadając odpowiednią wiedzę) napisać nawigację która będzie respektowała dowolny zestaw reguł. Jednakże powyższy sposób, nie tylko jest unormowany przez naszą społeczność i od dawna praktykowany, jest to także najlepszy sposób patrząc od strony programistycznej. Nie trzeba wymyślać algorytmów sprawdzających która z następnych uliczek to ta o którą chodzi. Jest o wiele prościej gdy wiesz które dokładnie elementy są Ci potrzebne.
