I sommer laget jeg denne oversikten over GSM-basestasjonene til Telenor, som ble publisert på NRKs nettsider.
Jeg legger inn noen linjer om hvordan jeg jobbet med Brennpunkts kart over Telenors basestasjoner. Kanskje noen har innspill til andre og bedre måter å løse ting på i fremtidige prosjekter?
1 Innhenting av data
Rådataene kommer fra Telenor, men utleveringen skjedde ikke frivillig. Vi begjærte innsyn i dataene med hjemmel i miljøinformasjonsloven.
Innsynsbegjæringen ble avslått, men miljøklagenemnda ga oss medhold, og påla teleselskapet å utlevere dataene.
Vi har i skrivende stund en tilsvarende klagesak gående mot NetCom, som også motsetter seg utlevering av informasjon om basestasjonenes plassering.
2 Konvertering av data
Dataene fra Telenor kom som en Excel-fil, med felter for kommune, navn, type, og desimalgrad. Denne konverterte jeg til en sql-fil for databaseimport.
3 Databasen
Jeg brukte MySQLs geospatial indexing for koordinatene til basestasjonene. Denne delen av MySQL er imidlertid svært mangelfull. PostgreSQL gir langt bedre muligheter dersom man tar i bruk PostGIS.
Mange av GIS-funksjonene i MySQL er ennå ikke implementert, for eksempel funksjonen for å regne ut avstand mellom to punkter, noe jeg trengte for å plukke ut nærmeste basestasjoner i forhold et gitt kartpunkt, samt geografisk avstand i kilometer mellom hver av dem.
Jeg fant denne presentasjonen, som beskriver en veldig hårete spørring for å returnere avstanden mellom to punkter i MySQL. Funker som bare det J
http://www.scribd.com/doc/2569355/Geo-Distance-Search-with-MySQL
4 XML-feeden
Et PHP-skript genererer en XML-feed med informasjon om basestasjonene innenfor et kartutsnitt. Klienten (flashapplikasjonen) rapporterer valgt kartutsnitt til PHP-skriptet, som returnerer et cachet utsnitt tilpasset området brukeren vil titte på.
Eksempel:
http://www.nrk.no/basestasjoner/list.php?bounds=18.80,69.70,19.12,69.60&z=9
Skriptet normaliserer (kvantiserer) det bestilte utsnittet, slik at de returnerte dataene alltid dekker et større område enn det utsnittet (viewport) brukeren ser på i øyeblikket. Dette for å begrense nettverkstrafikken og for å gjøre caching praktisk mulig.
Jeg har forsøkt å begrense størrelsen på individuelle XML-filer til under 300K. De fleste ligger nok på godt under 100K.
Klienten gjør en ny spørring mot databasen bare dersom brukeren har dratt kartet utenfor den leverte rammen.
5 Clustring av kartpunkter
I områder med stor tetthet av kartpunkter blir punktene samlet i klynger. Dette skjer server-side, i PHP-skriptet. Klienten rapporterer zoomnivået, noe som gjør det mulig å regne ut avstand i absolutte piksler mellom hvert punkt.
Punkter slås sammen dersom avstanden mellom dem er mindre enn 70 piksler. Informasjon om hvordan gjøre dette fant jeg et eksempel på her:
http://www.appelsiini.net/2008/11/introduction-to-marker-clustering-with-google-maps
Clustringen skjer altså server-side for å avlaste klientene. Dette er en tung rutine som drar fordel av server-side cacing. Client side clustering av kartpunktene ville ført til ulidelig treg responstid på lave zoomnivåer.
6 Caching
Bruker Zend Cache, hvor man enkelt kan swappe mellom memcached og file cache. Produksjonsmiljøet kjører med memcached og nyter godt av gode responstider, selv når trafikken er høy.
7 Google Maps for flash
Veldokumentert API her:
http://code.google.com/intl/no/apis/maps/documentation/flash/reference.html
Har ingenting i mot AJAX, men det blir for kronglete å styre med JS i publiseringsverktøyet vårt, som er Polopoly — derfor ble det Flash.
Bruker for øvrig Googles geocoding-tjeneste (ClientGeocoder-objektet) til stedsnavn-søket. Informasjonsknappen som søker opp basestasjoner rundt et gitt kartpunkt bruker dessuten Googles reverse geocoding-funksjon for å returnere stedsnavn fra et gitt koordinat.
8 Grafikk
Animerte kartikoner er laget i LightWave 3D. Ikke veldig utfordrende å lage noe som ligner på de rektangulære GSM-antenneboksene til Telenor.
Animasjonen ble lagt inn i en egen (bitte liten) flash-fil og kompilert til en frittstående swf som jeg deretter embeddet i hoved-flashen.
Størrelsen på den ferdige swf-en er 228 kB. Den inkluderer alt av grafikk, animasjoner og fonter. Flashappen bruker ikke andre eksterne ressurser enn Google Maps API-et samt XML-feeden fra vår egen MySQL-database.
Tags: Brennpunkt, databaser, dataprogrammering, Google Maps, Journalistikk, kart, miljøinformasjonsloven
[...] ba om oversikten for å kunne utvide kartet over GSM-senderne ytterligere. Foreløpig inkluderer det kun Telenor sine [...]
Hei
Flott jobba.
Kan med sikkerhet si at minst en base mangler som jeg kan se fra mitt hus.
Dette er en Netcom base som ble satt opp sommer/høst 2009.
Så hva gjør du for å holde kartet oppdatert med nye stasjoner.
Fra hva tidspunkt er rådata laget.
En funksjon for å bare vise netcom eller telenor hadde også vært fint.
Kartet viser heller ikke om det er en eller flere sendere i en mast, og heller ikke retningen senderen peker, som er viktig når en skal se på stråling og dekning.
Hei. Kartet på Brennpunkt-sidene inneholder kun GSM-stasjoner. Basen du viser til, betjener trolig en av de andre mobilteknologiene (UMTS/3G etc.). Vi kommer ikke til å oppdatere kartet jevnlig, men Post- og Teletilsynet jobber med en tilsvarende kartløsning nå – hvor du kan se alle senderne i landet. Den bli trolig publisert på nettet i løpet av kort tid.
Morsomt, men uten 3G sendere blir jo ikke dette noe mer enn et morsomt prosjekt…. Skal man få et kart for å avdekke noe med stråling blir jo dette meningsløst uten å samle alle type basesastjoner.
Blir dermed spennende å se hva PTT kommer opp med.
Hvis du ønsker å gjøre filtreringen av punkter som er i nærheten av hverandre mer effektivt på server siden, i SQL, så sjekk ut postgis funksjonen ST_SnapToGrid. Da slipper du å gjøre dette i php kode (Du burde absolutt brukt postgresql!
.
Sjekk ut denne demo’en som jeg har laget som kan gjøre noe tilsvarende (laget i postgresql istedenfor mysql): http://sanderm.no/google_maps_vg_no_demo/ (Har også lagt ved kildekode)
Andre forskjeller på min og din løsning er at jeg ikke cacher noe data i php (noe jeg kanskje burde gjort om behovet var der).
Og istedenfor å bruke xml feeds for komunikasjonen mellom server og klient så laster jeg inn punktene med data som allerede er i javascript format (så klienten slipper å gjøre om formatet på dataene).
Takk for bra innspill.
Jeg skulle definitivt ønske meg Postgres/PostGIS, men foreløpig er det MySQL som gjelder for oss. Og de geografiske funksjonene i MySQL er foreløpig veldig dårlige.
Med den trafikken kartet vårt har hatt de siste dagene, er caching en absolutt nødvendighet. Memcached er vår venn. Det drar unna det aller meste
Du mener json i stedet for xml? Kartet er skrevet i ActionScript (Flash) – som har svært god støtte for XML.
Nei. Mener ikke json. Mener at et php script rett og slett spytter ut feks: loaddata(1,2,3); Som da kjøres direkte i javascript ved å kjøre:
var newScript = document.createElement(’script’);
newScript.type = ‘text/javascript’; newScript.src = url;
Hvordan det blir i flash vet jeg ikke.