Wikipedia:Geografiske søk
Geografiske søk i Wikipedia er i utgangspunktet ikke støttet, men via bruk av kategorier og kall i APIet så er det mulig å få noe som fungerer til en viss grad. Utgangspunktet er et geografisk koordinat og så finne det som er nærliggende, for eksempel for å kunne presentere en rangert liste utfra avstand fra et angitt punkt. Et poeng her er at en ikke kjenner navnet på kommunen eller fylket. Et slikt søk etter artikler med en geografisk tilhørighet er ikke det samme som en fungerende geografisk navigasjon, men det er en start og kan brukes for å lage fungerende navigasjonsmodeller.
Algoritme[rediger kilde]
En metode som fungerer i konteksten til Mediawiki er å begrense et et sett av artikler ved å bruke subsett av artikler med en gitt lokal tilhørighet. Slike sett kan lages på flere vis, men en aktuell løsning er å dele opp jordkloden langs gradene angitt i de geodetiske koordinatene og plassere de i respektive skjulte kategorier. Istedenfor å søke gjennom et stort datasett vil en da behandle det mindre datasettet, eller endatil snittet mellom to slike mindre datasett.
For eksempel så er kartkoordinatet til Oslo 59°54'N 10°44'Ø og vil bli kategorisert i 59N og 10Ø, mens tilsvarende for Bergen er 60°23'N 5°19'Ø og vil bli til 60N og 5Ø. Slike kategorier kan legges inn via koordinatmalen og teknikken vil være skjult for alle andre enn brukere som har slått på fremvisning av skjulte kategorier. Når vi skal finne artikler for et lokalt sted så finner vi ut hvilken kategorier for lattitude og longitude stedet tilhører og tar et snitt mellom medlemmer i kategoriene.
Disse kategoriene kan vi så bruke for å hente ut kategorimedlemmer. For eksempel kan vi lage spørringer for koordinataksene til Alvdal som ligger i 10°Ø (api) og 62°N (api). Ved å ta ut subsettet som forekommer i begge disse settene så har vi artikler som er geografisk lokalisert i ruta til Alvdal.
Når vi har subsettet kan vi hente ut koordinatene for de enkelte kategorimedlemmene. Disse dataene er ikke direkte tilgjengelige uten i teksten, men de er kodet inn i URLen til blant annet GeoHack og er dermed tilgjengelig når prop inkluderer extlinks. Ikke helt optimalt, men adskillig raskere enn å hente ut posisjonen ved å parse nettsiden.
For eksempel vil tettstedet Bagn (api) rapportere
<el xml:space="preserve">http://toolserver.org/~geohack/geohack.php?language=no&pagename=Bagn&params=60_49_20_N_9_33_0_E_</el>
Hvor params=60 49 20 N 9 33 0 E er en geografisk representasjon av artikkelens posisjon. I noen tilfeller kan det være flere lenker i artikkelen, og da må det vurderes hva som skal velges. I slike tilfeller så kan type-parameteren som brukes i Mal:Koord være til hjelp. Det står noe mer om denne på Wikipedia:Geografiske posisjoner. Når denne settes så vil den kodes inn på formen params=52 28 N 1 55 W region:GB type:city. Muligens bør det kodes inn noe ala key=primary, eventuelt role=infobox eller lignende på en URL som gjelder artikkelens hovedinnhold. Dette vil gjøre det mulig å identifisere viktigste geografiske koordinat.
I Wikipedia kan vi ikke gjøre snittet mellom kategoriene på serveren, vi må laste ned settene og gjøre videre prosessering i nettleseren. For å få dette til å spille effektivt så kan vi gjøre noen triks. Det viktige er at hvis vi kan produsere et datasett som er tilstrekkelig mye mindre enn andre aktuelle datasett så kan vi skifte strategi og hente informasjon om kategorier mer effektivt.
Vi har en primær metode å hente informasjon om medlemmer i kategorier og det er med listevisningen som ble vist ovenfor. Denne vil en kategori liste alle kategoriens medlemmer. Vi er på jakt etter snittet mellom kategorier og om vi sammenligner 10°Ø (api) og 62°N (api) så er førstnevnte en vesentlig større kategori enn sistnevnte. Hvis forskjellen er stor nok (antakelig med enn en faktor på 10 eller mer) så vil det lønne seg å bruke en generator istedenfor liste vi har brukt ovenfor. I eksempelet med Alvdal er forskjellen en faktor på omtrent fem. Med en generator vil vi få ut kategoriens medlemmer, og kan liste ut deres kategorier samtidig. Det gjør det mulig å filtrere på kategorienes navn uten å gjøre en ny spørring til serveren.
Metoden med generator fungerer når vi har to kategorier og den ene er vesentlig større enn den andre. Det kan i noen tilfeller være nødvendig å bruke en generator på det minste datasettet fordi den nedlastede lista vil bli på over systemets maksimalt tillatte størrelse.
Hvis det er flere enn to kategorier så kan det brukes snitt mellom sett av kategorimedlemmer for alle kategorier inntil det er et tilstrekkelig lite restsett igjen. Denne iterasjonen løper fra de kategoriene som har færrest medlemmer og deretter på kategorier med flere medlemmer. For hver iterasjon må lista med kategorimedlemmer lastes ned. Når restsettet er endelig eller tilstrekkelig lite så spørres det eksplisitt etter informasjon om de gjenværende artiklene. Hvis det fortsatt er utestående kategorier så må prop inkludere categories, hvis ikke holder det med extlinks.
Det er viktig å være klar over at spesielt en generator er en tung operasjon og at slike spørringer bør begrenses mest mulig. I noen tilfeller vil det være mest effektivt å hente inn eksternlenke sammen med kategoriene under spørringen på categorymembers. I andre tilfeller er det mer effektivt å hente ned informasjon om de aktuelle artiklene etter at et restsett er beregnet i nettleseren. I begge tilfeller bør en cache der det er mulig, og en bør sette maxage og smaxage på de aktuelle spørringene slik at de caches der det er mulig.
Også når en spør etter ytterligere data om de enkelte sidene så må spørringen formateres slik at den cacher effektivt. Hvis noe er involvert i forutgående spørringer som kan introdusere sporadiske tilfeldigheter og avvik så er det lurt å gjøre tilpassinger i spørringen slik at den den gis en mulighet for å resynkronisere. For eksempel kan en spørre utfra artiklenes id, og gruppere denne med en eller annen faktor. En løsning er å hashe verdiene inn i bins med en predefinert funksjon eller å sortere de inn i slike på annet vis. Et grensetilfelle som er aktuelt er hvis antall oppføringer i restsettet er lite er å spørre på hver artikkel for seg.
Når antall oppføringer i kategoriene for breddegrad og lengdegrad blir stort så kan vi dele opp kategoriene i flere underkategorier. Typisk vil vi da dele de i underkategorier med lik bredde og jevnt fordelt innenfor sektoren. Det enkleste synes å være å bruke desimalgrader og og fordele i enten 10 segmenter eller 100 segmenter. Det kan også være aktuelt å fordele i 10 segmenter for så å dele enkeltsegmenter i nye 10 segmenter for å oppnå en oppløsning på 100 segmenter innenfor et mindre område. Foreløpig er det ikke kjent noen sektor som må deles opp med to desimaler.
Brukes en slik lokalt finere segmentering så må må det sjekkes om kategorien inneholder subcats, finnes slike så må en sjekke om det finnes ytterligere oppføringer i disse underkategoriene i den grad de dekkes av etterspurt område.
Det er mulig å effektivisere spørringene hvis en skal hente ut store datasett for så å gjøre et snitt (intersection) mellom dem. For det første så vil et slikt subsett medføre at det er to sett hvor alle sider i det nye subsettet er i begge de opprinnelige settene. Det gjør at vi kan spørre etter det minste av dem og filtrere på dette settets kategorier. For eksempel kan vi spørre etter antall medlemmer på koordinataksene til Alvdal, og da finner vi at nord-sør -aksen har flere tusen oppføringer (3074 når dette skrives), mens øst-vest -aksen har noen hundre oppføringer (620 når dette skrives). Slike kontroller kan vi gjøre med Kategori:10°Ø og Kategori:62°N ved å bruke categoryinfo.
Mediawiki er slik satt opp at det er en tung operasjon å hente informasjon om de enkelte medlemmene i en kategori. En alternativ metode er derfor å hente ned listene som sier hva som er kategorisert i to kategorier og så gjøre snittet i nettleseren. For eksempel har vi spørringene Kategori:10°Ø og Kategori:62°N som igjen er for Alvdal. Disse må utvides med cmlimit i en virkelig situasjon. Dette kan gi mindre overførte data hvis ikke den ene kategorien er vesentlig mindre enn den andre. Hva som er tilstrekkelig mye mindre må påvises med analyser og vil endre seg over tid fordi mengden kategorier øker.