Mapa z wyszukiwaniem POI w promieniu x

Witam,
Chciałbym umieścić na stronie OSM. Chciałbym aby potrafiła obliczać odległości do punktów POI od wskazanej lokalizacji i wybrać te których odległość od zadanego punktu < X
Parametr X musi być zmienny (np: 5km, 10km, 50km)
Punkty POI które mieszczą się w podanych parametrach miałby być wyświetlane w postaci listy poza obszarem mapy.

Czy coś takiego jest wykonalne? Czy ktoś byłby w stanie udzielić mi jakiś rad, jak wykonać coś takiego? Czego użyć? Strona napisana jest w asp.net

A masz własny serwer z postgis? Jeśli tak to są do tego gotowe funkcję. Jest jeszcze możliwość skorzystania z overpass, ale w tym przypadku myślę, że będzie to za długo trwało i użytkownik się będzie niecierpliwił.

Mam dedyka z debianem, działa na nim postgreSLQ wiec postgis to nie problem.

Potrzebujesz odległość w linii prostej, czy po drogach?

Najlepiej po drogach. Wyniki wyświetlane na stronie (poza mapą), tak abym mógł dodawać opisy itp.

To trzeba będzie jeszcze doinstalować pgRouting. Tutaj jest nieco wskazówek o liczeniu odległości po drogach:
http://underdark.wordpress.com/2011/05/13/catchment-areas-with-pgrouting-driving_distance/

Jak to wygląda w praktyce? Przejrzałem sobie to pod linkiem. Rozumiem że do bazy wprowadzam moje wszystkie punkty POI. A co z punktami startowymi od których wyznaczana jest odległość? Z tego co zrozumiałem te punkty też będe musial dodać do bazy, a byłoby to troche kłopotliwe dodać wszystkie miejscowości w PL

Strona w .net’cie na dedyku z debianem? Zresztą nieważne - pewnie masz całą serwerownie.

Co do wyszukiwarki, jakiś czas temu chwilę się bawiłem OSM i sądzę, że wyszukiwarkę może i da się zrobić, ale wymagałoby to dużo zachodu a efekt i tak był by marny. Przykładowe problemy jakie można napotkać to to, że:

  • POIe nie tylko są node’ami. Przykładowo stacja benzynowa raz jest oznaczona jako way z amenity=fuel, raz jako node, a czasem obie te kombinacje występują w jednym miejscu.
  • Chciałbyś wyciągnąć adres POIa? Ja do tej pory dowiedziałem się o trzech (choć może być ich więcej) przypadkach, które trzeba rozważyć wyciągając nazwę ulicy: ulica może być wpisana bezpośrednio do node, może być wpisana do budynku, może być w “relacji” budynków.
  • Bibliotek czy API, które by ułatwiały tak podstawowe operacje jak pomoc w wyciąganiu POI nie ma (albo nie idzie ich łatwo znaleźć - zresztą tak samo jest z dokumentacją jak takie rzeczy robić)
  • Dokładność danych OSM pozostawia wiele do życzenia. Martwi to zwłaszcza w przypadku gdy te dane niewielkim nakładem mogłyby się aktualizować automatycznie (np. taki Orlen udostępnia na stronie plik z informacjami o położeniu swoich stacji).

To raptem kilka przykładów, “poklikasz” to pewnie znajdziesz więcej. Generalnie takie mam odczucie, że projekt nastawiony jest na amatorów “ręcznego” wprowadzania danych (często bezużytecznych takich jak położenie koszy na śmieci). Niestety użytkownik (czy to mapy, czy “danych”) jest na drugim miejscu. Do tego polska społeczność OSM tworzy dość zamknięty krąg w moim odczuciu wrogo nastawiony na nowe osoby i jakąkolwiek krytykę. W każdym razie nie łudziłbym się, że da się zrobić jakiś poważny projekt na bazie OSM. Ale może się mylę :wink:

O, masz od nich zgodę na wykorzystanie tych danych? Nie? To nie trolluj.
Swego czasu występowaliśmy do nich o pozwolenie, bez odzewu.

Tak, niektórym się może nie podobać, ze ruszasz nieswoje dane w bazie OSM, szczególnie mając staż kilku dni w projekcie. Jak zostało Ci wytłumaczone w wątku dot. konkursu, działania podjęte przez Ciebie nie były zbyt szczęśliwe.
I skoro już pijesz do jakiegoś zamkniętego kręgu, który rzekomo tworzymy - nopaczpan, duży ten krąg… Kilkadziesiąt osób na forum i nikt Cię nie poparł w kwestii rozpychania bazy.

  1. Trolowanie polega na zamierzonym wpływaniu na innych użytkowników w celu ich ośmieszenia. Ja nic takiego nie zamierzałem.

  2. Skąd niby miałem wiedzieć, że się z nimi kontaktowaliście? Może stąd: http://wiki.openstreetmap.org/wiki/Pl:Permissions - oh, wait - nikt nie raczył uzupełnić listy o Orlen.

  3. Jedyną konsekwencją (i to bardzo mało prawdopodobną) zaimportowania tych danych byłaby konieczność usunięcia w przypadku gdyby Orlen chciał robić problemy (tylko czemu właściwie miałby chcieć usuwać informacje o położeniu swoich stacji?). Na prawdę nie jestem w stanie zrozumieć czemu tak “sracie w gacie”. Chyba, że to chodzi, żeby mieć wymówkę, że się “nic” nie robi…

