JOSM - różne sprawy, porady

To działa na 100%.

Filtr tak, ale wyszukanie type:way przez ctrl+f je bezwzglednie odznaczy.

Dla mnie najwygodniejsze jest Ctrl + F aby zaznaczyć jakiś rodzaj danych np. highway=track

Następnie z wcześniej przygotowanego zaznaczenia można usunąć wybrane elementy:Ctrl+F i przełączenie trybu na “usuń z zaznaczenia”, np. surface=* usunie z zaznaczonego highway=track tylko te obiekty, które zawierają niepustą wartość w tagu surface.

Jest też opcja “dodaj do zaznaczenia”, która pozwala łączyć kilka filtrów.

Generalnie więc trzeba do tego podejść kreatywnie i podobnie jak z SQL dopasować sposób filtrowania do konkretnej sytuacji.

Dzięki wam wszystkim za pomoc i wskazówki! Faktycznie, z wyszukiwaniem (Ctrl+F) działa inaczej niż z samym filtrowaniem, czyli zaznacza tak jak trzeba (bez punktów wchodzących w skład linii). Ciekawa zabawa :smiley: i na dodatek będzie wkrótce efekt:

https://github.com/gravitystorm/openstreetmap-carto/pull/1676

Majstruję preset do JOSM ze stacjami paliw. Z tak poustawianymi wartościami domyślnymi, żeby wystarczyło parę kliknięć, żeby otrzymać komplet tagów.
Potrzebuję informacji, które z poniższych paliw występują w ogóle w Polsce:
1_25
1_50
GTL_diesel
HGV_diesel
biodiesel
biogas
cng
e10
e85
octane_100
octane_91

Te, które w ogóle nie występują ustawię na “no”, być może nawet bez pytania użytkownika.

EDIT: Chyba jednak skórka nie warta wyprawki…

A co cię powstrzymało? Najlepszy byłby preset ze wszystkimi na świecie, ale może być także taki dodatkowy specjalnie dla Polski (bo nie wszystkie są dostępne domyślnie).

Kiepski pomysł. Raz, że obecny szablon w JOSM jest OK, a dwa, że ustawianie z difoltu =no wprowadza błędną informację.

Sensem dodatkowego presetu miałoby być ułatwienie szybkiego wprowadzenia poprawnych tagów przez istotne zmniejszenie liczby kliknięć potrzebnych do poprawnego pełnego otagowania.
W tym celu należy:

  1. zamiast jednego presetu dla amenity:fuel zrobić kilka, z różnymi zestawami wartości domyślnych. Myślę o stacji benzynowej, stacji LPG i punkcie ładowania samochodów elektrycznych.
  2. dla paliw zwykle dostępnych na stacji dać domyslnie “yes” (benzyna 95, 98 i olej dla stacji benzynowej, dla pozostałych odpowiednio). Dla pozostałych rodzajów paliwa dać domyślnie “no”. Dla rodzajów paliwa w ogóle niedostępnych w Polsce można ewentualnie ustawić na stałe “no” bez możliwości zmiany, żeby się nie pętały po formatce.
  3. Podobnie dla dostępnych metod płatności. Tu bym dodatkowo dorzucił Blika jako opcje, widziałem stacje, gdzie akceptowali. Podobnie dla PeoPay, jeśli gdzieś akceptują (nie wiem tego).
  4. Można też ograniczyć wybór sieci do występujących w Polsce.

W ten sposób w większości wypadków wystarczyłoby wybrać brand, żeby mieć w pełni otagowaną stację, przy czym co popularniejsze opcje paliwa i płatności wyciągnąłbym na wierzch z linkami do presetów umożliwiających ustawienie dowolnie egzotycznych opcji.

Czemu nie na całym świecie? Bo gdzie indziej inne wartości domyślne będą mieć sens. Już w Niemczech wcale nie jest tak, że niemal wszędzie akceptują Visę i MasterCarda, oraz zdaje się, że właśnie tam zdarza im się sprzedawać z dystrybutora mieszanki dla dwutaktów, których w Polsce nie uświadczysz, o ile mi wiadomo.

Co mnie powstrzymuje dla Polski? Przede wszystkim brak możliwości ustawienia checkboxa na “no”. Ustawienie value_off=“no” i default=“off” tworzy dokładnie takiego samego checkboxa, jak brak defaultu - tag w ogóle nie jest tworzony. żeby ustawić wartość na “no” trzeba w checkboxa kliknąć dwa razy. Musiałbym zamiast checkboxów użyć combo, ale wtedy formatka robi się trochę za duża do szybkiego ogarnięcia.

Ja nie mówię, że jest zły, tylko że przez poustawianie wartości domyślnych dla Polski można znacznie ułatwić poprawne, pełne otagowanie stacji. W większości przypadków wystarczyłoby wybrać brand z ograniczonej listy, ewentulanie dodać info o sklepie - i wszystko.

Tego nie rozumiem. Jaką błędną informację?

Ktoś będzie chciał dodać stację, na stacji wie, że jest Pb95, zmieni na ‘yes’, resztę pozostawi.
Jakie dane będziesz miał w bazie wtedy?

Nie zmieni, bo fuel:octane_95=yes jest juz ustawione w presecie. Tak samo, jak 98 i diesel. Czyli ktoś zaznaczy stację, ustawi brand, a podstawowe rodzaje paliwa już będą ustawione na yes.

Ale przecież Ty pisałeś o zmianach takich:

Także już nie wiem co chcesz pozmieniać.
Tak czy siak, uważam jak Zbigniew, że byłoby to wprowadzaniem w błąd.

Cytuję:

Da się w presecie zrobić tak, żeby z automatu dodawało do relacji?
Przy czym chodzi o relację Veturilo, gdzie każda wypożyczalnia jest członkiem bez roli.

