paczkomaty inpost

W OSM może jeszcze być obrys paczkomatu zamiast węzła. Tak tylko mówię na wszelki wypadek.

nie mam odwagi na maproulette: punktów jest bardzo dużo, a paczkomatami nikt się nie interesuje (aż do chwili kiedy ma wybrać ten do którego trafi paczka) liczę na to że ludzie będą korygować im pozycję bo bardzo będzie ich interesować lokalizacja wybranej maszyny, poza tym: i tak muszą być na miejscu i wyjąć przesyłkę, będą wiedzieć dokładnie gdzie co stoi

inpost wspominał że w sierpniu będą coś robić (ja do tego czasu też nie będę niczego dotykał)

rmikke też o tym wspomniał: ja nie przewidziałem że mogą być ‘way’, sprawdzałem tylko ‘node’: nie będę usuwał istniejących ‘way’, postawię im tylko ‘node’ na środku żeby wszystkie paczkomaty były jako ‘node’

mailuję z nimi, są przychylnie nastawieni i być może moje nagabywania skłoniły ich do zrobienia czegoś z mapą: w sierpniu będzie więcej wiadomo

to dużo węzłów, a uwagi maro21 o niedokładnościach pozycji są zupełnie słuszne: myślę jednak że będzie z tego więcej pożytku niż chaosu

To znaczy jak, będzie paczkomat dwa razy, jako obrys i jako węzeł?

tak, “paczkomatowy” “way” bez ref= będzie nieszkodliwy

jeśli zrobić wszystkie paczkomaty jako “node” a trzy zostawić jako “way”: to trudne w obsłudze, łatwiej wszystkie mieć jako “node”

nie chcę też usuwać “way”: ludzie bywają bardzo przywiązani do swoich edycji, nie mam dość energii aby wykłócać się z autorem usuniętych rzeczy i przekonywać że usunąłem jego prace “dla większego dobra” (zwłaszcza że jego “way” są zupełnie ok, ja bym je usunął bo tak mi wygodniej)

konstrukcja z “way” pod spodem i “node” na górze wydaje mi się w porządku: to by miało taki sens jak np. tutaj: https://www.openstreetmap.org/way/98991024 “way” paczkomatu byłby jak “way” budynku, a “node” paczkomatu: tak jak ten tu “node” nad budynkiem

Sęk w tym, że paczkomat jest wystarczająco duży, żeby go obrysować, więc kto go obrysuje, to dlatego że tak jest dokładniej, niż kropę postawić.

A z kolei inni się wzburzą, czemu tu są oznaczone dwa paczkomaty, skoro stoi jeden. A jeszcze inni się nie wzburzą, tylko scalą te dwa obiekty.

Stąd pytanie: o ile realnie trudniejsze byłoby dla Ciebie uwzględnienie istnienia paczkomatów jako obrysów i obsłużenie tego? Bo bez tego, to Ci się ten system będzie regularnie rozsypywać. A jeśli to obsłużysz, to być może Twój automat do uaktualniania tego dałby się wykorzystać do innych aktualizowanych z zewnątrz danych, jest ich coraz więcej.

słusznie: nie przewidziałem że ktoś może usunąć leżący sobie w spokoju ‘node’ i na jego miejscu narysować ładny ‘way’

no właśnie, dzięki - nie będę dyskryminował ‘way’ :slight_smile:

nie mam nic gotowego, zrobienie skryptu który brałby dane z jednej gromady i przerzucał na drugą nie jest bardzo skomplikowane: trudniej jest przewidzieć co może go spotkać “na wolności”, ludzie w osm mają wyobraźnię o którą bot będzie się potykał :slight_smile:

Tak zrozumiałem, że jeszcze nie masz, tym niemniej deklaruję zainteresowanie i ewentualne wsparcie od strony projektowej i bazodanowej. Już kiedyś kombinowałem nad podobnym mechanizmem, niestety umiejętności pisania skryptów w sieci mam przyzerowe :wink:

dzięki :slight_smile:

Dopiero teraz się zebrałem sorki, ale jak niektórzy wiedzą mam niedoczas.