To dane w projekcie mają swoich właścicieli? Czy moje zmiany były szczęśliwe czy smutne, nie ma nic do rzeczy.

Ale zdajesz sobie sprawę, że argumentem, że nikt mnie nie poparł potwierdzasz tezę, że jest to hermetyczny krąg wrogo nastawiony do nowych osób?

A tak swoją droga, jak na osobę odpowiedzialną za moderację forum trochę słabo wychodzi Ci trzymanie się tematu wątku…

Jeśli się nie znasz, to się nie wypowiadaj. Konwersja obrysu do node to jeden sql, sprawdzanie podobieństwa nie jest skomplikowane. Ogólnie nie uważam, aby to było trudne i sam już wiele rzeczy pisałem związanych z wyszukiwaniem i działały sprawnie. Trolujesz i nie masz pojęcia o tym jak to wszystko działa.

Oczywiście, że mają!

Nazywaj to sobie jak chcesz. Dla mnie to, że nikt nie poparł Twojego pomysłu oznacza, że Twój pomysł był zły. Jesteś zabawny, jeśli uważasz, że da się stworzyć hermetyczny krąg z kilkudziesięciu osób, które w żaden sposób nie są zależne od pozostałych.

Dokładnie, sam mam napisane wyszukiwanie + geodekodowanie + geokodowanie obejmujące łącznie dane OSM+UMP. Daje mi to sporą elastyczność, a procedury nie są złożone.
Podejście do różnych wariantów opisywania POI czy w ogóle addr się z resztą zmienia w czasie życia projektów ze względu na nowe podejście (np relacje) i to jest dobre, ale nie da się tego wdrożyć 1 kliknięciem na całą tak ogromną bazę, więc to soft musi być elastyczny. Obejmować też musi specyfikę rejonów czy państw.

Ja może jeszcze technicznie.
Dane nt. położenia stacji, sklepów czy innych udostępniane na stronach www firm niestety zwykle nie nadają się do automatów. Punkty potrafią być przesunięte nawet o kilkaset metrów. U niektórych jest lepiej, u niektórych gorzej, czasem spora część jest ok, ale pojedyczne odchyły zniechęcają do automatyzacji.
Nawet tam, gdzie dokładność nie jest zła (np. do 10-30m), POI może być przysunięty bliżej niewłaściwej drogi, a więc nawigacja do danego punktu będzie niewłaściwa, np: http://mapa.ump.waw.pl/ump-www/?zoom=18&lat=50.02789&lon=19.96127&layers=B00000FTF&mlat=50.02796&mlon=19.96156
Gdyby POI był tam gdzie czerwony marker, stację można byłoby powitać jedynie spojrzeniem (zjazd na nią jest nieco wcześniej i dość mało oczywisty, bo jednocześnie jest to zjazd do Castoramy).
Z doświadczenń UMPowych ze wszystkich Orlenów, Lidlów i innych udaje się korzystać sensownie jedynie z baz BP - i to dlatego, że możliwy jest feedback, tzn. korekcja współrzędnych “u źródła”.
W pozostałych przypadkach bazy przydają się do weryfikacji ilościowej i lokalizacji nowych punktów (chociaż niejednokrotnie są one wcześniej na mapie niż w bazie firmowej).
Pozdrawiam,

Widzę, że chyba inaczej rozumiemy “pojęcie” hermetyczny krąg (bo co niby zależności od “pozostałych” miałyby mieć do rzeczy), dlatego spróbuję wytłumaczyć w sposób prosty o co mi chodzi. Generalnie sądzę, że “stali” członkowie społeczności liżą się po fiutkach - tj. każdy każdemu przyznaje rację nawet jeśli jej nie ma. Skutkuje to zniechęcaniem ewentualnych nowych członków społeczności (stąd mowa o zamkniętym kręgu). Dobrym przykładem jak to się odbywa jest kwestia “mojego pomysłu”. Główną “inspiracją” do mojego kreatywnego “wpadnięcia” na pomysł były słowa:

z tematu konkursowego. Teraz mi piszesz, że “mój” pomysł jest nieszczęśliwy i rozpycha bazę danych…

