Edycja
Z UMP
(→Edycja kilku obszarów naraz) |
d (listy do zapisania, kosmetyka) |
||
Linia 35: | Linia 35: | ||
==Jak już dostaniesz hasło do cvs== | ==Jak już dostaniesz hasło do cvs== | ||
- | Najpierw skasuj całe repozytorium czyli pliki pobrane przez cvs. Tak, całe. Zaloguj się do cvs i ściągnij od nowa. Przydatne polecenia: | + | ...to jeszcze tylko kilka drobiazgów, z którymi mogłeś się nie spotkać: |
+ | |||
+ | * Ściągnięcie źródeł jako nazwany użytkownik, a nie gość bez praw | ||
+ | Najpierw skasuj całe repozytorium czyli pliki pobrane przez cvs. Tak, całe. Zaloguj się do cvs i ściągnij od nowa. Przydatne polecenia, jeśli nie używasz klientów graficznych: | ||
cvs login | cvs login | ||
- | cvs co all (co=checkout) | + | cvs co all (co=checkout) albo zamiast all: narzedzia, POLSKA, EUROPA, UMP-Egipt |
cvs co -c; sprawdzenie modułów | cvs co -c; sprawdzenie modułów | ||
- | cvs com (com=commit) | + | cvs com (com=commit) - pamiętaj o dopisywaniu opisów do wysyłek |
cvs logout | cvs logout | ||
- | *Jak często robić update | + | Jeśli coś pominiesz, to potem nie uda się próba wysłania na serwer. |
- | Zawsze na początku pracy i tuż przed commitem (no, jeszcze wypada zmontować i rozmontować mapę pomiędzy update i commitem oraz sprawdzić, czy nie zostały jakieś błędy). Przy dłuższej pracy także podczas przerw, ale TYLKO WTEDY, gdy rozmontowałeś wcześniej źródła. | + | |
+ | * Co czytać? | ||
+ | Na pewno listę dyskusyjną ump@, gdzie (poza dyskusjami) są wysyłane | ||
+ | ** raporty gorszych błędów, często blokujących przetwarzanie mapy lub jej prawidłowe działanie - wypada po sobie poprawić! | ||
+ | ** ogłoszenia o nowych narzędziach czy ich funkcjach, ustaleniach "politycznych" itp. | ||
+ | Do tego możesz się zapisać na: | ||
+ | ** jeśli chcesz obrabiać także zgłoszenia innych: [http://ump.waw.pl/mailman/listinfo/ump-wrzuty listę Wrzuty] i/lub [http://ump.waw.pl/mailman/listinfo/ump-remonty Remonty] | ||
+ | ** [http://ump.waw.pl/mailman/listinfo/ump-devel listę developerską], gdzie są dyskusje o nowych narzędziach przed ich ogłoszeniem (często niestrawne dla nie-informatyka;) | ||
+ | ** dla warszawiaków: [http://ump.waw.pl/mailman/listinfo/ump-wawa lista warszawska] | ||
+ | |||
+ | * Jak często robić update | ||
+ | Zawsze na początku pracy i tuż przed commitem (no, jeszcze wypada zmontować i rozmontować mapę pomiędzy update i commitem oraz sprawdzić, czy nie zostały jakieś błędy). Przy dłuższej pracy także podczas przerw, ale TYLKO WTEDY, gdy rozmontowałeś wcześniej źródła i umieściłeś poprawki w katalogu src. | ||
Jeśli zrobisz <code>cvs update</code> w trakcie edycji, zapiszesz swoje zmiany, a potem rozmontujesz źródła, to nadpiszesz poprawki wprowadzone przez <code>update</code>, a więc skasujesz czyjąś pracę. | Jeśli zrobisz <code>cvs update</code> w trakcie edycji, zapiszesz swoje zmiany, a potem rozmontujesz źródła, to nadpiszesz poprawki wprowadzone przez <code>update</code>, a więc skasujesz czyjąś pracę. | ||
+ | |||
*Jak często robić commit | *Jak często robić commit | ||
Po zakończeniu pracy stanowiącej jakąś całość. Najlepiej dzielić pracę na względnie małe kawałki, commit trwa tylko chwilę, a od razu pokazuje innym naszą pracę i zapobiega w ten sposób zderzeniom. | Po zakończeniu pracy stanowiącej jakąś całość. Najlepiej dzielić pracę na względnie małe kawałki, commit trwa tylko chwilę, a od razu pokazuje innym naszą pracę i zapobiega w ten sposób zderzeniom. | ||
- | |||
- | |||
- | + | *W pliku pojawiły się jakieś linijki z "<<<<<" "=====" i ">>>>>" | |
- | + | Jednocześnie z kimś edytowałeś te same linijki pliku. Ty zrobiłeś update, cvs ściągnął drugą wersję tej samej linijki, i nie wie która jest lepsza. Między wspomnianymi linijkami widzisz swoją i czyjaś pracę. Sam wybierz którą zachować. Jeśli dwie osoby po prostu dopisały nowe obiekty na koniec pliku, to zachowuje się oczywiście wszystkie. | |
- | + | W razie niepewności dopytaj kogoś doświadczonego. | |
- | + | ||
==Jak dodać lub usunąć plik?== | ==Jak dodać lub usunąć plik?== |
Wersja z dnia 10:37, 31 gru 2011
Rzeczy potrzebne raczej dopiero edytorom z prawem zapisu w cvs.
Spis treści |
Edycja kilku obszarów naraz
- skrypt mdm-gui.pl (dostępny w cvs/narzedzia)
sposób pracy:
- uruchom (wymagany perl)
- zaznacz wybrane obszary
- kliknij na Montuj, edytuj, Demontuj
ALBO
sposób pracy:
- uruchom (wymagana java)
- sprawdź ew. popraw ustawienia (menu narzędzia)
- zaznacz obszary, które chcesz edytować: menu regiony (jeśli nie ma żadnego, to poplątałeś ścieżki w ustawieniach)
- edytuj: guzik mapedit
- ...
ALBO
- W systemie UNIX - ustaw zmienną "DIR" tak, aby zawierała nazwy kilku regionów, na przykład:
export DIR="UMP-PL-JeleniaGora UMP-PL-GorzowWlkp UMP-PL-Szczecin"
a następnie dokonuj montowania/demontowania tak jak normalnie ("make mont", edycja, "make demont", "make commit"). Możesz też użyć mdm-gui.pl opisanego powyżej. Jeśli rysujesz drogi, które przechodzą przez granice obszaru z jednego na drugi, koniecznie przeczytaj Rysowanie_poza_obszar, żeby się dowiedzieć jak to robić poprawnie, a także Międzymapowy_routing_w_GARMIN-ie, by się dowiedzieć jak to działa.
Sprawdzanie ogólnej kondycji regionu
Służy do tego skrypt "sprawdz_bledy.bat" - dwukliknij i czytaj.
Pod uniksem, analogiczny make sprawdz
.
A więcej opisów jest tam.
Jak już dostaniesz hasło do cvs
...to jeszcze tylko kilka drobiazgów, z którymi mogłeś się nie spotkać:
- Ściągnięcie źródeł jako nazwany użytkownik, a nie gość bez praw
Najpierw skasuj całe repozytorium czyli pliki pobrane przez cvs. Tak, całe. Zaloguj się do cvs i ściągnij od nowa. Przydatne polecenia, jeśli nie używasz klientów graficznych:
cvs login cvs co all (co=checkout) albo zamiast all: narzedzia, POLSKA, EUROPA, UMP-Egipt cvs co -c; sprawdzenie modułów cvs com (com=commit) - pamiętaj o dopisywaniu opisów do wysyłek cvs logout
Jeśli coś pominiesz, to potem nie uda się próba wysłania na serwer.
- Co czytać?
Na pewno listę dyskusyjną ump@, gdzie (poza dyskusjami) są wysyłane
- raporty gorszych błędów, często blokujących przetwarzanie mapy lub jej prawidłowe działanie - wypada po sobie poprawić!
- ogłoszenia o nowych narzędziach czy ich funkcjach, ustaleniach "politycznych" itp.
Do tego możesz się zapisać na:
- jeśli chcesz obrabiać także zgłoszenia innych: listę Wrzuty i/lub Remonty
- listę developerską, gdzie są dyskusje o nowych narzędziach przed ich ogłoszeniem (często niestrawne dla nie-informatyka;)
- dla warszawiaków: lista warszawska
- Jak często robić update
Zawsze na początku pracy i tuż przed commitem (no, jeszcze wypada zmontować i rozmontować mapę pomiędzy update i commitem oraz sprawdzić, czy nie zostały jakieś błędy). Przy dłuższej pracy także podczas przerw, ale TYLKO WTEDY, gdy rozmontowałeś wcześniej źródła i umieściłeś poprawki w katalogu src.
Jeśli zrobisz cvs update
w trakcie edycji, zapiszesz swoje zmiany, a potem rozmontujesz źródła, to nadpiszesz poprawki wprowadzone przez update
, a więc skasujesz czyjąś pracę.
- Jak często robić commit
Po zakończeniu pracy stanowiącej jakąś całość. Najlepiej dzielić pracę na względnie małe kawałki, commit trwa tylko chwilę, a od razu pokazuje innym naszą pracę i zapobiega w ten sposób zderzeniom.
- W pliku pojawiły się jakieś linijki z "<<<<<" "=====" i ">>>>>"
Jednocześnie z kimś edytowałeś te same linijki pliku. Ty zrobiłeś update, cvs ściągnął drugą wersję tej samej linijki, i nie wie która jest lepsza. Między wspomnianymi linijkami widzisz swoją i czyjaś pracę. Sam wybierz którą zachować. Jeśli dwie osoby po prostu dopisały nowe obiekty na koniec pliku, to zachowuje się oczywiście wszystkie. W razie niepewności dopytaj kogoś doświadczonego.
Jak dodać lub usunąć plik?
Jak dodać: stwórz pusty plik (o nazwie zgodnej z konwencją), wydaj polecenia cvs add nazwapliku; cvs commit (plik binarny: dodaj -kb). Wrzucaj zawartość, commituj.
Jak usunąć: skasuj plik z dysku, wydaj polecenia cvs remove nazwapliku; cvs commit. Użytkownik nie może kasować katalogów.
Zmiana nazwy: żeby nie stracić historii zmian w pliku, poproś Alf/red/a.
Inne sztuczki w cvs - na osobnej stronie.
Przykazania edytora
- Czytać co wypisuje sprawdzacz przy demontowaniu, poprawiać błędy. Uruchomić co jakiś czas Sprawdz_bledy lub odpowiedni make.
- Dopisywać miasto do POI
- Stawiać bojki
- Poprawiać literówki i typy przy realizacji zgłoszeń z flyspraya.
- Do plików dedykowanych wrzucać tylko to, co jest dla nich dedykowane (szczególnie stacje BP/Orlen, bankomaty, szlaki)
- Remonty:
- Nanosząc remont stawiać znacznik (punkt REMONT z opisem FS#numer) i otwierać zgłoszenie na Flyspray, projekt Remonty
- Usuwając remont (znacznik REMONT z numerem FS# i wyłączenia ulic) zamykać zgłoszenie na Flyspray (ale dopiero po upewnieniu się, że to już wszystkie znaczniki i komentarze z tym numerem FS#)
- Uważać co się wysyła do cvs. Nie wrzucać plików z konfliktami albo z zaokrąglonymi współrzędnymi.
- Dawać komentarze przy wysyłaniu zmian do cvs
- Czytać listę ump@ i reagować na błędy, szczególnie własne.
Sprawdzanie co i gdzie autor diffów namotał
czyli jak obejrzeć, co w tych diffach zostało podesłane.
Kroki poniżej automagicznie załatwia paczuj.bat pod system win32, jednak przeglądanie diffów zostaje.
Najpierw diffy po prostu przejrzyj, żeby wyłapać grube błędy albo takie niewidoczne pod Mapedit (np. zdublowanie komentarzy, albo edycja z włączonym Snap to grid, którą widać jako zmianę większości współrzędnych na ostatniej cyfrze).
- Windows
- zmontuj plik Rejon-wynik.mp ("mont-demont /mont" albo po prostu dwuklik w mont-demont i zamknij bez zmieniania)
- dwuklik w cvs_diff.bat
- to zrobi wyciąg w plikach new.plt, old.plt oraz chg.plt, oraz podepnie je pod wynik
- otwórz edycję Rejon-wynik.mp w Mapedit
- szukaj wzrokiem kolorowych wyróżników
- niebieskie - zmienione, czerwone - skasowane, zielone - dodane
- oglądaj i analizuj, pomagając sobie klawiszem E (ukrywa i pokazuje załączniki, w tym wypadku pogrubienia zmienianych miejsc)
- rozmontuj, i jeśli robiłeś poprawki, to zrób to co zwykle.
Czym się można podpierać?
Zgłoszenie jest niejasne. Trak chaotyczny. Miejsce skomplikowane. Nie pamiętam jak tam dokładnie wyglądało. Kurcze, jak skołować więcej informacji?
- Mapedit zarejestrowany wyświetla mapy Google
- Mapa UMP na WWW - korzystając z plusika po prawej stronie możesz obejrzeć wybrany obszar na UMPie, albo zmienić podkład na Google lub OSM i porównać. Jeśli oglądasz zgłoszenie z FlySpray-a, kliknij na opcji "Pokaż na mapie", żeby załączony ślad/punkty pojawiły się na podkładzie UMP-a.
- geoportal
- PKT (bardzo szczegółowe i dość świeże zdjęcia!)
- Zumi i widok satelitarny
- niektóre miasta mają własne systemy z bogatymi lokalnymi informacjami:
- Gdańsk
- Konin (wymaga pluginu AutoCad'a)
- Kraków
- Łódź
- Piotrków Trybunalski
- Bełchatów
- Poznań
- Szczecin
- Warszawa (menu Geodezja - Adresy)
- Wrocław oraz powiat wrocławski
- Zielona Góra
- Norc - zdjęcia z sierpnia 2008, tylko główniejsze ulice Kraków, Poznań, Warszawa, Wrocław
- jeśli nie obędzie się bez wizji lokalnej, można poprosić kogoś o pomoc.
Pamiętaj, że zdjęcia satelitarne mają przynajmniej pół roku, często dużo więcej, a my chcemy mieć mapę aktualną. Nie podpieramy się obcymi mapami w kwestii routingu czy nawet przebiegu ulic. Drogowcy są szybsi, niż te produkty.
Inne mapy
Źródeł danych geograficznych jest niedużo, map na ich bazie więcej. Krótkie zestawienie kto z jakich danych korzysta:
- OpenStreetMap z czegokolwiek, poza własnymi trackami także z UMP, państwowych danych we Francji, itd. Przepis jak zaimportować dane ImportOSM
- OpenMaps z własnych tracków
- z bazy Imagisu korzystają:
- z bazy Indigo korzystają:
- z bazy Emapy korzystają:
- z bazy Teleatlas korzysta:
- TomTom
- Google (także z PPWK i Trans Navicom)
- Via Michelin
- z bazy Navteq korzysta