JOSM - różne sprawy, porady

Tak, jestem w kontakcie z lokalna spolecznoscia OSM, koordynuje sie z wieksza akcja importu z LINZ - idaca bardzo wolno bo ichniejsza spolecznosc to doslownie kilka osob. Swoja droga - mapy LINZ sa tak dobre ze po prostu nie ma tam zapotrzebowania na OSM. A jednoczesnie polityka rzadowego urzedu geodezyjnego… zachwyca. Wszystkie dane podane na tacy, we wszelkich mozliwych formatach, na licencji CC BY. Mam zreszta juz oficjalne konto w LINZ Pod wzgledem prawnym etc jest wiec wszystko ok. Mam problem braku swoich kompetencji.

Bardzo mi pomogłeś, dzięki tej metodzie jestem 3 lata świetlne do przodu Dziękuję.

Domyslam sie, ze nie jestem pierwsza osoba na swiecie ktora chce zrobic import i zmerge’owac nowe ze starym wiec ponawiam prosbe o pomoc

Jakby co szukaj może szerzej tej pomocy, np. tu:

http://forum.openstreetmap.org/viewforum.php?id=54

albo na liście Talk.

Pytanie - kto ma rację? Czy import, czy użytkownik OSM? Przy imporcie adresów wysoki priorytet mają dane wprowadzone przez użytkowników, a sytuacje konfliktowe - zostawiam do rozstrzygnięcia importerowi. Generalnie - mając funkcję identyczności (obiekt w OSM == obiekt w źródle importu), jest to łatwe do zrobienia

Tu rozwiązanie jest potrzebne podobne jak w punkcie pierwszym - wystarczy funkcja identyczności, by wiedzieć, który punkt należy zaktualizować o te informacje.

Ale teraz może wrócę do części ogólnej - jak się robi importy:

1. Pisze się konwerter z formatu źródłowego do pliku *osm
2. Ładuje plik *.osm do JOSM
3. Ewentualnie - generuje poprawki
4. Upload do OSM

I to jest z grubsza, do czego pewnie masz już narzędzia

W przypadku adresów, rozwinąłem trochę to rozwiązanie bo wygląda to tak:

1. Konwerter ściąga dane źródłowe
2. Konwerter ściąga dane z OSM
3. Konwerter dokonuje porównania danych OSM ze źródłowymi, i algorytmami wyznacza, co trzeba zmienić w OSM
4. Generuje plik OSM
5. W pliku OSM są oznaczone dane, które trzeba poprawić ręcznie (poprzez tag fixme=*)
6. Osoba importująca otwiera plik *.osm w JOSM-ie
7. Osoba importująca ogarnia fixme=*
8. Upload do OSM

Niestety - na potrzeby importu danych dla NZ, trzeba by napisać (pewnie banalny) importer uwzględniający specyfikę danych, co niestety wymaga umiejętności programistycznych.

To co mi przychodzi do głowy, to że obecny importer adresów można by przepisać, by działał bezpośrednio w JOSM - jako funkcja do łączenia warstw. Gdyby algorytmy łączenia danych były jakąś tam konfiguracją (coś na kształt preset’ów), to w sumie można by to zacząć stosować ogólniej dla importów.

Są tylko dwa (wydaje mi się, że niewielkie) problemy:

1. Zwykle importy obejmują duże obszary, i trudno załadować wszystkie obiekty do pamięci (zresztą, zwykle są one nieistotne w kontekście importu)
2. Importy staną się zbyt łatwe, a podejście do importów jest jakie jest w środowisku OSM (moim zdaniem niesłusznie)

Pomysł gdzieś mi się zgrywa z tematem PTTK, czy np. importem granic (akurat ostatnio testowałem). Więc przypadków użycia widzę całkiem sporo, które można by narzędziem obsłużyć.

@Rekrutacja
Osobiście do importu używam JOSM wraz z wtyczką opendata która pozwala na bezpośrednie użycie plików *.shp (innych danych wejściowych nie używałem). Wówczas tak zaimportowaną wersję porównuję w JOSM z warstwą pobraną z overpass dla obiektów mnie interesujących (dla ciebie będzie to natural=peak). W JOSM można kopiować dane pomiędzy warstwami co jest bardzo pomocne jeśli chcesz robić to pół automatycznie importując dane po kolei dla kolejnych obszarów co pewnie i tak będzie konieczne by nie powielać danych już istniejących. Robiłem tak dla pomników przyrody na Podkarpaciu czy mezoregionów dla kraju.

Co do łączenia poszczególnych warstw przed importem by miały pełne dane (ele i name) to już wyższa szkoła jazdy z którą nie miałem do czynienia, ale podejrzewam że jeśli dane wejściowe mają identyczne współrzędne pomiędzy warstwami to pewnie da się je jakimś GISowym narzędziem czy skryptem połączyć

Też wam tak muli ostania wersja JOSMA?
Wróciłem się kilka wersji wstecz, bo nie da się pracować zarówno wtyczkami jak tracer czy tez ręcznie nie można szybko stawiać nodów.
Do tego co rusz wyskakują błędy, chyba gdy JOSM nie nadąża przyjąć nowego polecenia przed zakończeniem poprzedniego.