Co do Inpostu.

  1. Nie mamy ustalonego sposobu oznaczania nie tylko “Inpostowych”, ale ogólnie i nie tylko w Polsce, ale i obecnie jest to problem w Europie. (Kocio w tym temacie jest autorytetem )
  2. Jesteśmy w kontakcie z Inpostem. (Jako stowarzyszenie OSM Polska)
  3. Mają bardzo ambitne plany rozwoju musisz zdawać sobie sprawę z konieczności aktualizacji danych, około 300 nowych lokalizacji miesięcznie.
    i co najważniejsze co do samej bazy którą dysponuje Inpost jakiś czas temu kiedy pojawił się temat paczkomatów kolega Marek (Chwalmy Go - kawał dobrej roboty :smiley: ) zrobił porównanie pomiędzy tym co jest u nas a tym co jest u nich … rozrzut jest ogromny. Baza inpostu składa się z kilku rodzajów pkt. na przykład:
  • lokalizacja to pkt. adresowy na działce lub najbliższy adres (nie pokrywa się z lokalizacją)
  • centroid terenu lub budynku na którym lub przy którym znajduje się paczkomat (nie pokrywa się z lokalizacją)

Przykład (https://discord.com/channels/783754873861963786/797883261719543881/822044775271890964) (od Marka :D)

Sam znam miejsca gdzie na lokalizacja paczkomatów, a adres to jakaś masakra - powodzenia nie znajdziesz bez pytania lub opisu.

Wprowadzenie danych, które są niezweryfikowane, a mogą być niepoprawne jest sprzeczne z zasadami OSM - mapujemy obiekty istniejące, a nie te które “mogą” być w tych miejscach. To jest największy problem z danymi Inpostu nie da się ich tak po prostu zaimportować, część nawet nie jesteś w stanie zweryfikować na podstawie orto.

Co do tych edycji uwzględnianiając twój nick i staż to:
https://wiki.openstreetmap.org/wiki/Pl:Automated_Edits_code_of_conduct
i chyba:
https://wiki.openstreetmap.org/wiki/Organised_Editing_Guidelines

mam nadzieję, że uda się jak najszybciej wdrożyć schemat tagowania paczkomatów, bo po zainteresowaniu widać, że temat jest ważny.

z botem który by nad tym czuwał to nie kłopot, a będzie miał łatwiej jeśli nikt nie będzie dodawał nowych paczkomatów w osm (nie będzie trzeba ustalać o którą maszynę chodzi jeśli ktoś doda paczkomat bez identyfikatora na przykład)

nie sprawdzałem adresów z inpostu, badałem tylko lokalizacje (lat, lng) przy ustalaniu czy pozycja z inpostu odpowiada pozycji w osm (żeby ustalić czy paczkomat o którym mówi inpost to ten sam który jest w osm), w żadnym wypadku pozycja się nie zgadzała, różnice były od metra do kilkunastu metrów (jeśli była za duża uznawałem że to nie ta sama maszyna), to sugeruje że pozycje paczkomatów w inpost nie są całkowicie przypadkowe: mają związek z rzeczywistością (jeśli za rzeczywistość uznać lokalizacje w osm, a te najprawdopodobniej są precyzyjne)

to argument za dodaniem paczkomatów do osm: błędnie umiejscowione maszyny możesz ustawić we właściwym miejscu, dodatkowo paczkomaty będą miały opis w description= i image= z bazy inpostu

a także: jeśli paczkomat w inpost jest w złej pozycji, w tej samej złej pozycji byłby w osm, próba odnalezienia go na podstawie danych z inpost byłaby dokładnie tak samo wymagająca, z tą różnicą że w osm możesz przesunąć punkt aby następni nie błądzili

podejrzewam że maszyny które inpost ma w swojej bazie fizycznie istnieją: ich lokalizacja będzie niedokładna ale są “istniejącymi obiektami”

argument o “zasadach OSM” jest słuszny, doświadczenie z usuwanie duplikatów istniejących paczkomatów mówi że to nie są “sztywne zasady”: zdarzają się błędy i niedokładności, nie sugeruję aby umyślnie wprowadzać jeszcze większy chaos, podkreślam tylko że nie wszystko jest tak ładnie jak byśmy chcieli i trzeba pogodzić się z jakimś poziomem błędu (który w osm można skorygować)

to jest argument za wprowadzeniem wszystkich paczkomatów: nikt nie będzie dodawał i tagował po swojemu, wszystkie będą miały jednolite i kompletne tagi

Tylko że paczkomat to nie restauracja. W przypadku restauracji bym się zgodził, że nawet jeśli będzie po drugiej stronie ulicy, ale z wypełnionymi tagami to pozwoli ją znaleźć i do niej dotrzeć. Paczkomaty to jednak małe obiekty i niekoniecznie znajdują się od strony ulicy, wiele z nich widziałem za budynkami, od strony niewidocznej.

Więc ja mam inne zdanie - lepiej mieć węzeł tylko z tagiem paczkomatu w dobrej lokalizacji.

Gdybym był w takim miejscu, a paczkomat byłby w złej pozycji (gdzie go nie widziałem) to bym go usunął.

Dawno temu był import bankomatów z niedokładnymi pozycjami - do dzisiaj zbieram je z chodników i ścieżek rowerowych.

jedynym(?) źródłem informacji o lokalizacji paczkomatów jest strona inpostu na której zaznaczone są nieprecyzyjne pozycje: w jaki sposób znajdujesz paczkomat z którego chcesz skorzystać?

wszystkie które widziałem były sporymi szafami, łatwo dało się je zauważyć: kiedy są gdzieś za rogiem budynku faktycznie trudno na pierwszy rzut oka je zlokalizować, jednak kiedy wiem że maszyna “jest w tej okolicy” (bo tak widziałem na mapie inpost) to się rozejrzę aż znajdę (poszukiwania ułatwia image= jeśli jest)

jeśli np. nie będzie ref=: w jaki sposób ustalasz czy to paczkomat do którego trafiła Twoja przesyłka?

co byś zrobił po tym: skopiował tagi i dodał w dobrym miejscu?

Drodzy Panowie!
Dyskusja ciekawa tylko mało produktywna. Moja propozycja. Kolega Paczkomaty skoro chce się podjąć zadania integracji danych niech robi. (Czekam z popcornem), natomiast koniecznie trzeba:

  1. Jeśli chce to robić w imieniu lub w porozumieniu z InPostem - musi przestrzegać zasad zawartych w https://wiki.openstreetmap.org/wiki/Pl:Automated_Edits_code_of_conduct oraz https://wiki.openstreetmap.org/wiki/Organised_Editing_Guidelines bez tego musi się liczyć z wycofaniem swoich zmian.
    W szczególności stworzenia strony na wiki - dodatkowo przy takiej ilości zmian o zasięgu krajowym chciałbym rozmawiać nie z Nickiem, a osobą w kwestii wiarygodności i weryfikacji jakim jest edytorem. Bo może po tym forum nie wygląda, ale większość z nas zna się osobiście lub przynajmniej “zdalnie”.

  2. W przypadku danych InPostu muszą być one zgodne z ODbL i w tym przypadku nie wystarczy ich dostarczenie, co innego jest mapowanie ze “swiata” co innego import. Do tej pory ich dział prawny nie wypowiedział się w tej sprawie. Brak pisemnej informacji o przekazaniu danych na zasadach zgodnych z ODbL może prowadzić do wycofania wszystkich zmian dokonanych przez Ciebie. I to jest nie nasza interpretacja tylko zasada OSMF z którą się nie dyskutuje ponieważ mówimy tu o zgodności z prawem europejskim dotyczących własności intelektualnej.

  3. Co do sposobu oznaczania po piątkowym spotkaniu mam zebrane wnioski społeczności oraz jakiś taki ogólny zarys jak chcemy ugryźć temat, bo w tym przypadku idziemy na standard międzynarodowy. Postaram się do Niedzieli (20.06.2021) zebrać i stworzyć osobny post w tej sprawie. Potem przeniesiemy dyskusję na wiki (stanęło na stworzenie nowej propozycji) i zrobimy kampanię tak, by zatwierdzić schemat.

Dodatkowo chciałbym zwrócić Ci uwagę, ze chwali się zapał natomiast uwagi kolegów oraz moje wynikają nie z prób zniechęcenia, ale wieloletniej znajomości OSM oraz doświadczeń wynikających z edytowania i korzystania z danych i narzędzi powiązanych z OSM. Cześć z nas ma także doświadczenie zawodowe powiązane z GIS, i wiemy jak trudno jest dokonać takiej edycji. Z góry mówię, że w przypadku tych danych automatyczna edycja nie jest możliwa, konieczne będzie w wielu przypadkach ręczna korekta położenia pkt. przed ich integracją. Wstępna analiza danych jaką dokonaliśmy wskazuje na konieczność poświęcenia tak gdzieś ze 3 miesiące na weryfikację danych. Wiem co mówię w kilku województwach integrowałem dane z CRFOP z OSM, i powiem, że ogrom pracy znacznie przekroczył moje możliwości czasowej jakie mam na działanie hobbystyczne. (Bdot oraz obecnie porządkowanie adresów fixme jest zdecydowanie łatwiejsze)

Tak na marginesie obecnie sama strona InPost przeszła przebudowę i teraz proponuję sprawdzić:
https://inpost.pl/paczkomat-lodz-lod23a-jana-karskiego-paczkomaty-lodzkie

Co się dzieje po próbie nawigacji do paczkomatu. Idą w ciekawym kierunku :smiley: Trochę strasznie, trochę śmiesznie, ale to ich kasa.

Kolegę Paczkomaty zapraszam na DS, będzie łatwiej rozmawiać.

Nie znajduję. Ani na stronie Inpostu, ani w OSM. Jak zamawiam coś w sklepie internetowym, to tam wybieram adres paczkomatu w którym chcę odebrać.

Patrz wyżej. Zamawiam do paczkomatu, który wiem gdzie jest.

Napisałem że bym usunął - jeśli nie widziałem paczkomatu, bo ten z importu był 100 metrów dalej.

Z moich obserwacji i doświadczenia wynika, że temat mapowania paczkomatów jest identyczny jak z mapowaniem przystanków tramwajowych/autobusowych.
Czyli nanoszenie danych które w przyszłości nie będą traktowane poważnie i aktualizowane.

Spędziłem bardzo dużo czasu z naniesieniem tras i przystanków tramwajowych i autobusowych w Krakowie i innych miejscowościach.
Za ostatnie kilka lat rzadko ktoś to aktualizował. Poza niektórymi wyjątkami gdy przystanek był w pobliżu obszaru czyjegoś zainteresowania.

Moim zdaniem Inpost powinien stworzyć nakładkę na mapę OSM, podobnie jak to jest z https://www.mapakrakow.pl/ w Krakowie.
InPost ma własną aplikację do śledzenia przesyłki i tam może dodać swoją nakładkę.

Oczywiście, nie oznacza to, że nie mamy nanosić paczkomatów na mapie.
Ale należy traktować je bardzo orientacyjnie, tzn, że gdzieś w jakiejś okolicy jest taki paczkomat.

Z jakich kont te edycje szły? Bo to jest do pilnego wycofania.

W przypadku bezużyteczego położenia (przesunięcie o setki metrów lub tak że nie idzie go znaleźć) skasowałbym na pewno. I jeśli jest taka jakość danych to import byłby błędny.

Przystanki, więc tak samo paczkomaty, to fizyczne obiekty. Takie dane są bardzo potrzebne, bo nie zmieniają się aż tak często, a bardzo często stanowią, jeśli nie cel, to odniesienie w terenie. Nie ma potrzeby traktować ich mniej dokładnie. Trasy (relacje) tram/bus/itp. to dane niefizyczne, metadane, czy miękkie dane… jak kto woli to nazywać. Ludzie ich nie edytują, bo w OSM to relacje, często MPK zmienia lub zamraża linie i ogólnie jest to żmudna robota. Żadna popularna strona nie bazuje tez na OSM, by serwować routing MPK na naszych relacjach.

Władku, może w Krakowie akurat nikt tego nie poprawiał za bardzo, bo:

  1. gdy się za to zabrałeś, zrobiłeś to po swojemu, usuwając bez pytania name ze wszystkich public_transport=stop_position w całym Krakowie i niektórzy nie chcieli przepychanek :wink:
  2. zrobiłeś to na tyle kompleksowo, że poza powyższym nie było do czego się przyczepić

Co do reszty dyskusji, to robienie importu, aby potem poprawiać pozycje tych obiektów, będzie bez sensu. Tym bardziej, jeśli importowane paczkomaty miałyby zastępoować stare dane o dokładniejszej pozycji, tylko po to by był ref. Potem będzie bałagan jeszcze większy niż obecnie.

MOŻNA zrobić import tak, żeby nie korygował tego, co w OSM już jest i, jak rozumiem, taka jest idea tego importu paczkomatów.

Wiem. O to w sumie mi chodziło. Jeśli od początku taka idea przyświeca autorowi (a druga rzecz, że nie zostaną sieroty), to pewnie mylnie go zrozumiałem i nie było tematu. :slight_smile:

Ale mogliby narysować te relacje w OSM, bo łatwo, i potem z nich korzystać;)