Czytam o member_expression i ni cholery nie kapuję, jak to działa…

Wygląda na to, że wystarczy zadać to pytanie w dowolnym wątku w dowolnym języku, jakim umiem się posłużyć, żeby wątek umarł…

Naprawdę NIKT nie wie, jak to działa?

Chyba zostałem wywołany do tablicy, bo jakiś czas temu poprawiałem to, jak to się parsuje w walidatorze, więc coś wiem jak to działa.

Patrząc po kodzie preset’ów, to wydaje mi się, że wykorzystywane to jest tylko w walidatorze, przy edycji w ogóle.

To jak to działa w walidatorze, to chodzi o to, czy jak mamy element o danej roli, to czy jest odpowiednio otagwany, czyli jak mamy:

<role key="stop" text="stop position" requisite="optional" type="node" member_expression="public_transport=stop_position" />

To jeżeli mamy członka relacji typu “stop position”, to sprawdzamy, czy członek relacji ma tag: “public_transport=stop_position”. Jeżeli to nie będzie spełnione (oraz dla żadna inna definicja roli o tym samym kluczu nie zostanie spełniona), to walidator zgłosi błąd.

Dzięki :smiley:

Czyli w przypadku Veturilo, gdzie stacje są członkami bez roli, to i w walidatorze tego nie użyję. Czyli dalej, albo przypiszemy stacjom jakąś rolę (korzyść dodatkowa - walidator przestanie płakać przy każdej zmianie relacji), albo mogę najwyżej łatać jakimś tekstem w szablonie, przypominającym żeby dodać do relacji…

A jest jakiś edytor do relacji, albo dobra instrukcja, z ktorej się nauczę jak się definiuje możliwe role?

No ale walidator działa z poziomu relacji. Więc on nie wyciągnie Ci błędu “ten obiekt powinien być członkiem relacji, a nie jest”. Bo tego możesz się dowiedzieć najwyżej patrząc na obiekt typu way/node.

Edytora, który pozwala definiować typy relacji nie ma - tak samo jak nie ma edytora definiującego nowy schemat tagowania linii. Rola w relacji jest po prostu dodatkowym “tagiem”, może być dowolnym ciągiem znaków.

A wprowadzanie nowych presetów do JOSM-a jest opisane tutaj:
https://josm.openstreetmap.de/wiki/TaggingPresets

Słusznie, niniejszym zapominam o jakim bądź automacie do relacji i będę jakoś łatać.

Tak, rozumiem. Tyle, że z komunikatu, którym JOSM mi płakał ilekroć modyfikowałem sieć Veturilo wnioskuję, że da się jakoś zdefiniować możliwe role dla relacji i potem sprawdzać, czy elementy mają którąś z tych ról. I chciałbym to jakoś rozpracować, więc szukam jakiejś dobrej instrukcji, albo edytora, w którym byłoby wszystko jasne ;).
Aczkolwiek nie wykluczam, że wyciągam z tego komunikatu zbyt daleko idące wnioski…

A na to już trafiłem, dzięki. Własnie na tej stronie natknąłem się po raz pierwszy na member_expression.

Reguły jakie mamy w tej chwili w walidatorze dla Route Network są następujące:

<item name="Route Network" icon="presets/path.png" type="relation" preset_name_label="true">
            <link href="http://wiki.openstreetmap.org/wiki/Relations/Proposed/Network" />
            <space />
            <key key="type" value="network" />
            <text key="name" text="Name" />
            <optional>
                <text key="network" text="Network" />
                <text key="operator" text="Operator" />
            </optional>
            <roles>
                <role key="" text="member" requisite="required" type="relation" />
            </roles>
        </item> <!-- Route Network -->

No i zapisana tutaj reguła dla ról mówi o tym, że dupuszczalni są tylko członkowie typu relacja, więc węzły są złym typem relacji.

Czytając wiki:
http://wiki.openstreetmap.org/wiki/Key:network

Wydaje mi się, że albo trzeba się zastanowić nad dodaniem jakiejś wartości network=* dla sieci wypożyczalni rowerów i dodać preset dla relacji - “sieć wypożyczalni rowerów”, która wtedy będzie dopuszczać jako członków węzły i obszary (jakby ktoś chciał rysować wypożyczalnię jako obszar?). Albo zmienić tą ogólną regułę walidatora, by nie sprawdzała w ogóle członków.

Wydaje mi się, że obecne podejście, by sieci wypożyczalni tagować jako network=*, jest błędne, bo mieszamy sieci drogowe, z innymi sieciami. Ale tutaj potrzeba zastanowić sie nad ontologią i popatrzeć - co w tej chwili jest w relacjach typu network.

PS.
A konkretnie, gdybyś dodał:

<role key="" text="member" requisite="required" type="node" />

To walidator by nie krzyczał. Możesz też dodać node po przecinku.

JOSM po ostatniej aktualizacji przy próbie załadowania podkładu, np. Geoportalu wypisuje komunikat:

“The layer Geoportal 2: Ortofotomapa (aerial image) does not support the new projection EPSG:3857. Supported projections are: EPSG:2176, EPSG:2177, EPSG:2178, EPSG:2180, EPSG:4326.
JOSM użyje EPSG:4326 do odpytania serwera, jednak rezultaty mogą różnić się w zależności od serwera WMS.
Change the projection again or remove the layer”

Można dać tylko OK, podkład się wczytuje, ale nie na wyższych rozdzielczościach, takich 3-4m na suwaku u góry po lewej (przepraszam za lamerskie określenie zooma, ale nie wiem jak podać to inaczej), natywnie jest to 9-10m na skali. Na pewno przedtem wyższe rozdzielczości się wczytywały.

Czy ktoś potrafi to wyjaśnić?