Witam. Przeglądając tę oto stronę autorstwa starsepa zauważyłem, że niektóre stacje Wrocławskiego Roweru Miejskiego są nieco oddalone od koordynatów podanych na strony WRMu, a niektóre stacje nawet nie są zmapowane. Później przeglądając takie stacje na OSM zauważyłem wiele przeróżnych i niekonsekwentnych sposobów tagowania, a do tego doszła jeszcze dziwna relacja, która nawet nie zawiera połowy wszystkich stacji i podaje e-mail nieaktualny od 5 lat.
Proponuję skopiowanie współrzędnych stacji ze strony WRMu, w celu zmapowania jak najdokładnejszej pozycji. Występuje jednak pewna komplikacja z współrzędnymi na stronie, ponieważ są one podawane z dokładnością do 6 miejsc po przecinku, gdy na OSM używane jest 7. Mam nadzieję, że to nie będzie problem, jeśli dopisze się na końcu 0 albo 5, a dokładność nie powinna zbytnio ucierpieć.
Ponadto chcę ustalić jeden konsekwentny sposób tagowania stacji WRMa, żeby zapobiec jakimkolwiek dziwnym tworom.:
amenity=bicycle_rental
bicycle_rental=docking_station – dość często używany tag
name=*
ref=*
capacity=* – użycie tego tagu jest trochę dziwne, ponieważ tuż obok takiej stacji mapujemy amenity=bicycle_parking, które posiada ten sam tag, ale z wartością 2 razy większą. Wolałbym użyć tag stands=*, żeby zapobiec zamieszaniu, lecz capacity=* jest o wiele popularniejsze.
contact:phone, contact:email=ck@wroclawskirower.pl i contact:website=https://wroclawskirower.pl – dane kontaktowe na węzłach zamiast w śmiesznej relacji-kategorii
operator=NextBike + operator:wikidata=Q2351279 – myślę, że nie ma sensu dodawać operator:wikipedia ani żadnych danych kontaktowych
network=Wrocławski Rower Miejski + network:wikidata=Q24941606 + network:short=WRM – nie widzę potrzeby dodawania network:wikipedia
source:position=* – wroclawskirower.pl/mapa-stacji lub ortofotomapa
Sądzę, że więcej tagów już nie trzeba. Zawsze się można bawić i dodawać rzeczy w stylu tourism=information + information=stele + map=yes, app_operated=yes, fee=yes + fee:conditional=no @ ride<20min, ale próbujemy jedynie mapować stacje, a nie pisać księgi.
Nie wiem jak można wykonać taką edycję automatycznie, ale jestem gotów zmapować to ręcznie, w końcu to tylko 306 stacji.
Nie przeglądałem tych danych urzędowych, ale one wcale niekoniecznie są dokładne jeśli chodzi o lokalizację.
Zamiast contact:phone=* i contact:email=* można pisać po prostu phone=* i email=*.
Relację można chyba skasować, relacje nie powinny być używane jak kategorie.
Że “tylko” to bym nie powiedział :D, ale inna sprawa że ja w tabelce naliczyłem 238 stacji
Od początku kwietnia ruszył kolejny sezon WRMu i tym razem z pewną znaczną zmianą — nie ma już słupków reprezentujących stacje. To oznacza, że nie ma już problemu z brakiem atrybucji . Z poważniejszych spraw, zakładam, że rowery są przyjmowane jako zwrócone na stację, jeżeli ich pozycja GPS znajduje się jakimś promieniu od lokalizacji stacji w bazie danych WRM.
W związku z tym uważam, że powinniśmy jak najlepiej odwzorować lokalizacje tych punktów, skoro nie istnieją już w terenie.
bicycle_rental=dropoff_point – jednak ten tag jest właściwym dla stacji we Wrocławiu
name=*, ref=*
brand, brand:wikidata – w celu dodania do NSI
network, network:wikidata, network:short
operator=NextBike Polska
fee=yes, fee:conditional=no @ rental < 20 minutes – wiem, że to mało popularny tag. Być może nie będę go dodawał, ale moim zdaniem to przydatna informacja
authentication:app=yes – powszechnie używany tag za granicą i niektórych polskich miastach
Chciałbym, aby lokalizacja punktów była jak najdokładniejsza, dlatego, choć trochę kontrowersyjnie, proponuję dodać tagi lat i lon do każdej stacji, aby po przypadkowym przesunięciu stacji łatwo było ją przywrócić na właściwe miejsce.
Tagi, których proponuję nie dodawać:
capacity – nie ma limitów na stacjach, ile rowerów może się na niej znajdować. Zamiast tego proponuję liczbę ze strony pomnożyć przez 2 i dodać do najbliższego parkingu rowerowego
wszystkie tagi kontaktowe – NSI nie wspiera ich dodania, gdyż są one dostępne poprzez brand:wikidata. Uzupełniłem te dane na stronie Wikidata WRMu, więc nie będzie problemów. Nawet dałem aktualny email – nie tak jak na relacji grupującej stacje
operator:type=private – jakoś nie widzę sensu w tym tagu. Czy ktoś mógłby mi wytłumaczyć, po co ten tag na stacji rowerowej? Czy do czegokolwiek się przydaje?
Po raz kolejny zgłaszam się na ochotnika do manualnego dodawania tych tagów.
Według schematu, który ustalimy w tym wątku, zaproponuję aktualizację wpisu WRMu w NSI.
Nie widzę sensu w dodawaniu lat, lon do punktów. Nie rozumiem też do końca celu?
Jeśli ktoś Ci zmodyfikuje punkt to i tak musisz zobaczyć, jak to w ogóle zostało zmienione i czy może zostało przesunięte poprawnie (z nowym orto), czy zmienione tylko tagi.
Co jak np. zrobią stojaki rowerowe obok takiego punktu (o ile może teraz tak być, że ich nie ma)? Naturalnym wydaje się wtedy przesunięcie go tam, a nie trzymanie np. na środku chodnika.
Takie rzeczy można śledzić poza OSMem jak dane o sklepach, przystankach itp.
Prosty skrypt pobierający dane z Overpassa + gdzieś masz zapisane pozycje lat lon, czy to lokalnie swoje dane, czy z konkretnej wersji obiektu OSM, czy nawet z danych z importu, choć te pewnie będą niedoskonałe względem OSMowych obiektów, ale zawsze w takim skrypcie możesz dodać jakiś margines np. 5-10 m, a dopasowywać je możesz po tagu ref – wtedy masz przy okazji kontrolę, czy wszystkie punkty są oznaczone.
Pytanie jest jak wtedy odbiera to system. Bo tak naprawdę rower można zostawić gdziekolwiek w określonym promieniu i będzie to zaakceptowane. Nawet jeśli będzie to oddalone od stojaków.
Tym bardziej się przydadzą, jeśli punkty byłyby przenoszone bliżej stojaków, ale preferuję nie przesuwać węzła i nie będę wtedy się upierać przy tych tagach.
Brak słupka powoduje, że brzmi to bardziej jak lokalizacja wirtualna, a nie fizyczna, no chyba, że jednak coś będzie? Jakaś naklejka nawet?
Załóżmy, że masz nawet i te tagi w OSMie (lati lon), choć nie rekomenduję tego podejścia.
Co zrobisz jak operator zmieni dane punktu, bo np. ktoś im zgłosi, że lepiej przesunąć na północ, żeby pokrywał zasięg większą część chodnika, albo zmienią “tak o”? Prawdopodobnie tego nie wykryjesz. Wtedy będziesz rozbieżne wartości w powyższych tagach. Lokalizacja też nie będzie ta sama, bo rozumiem że dążysz do współrzędnych zgodnych z danymi od operatora, co wg mnie trochę nie ma sensu – teren powinien decydować na ile to możliwe.
Chodzi mi o to, że jak nie będziesz miał narzędzia np. jakiś prosty skrypt, który umożliwił by Ci kontrolowanie co jakiś czas tych punktów względem jakichś danych, to traci to trochę sens trzymania się tych wirtualnych współrzędnych niezależnie od tego czy masz to w tagach, czy nie
Wcześniej jak były słupki, to na nich widniała mapka ze stacjami w pobliżu. Mapką było OSM, ale bez atrybucji. Miałem do nich pisać w tej sprawie, ale widać, że już nie ma potrzeby, bo słupki nie powróciły.
Ale to tylko w ramach ciekawostki. Realnym problemem jest lekka niezgodność z zasadą mapuj, co jest na ziemi.
Dzięki, nie wiedziałem o tym. Bez znajomości tego kontekstu sądziłem, że masz na myśli atrybucję w drugą stronę, danych z WRM w OSM, i nie bardzo mi się to kleiło.
No ja bym jednak zmapował, bo pomimo braku słupków to funkcjonalność rowerów się nie zmienia. To przydatna informacja np. w aplikacji z rozkładami autobusów, żeby zobaczyć, że obok przystanku znajduje się stacja.
Można by nawet wymyśleć jakiś tag na to, że nie ma słupka.
To bez sensu. Po co umyślnie mieć zmapowaną część stacji, a nowszych stacji już nie?
No ja bym powiedział, że takie stacje są weryfikowalne pod warunkiem, że nie wszystkie rowery zostały wyposażone na raz.
Mogę powiedzieć, że te stacje tak połowicznie spełniają wymagania bicycle_rental=dropoff_point. Są one w jakiś sposób częścią parkingu rowerowego oraz mają blokadę otwieraną aplikacją, ale nie ma nigdzie znaku wskazującego na przeznaczenie dla miejskich rowerów.
To jak, ujednolicać tagowanie według zaproponowanego schematu czy całkowicie kasować?
. Z poważniejszych spraw, zakładam, że rowery są przyjmowane jako zwrócone na stację, jeżeli ich pozycja GPS znajduje się jakimś promieniu od lokalizacji stacji w bazie danych WRM.