U mnie też najnowsza wersja strasznie muli, bardzo szybko “zapycha” się ram. Jest na to jakiś sposób?

^^ potwierdzam także

U mnie to samo, myślałem, że to przez to, że robiłem formata.

**rowers2 ** możesz powiedzieć, która ze starszych wersji nie sprawia problemów?

z uwagi na to, że czasami kopiuję pomiędzy warstwami z pliku .shp to stosuję wersję 10526 Nie wiem czy to wina samego JOSM czy też wtyczki opendata, ale kolejna wersja nie kopiuje elementów dokładnie w to miejsce gdzie wskazują współrzędne na pliku tylko gdzieś na środek ekranu na w nowej warstwie. Żadnego z wyżej wymienionych problemów na niej również nie doświadczyłem

Jadę na 10327, która dość długo była dostępna.
Nie pamiętam kiedy się zaczęły kłopoty.Przedostania wersja szybko zdaje się była zmieniona.
Oprócz 10327 mam 10526, 10786 i obecną 10966, ale wolałem się wrócić do 10327, bo pamiętałem, że stabilnie chodziła.

Cofnęła ona wtyczki do starych wersji i jedyny mankament jaki zauważyłem to chyba nie odzyskała skrótów klawiaturowych do opcji z wtyczki BuildingTools służącej do podzielenia budynku na podaną liczbę części ((Ctrl+T).
Ale ta opcja działała tylko dla idealnych prostokątów więc zawsze budynek z wykuszami (czy inny poligon) można podzielić przez Alt+X

Wersja 10327 rzadko generuje błędy ale jeszcze mi się nie zawiesiła na stałe, choć odpalam ją bez przydzielania większej pamięci. Zatem te błędy jakie czasem wyskakują maję związek z tym, że JOSM wychodzi poza przydzieloną pamięć ale zwiech trwa tylko 1-2 sekundy.
Na wszelki wypadek co jakiś czas wywalam z cache Josma z folderu Tiles największe pliki ale te z końcówka data a nie key.
Pliki te mają po kilkaset MB i nie zawsze są zerowane po wyłączeniu JOSMA.
Takie wywalenie z cache tracera czy josma po 1-1,5 GB przyśpiesza trochę JOSMa na kompie z 4BG RAMu z odpalonymi kilkudziesięcioma kartami w Firefoksie. Jednak to przyśpieszenie JOSMA nie jest idealne i zanika szybciej niż po godzinie.
Np. wrysowanie budynku tracerem zabiera ok 3 sekund ale ten czas jest też zależny od współpracy czyli negocjacji z geoportalem.

Gdy trwają prace na geoportalu to JOSM pracuje w dziwnych 3 skokach czasowych a wieczorem znacznie przyśpiesza (tak dwukrotnie). Co ciekawe nawet przeciąganie myszką podkładu orto idzie skokami co wyraźnie sugeruje brak pamięci, choć proces w jawie nie zajmuje więcej niż 500-800 MB.Nie mam pod ręką kompatybilnych pamięci aby sprawdzić jak to chodzi pod np. 6GB.
Częste błędy JOSMA mogą mieć u mnie związek ze zmianą myszki na bardziej iskrzącą.
Jednak nic nie tlumaczy, że rysowanie np stawu jest niezmiernie kłopotliwe bo gdy się chce wrysować szybko to linia jest porzucana a JOSM wstawia pojedyncze nody.
A gdy za szybko użyje się klawisza klawiatury lub nawet kilkakrotnie kliknie myszką, to zamulony JOSM wyrzuca komunikat o błędzie i takie okienko może wyskoczyć co killka-kilkanascie sekund.

Przypuszczam, że obserwowane problemy z ostatnią wersją to ten błąd.
Aktualna wersja testowa powinna działać normalnie (nie sprawdzałem).

Wersja rozwojowa działa stabilnie i co najważniejsze nie zawiesza się.

Od jakiegoś czasu pojawiają mi się pionowe linie wychodzace w górę z poszczególnych węzłów:

Ma ktoś pojęcie co to jest i jak się tego pozbyć?

Przypomina to mi błąd zgłoszony kiedyś:
http://josm.openstreetmap.de/ticket/11473

Czy aktualizowałeś ostatnio Java’ę?

Zaiste, objaw podobny i nawet laptop mam podobnej klasy, tylko trochę nowszy. Sprawdzę sobie Javę wieczorem, to może występować od którejś aktualizacji.

Czy można zapisać jakoś skomplikowaną wielozadaniową akcję w wyszukiwarce F3 w JOSMIE?
Rozumiem, że nie w pliku lub funkcji w menu, ale może jakiś wzór logiczny regułki zawierający nawiasy i polecenia typu zamień zaznaczenie potem znajdź w zaznaczeniu inną formułkę? Czyli aby jedną akcją F3 zastąpić kilkukrotne grzebanie w opcjach aby zawężać filtr, co może prowadzić do błędów przy częstym stosowaniu.

Czy jest jakiś mądry powód, dla którego WMS-y nie mogą być ładowane jako pierwsza warstwa, tak jak TMS? Obecnie nie da się po uruchomieniu załadować WMS-a, trzeba najpierw dodać inną warstwę (po dodaniu WMS-a już nie jest potrzebna)