W każdym razie, na podstawie powyższego śmiem uważać, że to jednak Ty jesteś “zabawny”.

Myślę, że się nie znasz, więc się nie wypowiadaj. Kolega wyraźnie napisał, że robi to "jednym SQL"em, a nie procedurami. “Trolujesz i nie masz pojęcia o tym jak to wszystko działa.”

Rozumiem, że importu bez żadnego nadzoru nie opłaca się robić. Dlatego można to zrobić “półautomatycznie”, tak że wątpliwe rzeczy musiałby potwierdzić człowiek, albo że dane pomiędzy bazami danych byłyby powiązane w taki sposób, że priorytetem byłoby położenie punktu podane przez użytkownika OSM, a inne metainformacje brane by były ze źródła. No i dochodzi właśnie kwestia tego, że dochodzą nowe punkty (albo stare są usuwane). Moim zdaniem lepiej, żeby nawigacja poprowadziła błędnie kilometr do najbliższej stacji, niż prawidłowo do stacji oddalonej o 10km. Stacje może nie są najlepszym przykładem, ale jak np. wejdę na mapę bankomatów Euronetu i porównam z OSM to od razu widzę, że trochę ich brakuje i trochę to boli, że zamiast “samo” się dodać automatycznie, to latami pewnie będzie trzeba czekać zanim “ktoś” doda.

Możliwe, że robimy się zwapniali… Ale bez przesady. Sami często się kłócimy jakie rozwiązanie będzie najlepsze. NAJWAŻNIEJSZE jest jednak to, że rozmawiamy ze sobą o tym, bo przecież moglibyśmy robić boty, które wszystko zmieniają wg naszego planu bez żadnych rozmów. A to już byłaby wojna w bazie danych, która do niczego by nie prowadziła.

Wracając do meritum :slight_smile:
Kombinowałem i wyszło mi, że trzeba by zrobić kilkuetapowo:

  • wziąć na wejściu współrzędne użytkownika (środek wyświetlanej mapy albo przez Geolocation API, to już zależy jaką masz aplikację - na pewno nie musisz wgrywać wszystkich miejscowości do bazy)
  • wyznaczyć na podstawie sieci dróg OSM (którą musisz sobie importować przez osm2pgrouting albo osm2po) “catchment zone” o zadanej odległości,
  • punkty otoczyć przez ST_ConcaveHull (uwaga, wolne! i to bynajmniej nie w znaczeniu “free”) poligonem,
  • znaleźć te POI, które się mieszczą w tym poligonie.

Całość potrwa dość długo i jest dobra do celów badawczych, ale na pewno nie do działającej aplikacji. Zatem proponuję na start po prostu:

  • wziąć współrzędne użytkownika - tak jak poprzednio,
  • zrobić SELECTa z tabeli zawierającej POI z warunkiem … AND ST_DWithin(<współrzędne_użytkownika>,<dystans_w_metrach>)

Współrzędne POI najlepiej trzymaj w układzie geograficznym (typ Geography - nie Geometry! i układ EPSG:4326), będzie trochę wolniej, ale zadziała w każdym miejscu na Ziemi bez martwienia się o zniekształcenia.

A to w SQL to już nie może być procedur? Akurat całe np. geokodowanie robię 2 sqlami, z tego powodu że lecą do 2 baz OSM i UMP i wybieram z nich “lepsze” - bliższe geograficznie lub dokładniejsze - np. nr posesji, bo ulice czy reszta to w większości jest.

Tak byłoby chyba najrozsądniej.

Teoretyzując: mogłoby się dodawać “automatycznie” ale z nazwą czy tagiem wyraźnie wskazującym, że jest to do weryfikacji (żeby dało się nad tym zapanować). Ale kończy się wtedy na “opiekunie” obszaru, który taki rzeczy weryfikuje - czy to bankomaty, czy stacje, czy inne kategorie. Moim konikiem są bankomaty w Krakowie (na UMP), ale może warto byłoby napisać automaty wykrywające choćby pojawienie się nowych punktów na kilku www (stacje, bankomaty, sklepy).
Akurat bankomaty w miarę dobrze zbiera strona karty.pl, tyle że mało nadaje się do współpracy z automatami…
Pozdrawiam

No akurat pobieranie na chama danych (chociaż i tak one nie mają informacji o współrzędnych), na których zagregowanie gołym okiem widać ktoś poświęcił czas było by już niestosowne. Ale widać, że pewnie ten serwis prowadzi jakiś hobbysta, z którym można by się jakoś dogadać - jak nie na temat importu danych to jakiegoś know-how skąd je ma. W sumie to jest rzecz, którą by takie stowarzyszenie mogłoby zrobić (gdyby potrafiło rozmawiać z ludźmi).