memo pfc defusers.salleurl.edu/~xavier.canaleta/memories/albertvelasco_pfc.pdf · figura 10....

Abstract

Aquest treball pretén realitzar un estudi del sistema GPS, però centrat concretament en l’anàlisi de tracks realitzats durant la pràctica del senderisme. Aquesta anàlisi té per objectiu extreure la màxima informació dels tracks per tal de convertir finalment aquesta en coneixement valuós pels usuaris.

Per tal de reafirmar els coneixements assolits en l’estudi teòric, s’implementarà una aplicació amb un doble objectiu: per una banda que l’usuari que pengi els tracks pugui obtenir informacions rellevants d’aquest i, per altra banda, que tota aquesta informació sigui accessible per tota una comunitat d’usuaris fent créixer així el volum de coneixement emmagatzemat.

Finalment, també s’ha dotat a l’aplicació d’un mòdul que permetrà la realització de recomanacions de rutes als usuaris en funció del seu perfil i de les seves preferències.

Resum

Aquest treball emmarcat dins de l’anàlisi i compartició de rutes de muntanya té per objectiu proposar un conjunt de millores respecte el conjunt d’eines existents que realitzen funcions similars a la que es presenta. Aquestes millores es troben emmarcades en la possibilitat d’extreure cert coneixement de les rutes.

La primera de les millores guarda relació amb la creació d’una ràtio que ens permetrà mesurar la dificultat d’una ruta. Aquesta, malgrat és una característica que es troba lligada a la forma física de cada individu, és calculable a partir de l’anàlisi detallada del track. En aquest treball es proposen i s’avaluen diverses tècniques per avaluar aquesta dificultat fent ús d’informacions exclusivament extretes del track com són la distància, el desnivell, l’altura a la qual discorre una ruta, etc.

La segona de les aportacions que es proposen consisteix en la possibilitat de que l’aplicació permeti realitzar recomanacions als usuaris en funció de les rutes prèviament realitzades, així com també a partir de l’objectiu fixat per aquest (mantenir la dificultat, disminuir-la o augmentar-la). Per a la implementació d’aquest recomanador s’analitzaran diverses tècniques relacionades amb la Intel�ligència Artificial amb l’objectiu d’escollir aquella que ens permeti realitzar recomanacions de forma més fiable i d’acord amb els objectius marcats.

Agraïments

Poder realitzar un treball que barregés les meves 2 passions la tecnologia i la muntanya ha estat un somni fet realitat. Ha estat un camí llarg i dur, des de la concepció inicial de la idea fins a la implementació i presentació d’aquesta però ha valgut la pena, i més fer-ho amb gent que com jo estima i necessita la muntanya per viure.

M’agradaria agrair en primer lloc als meus pares que ja des de ben petit ens portessin d’excursió i que ens inculquessin que la vida és com pujar un cim, que malgrat és dur un cop ets dalt reps la teva recompensa. Amb el lliurament d’aquest treball em sento com si estigues a dalt d’un cim.

M’agradaria agrair al meu germà la seva ajuda per resoldre els petits entrebancs matemàtics que han anat sorgint durant tot el treball, així com també per ser un dels infatigables company de travesses.

Voldria agrair també tota la ajuda rebuda tan per part del meu ponent en Xavi Canaleta com en David Vernet que malgrat no ésser el ponent ha actuat com a tal. Gràcies als 2 per totes les hores que m’heu dedicat, totes les vostres idees i innumerables cops de mà que m’heu donat. Aquest projecte és vostre també.

Tampoc voldria oblidar-me d’en Pablo Ros per la seva ajuda amb la configuració i ús del Framework, gràcies per instruir-me en la Web del segle XXI.

També m’agradaria agrair tota l’ajuda rebuda per part d’en Francesc Babot per ser uns dels principals subministradors de tracks, i per ser un dels beta-testers de l’aplicació.

I per últim també m’agradaria donar les gràcies a totes aquelles persones que m’han animat, ajudat i orientat durant tot el treball, gràcies a tots.

1

Índex

1. Introducció ................................................................................................................ 7

2. Descripció conceptual de l’entorn de treball .............................................................. 9

2.1. Introducció .......................................................................................................... 9

2.2. El GPS ............................................................................................................... 9

2.2.1. Introducció ................................................................................................... 9

2.2.2. Tracks GPS ............................................................................................... 11

2.3. Marxes Oficials i Rutes de muntanya ............................................................... 13

2.4. Índex Dificultat .................................................................................................. 14

2.5. Recomanador ................................................................................................... 16

2.5.1. K-Nearest Neighbours ................................................................................ 16

2.5.2. Case-Based Reasoning ............................................................................. 18

3. Estat de l’art ............................................................................................................ 21

3.1. Introducció ........................................................................................................ 21

3.2. Aplicacions Web ............................................................................................... 21

3.2.1. Wikiloc ....................................................................................................... 21

3.2.2. Garmin Connect ......................................................................................... 22

3.2.3. Mis Rutas ................................................................................................... 24

3.2.4. Wandermap ............................................................................................... 25

3.2.5. Magnalox ................................................................................................... 26

3.2.6. Everytrail .................................................................................................... 27

3.2.7. Altres aplicacions ....................................................................................... 28

3.3. Aplicacions Instal�lables ................................................................................... 28

3.3.1. CompeGPS ................................................................................................ 28

3.3.2. OziExplorer ................................................................................................ 30

3.3.3. SportsTracks .............................................................................................. 31

3.3.4. Altres aplicacions ....................................................................................... 32

4. Especificació dels Requisits de Software ................................................................ 33

4.1. Introducció ........................................................................................................ 33

4.1.1. Propòsit del document ............................................................................... 33

4.1.2. Abast ......................................................................................................... 33

4.1.3. Definicions, sigles i abreviacions ................................................................ 33

4.1.4. Referències ................................................................................................ 33

4.1.5. Estructura del document ............................................................................ 34

4.2. Descripció general ............................................................................................ 34

4.2.1. Perspectiva del producte ............................................................................ 34

4.2.1.1. Interfícies ............................................................................................. 35

4.2.1.2. Operacions ja existents ....................................................................... 35

2

4.2.2. Funcions del producte ................................................................................ 36

4.2.3. Característiques de l’usuari ........................................................................ 36

4.2.4. Restriccions/Limitacions ............................................................................. 36

4.2.5. Suposicions i dependències ....................................................................... 37

4.2.6. Línies de futur ............................................................................................ 37

4.3. Requeriments específics .................................................................................. 37

4.3.1. Requeriments funcionals ............................................................................ 37

4.3.2. Usabilitat .................................................................................................... 38

4.3.3. Fiabilitat ..................................................................................................... 38

4.3.4. Rendiments ................................................................................................ 39

4.3.5. Suport ........................................................................................................ 39

4.3.6. Altres requeriments .................................................................................... 39

4.4. Annexos ........................................................................................................... 40

4.4.1. Diagrama d’activitats .................................................................................. 40

4.4.2. Diagrama de casos d’ús ............................................................................. 41

5. Disseny i implementació del Portal de Gestió ......................................................... 42

5.1. Introducció ........................................................................................................ 42

5.2. Metodologia de desenvolupament .................................................................... 42

5.2.1. Introducció ................................................................................................. 42

5.2.2. Instal�lació de l’entorn de desenvolupament .............................................. 45

5.2.3. Estructura genèrica de les capes MVC ...................................................... 49

5.2.4. Casuístiques Framework ........................................................................... 54

5.3. Decisions de disseny ........................................................................................ 61

5.3.1. Càlcul de la distància entre coordenades GPS .......................................... 61

5.3.2. Càlcul del percentatge de desnivell ............................................................ 62

5.3.3. Definició de l’índex de dificultat .................................................................. 63

5.3.3.1. Càlcul de l’Índex de dificultat ............................................................... 67

5.3.4. Elecció generador perfil de ruta ................................................................. 74

5.3.5. Correccions del track ................................................................................. 75

5.3.6. Tipus d’informació a carregar en l’aplicació ................................................ 76

5.3.7. Implementació del Recomanador ............................................................... 78

5.4. Disseny Tècnic ................................................................................................. 80

5.4.1. Diagrama Entitat Relació ........................................................................... 80

5.4.2. Diagrama de Paquets ................................................................................ 81

6. Resultats ................................................................................................................. 82

6.1. Introducció ........................................................................................................ 82

6.2. Resultats de l’Índex de dificultat ....................................................................... 82

6.2.1. Resultats Índex 1 ....................................................................................... 82

6.2.2. Resultats de l’Enquesta de qualitat de l’índex 1 ......................................... 82

3

6.2.3. Resultats Índex 2 ....................................................................................... 83

6.2.4. Resultats Índex 3 ....................................................................................... 83

6.2.5. Comparativa de l’Índex proposat amb altres Índexs ................................... 84

6.3. Tests de l’Aplicació ........................................................................................... 88

6.3.1. Tests dels tracks ........................................................................................ 88

6.3.2. Tests dels formularis .................................................................................. 90

7. Cost de realització del projecte ............................................................................... 91

8. Conclusions ............................................................................................................ 92

9. Línies de futur ......................................................................................................... 95

10. Bibliografia ............................................................................................................ 97

Annex ......................................................................................................................... 99

1. Enquesta sobre la qualitat de l’Índex ................................................................... 99

4

Índex de figures

Figura 1. Format del fitxer GPX .................................................................................. 13

Figura 2. Classificació dels CBR’s .............................................................................. 18

Figura 3. Fases d’un CBR ........................................................................................... 19

Figura 4. Captura de Wikiloc ....................................................................................... 21

Figura 5. Captura del detall d’una ruta de Garmin Connect......................................... 23

Figura 6. Captura del perfil d’una ruta de Garmin Connect ......................................... 23

Figura 7. Captura del detall d’una ruta de Mis Rutas .................................................. 24

Figura 8. Captura del detall d’una ruta de Wandermap ............................................... 25

Figura 9. Captura del detall d’una ruta de Magnalox ................................................... 26

Figura 10. Captura del reproductor de l’eina en la modalitat slideshow ....................... 27

Figura 11. Captura del reproductor de l’eina en format stadistics ................................ 27

Figura 12. Captura de CompeGPS ............................................................................. 29

Figura 13. Captura d’OziExplorer ................................................................................ 30

Figura 14. Captura d’SportsTracks en la vista d’Activitat Diària .................................. 31

Figura 15. Diagrama de desplegament ....................................................................... 34

Figura 16. Diagrama d’activitats .................................................................................. 40

Figura 17. Diagrama de casos d’ús ............................................................................. 41

Figura 18. Arquitectura de software MVC ................................................................... 42

Figura 19. Configuració del fitxer de hosts .................................................................. 46

Figura 20. Configuració del fitxer de Virtual Hosts ...................................................... 47

Figura 21. Codi mínim del Controlador ....................................................................... 50

Figura 22. Codi mínim del Model ................................................................................ 51

Figura 23. Exemple de Select usant ADOdb ............................................................... 51

Figura 24. Exemple d’insert usant ADOdb .................................................................. 51

Figura 25. Exemple de Delete usant ADOdb .............................................................. 52

Figura 26. Exemple d’update usant ADOdb ................................................................ 52

Figura 27. Codi mínim de la Vista ............................................................................... 53

Figura 28. Controlador de la casuística bàsica............................................................ 55

Figura 29. Model de la casuística bàsica .................................................................... 56

Figura 30. Vista de la casuística bàsica ...................................................................... 56

Figura 31. Configuració del fitxer dispatcher.config ..................................................... 57

Figura 32. Configuració del fitxer base.config ............................................................. 57

Figura 33. Resultat de la casuística bàsica ................................................................. 57

Figura 34. Resultat casuística Google Maps ............................................................... 59

Figura 35. Cerca amb AJAX ....................................................................................... 60

Figura 37. Triangle Rectangle ..................................................................................... 61

Figura 45. Estudi dels percentatges de desnivell positiu ............................................. 64

Figura 46. Estudi dels percentatges de desnivell negatiu ............................................ 65

Figura 47. Estudi comparatiu de pesos ....................................................................... 67

Figura 48. Comparativa propostes ponderació............................................................ 69

Figura 51. Problemes de càlcul de la ràtio hores nit .................................................... 72

Figura 53. Perfil de ruta generat amb Jpgraph ............................................................ 74

Figura 54. Perfil de ruta generat amb flot .................................................................... 75

Figura 55. Diagrama Entitat Relació ........................................................................... 80

Figura 56. Diagrama de paquets ................................................................................. 81

Figura 58. Comparativa Índex proposat respecte l’Índex de la FEEC ......................... 86

Figura 59. Comparativa Índex proposat respecte l’Índex de la UTMB ......................... 86

Figura 60. Comparativa Índex proposat respecte l’Índex IBP ...................................... 88

5

Índex de taules

Taula 1. Resum de les desviacions dels receptors GPS ............................................. 11

Taula 2. Resultats de l’Índex IBP ................................................................................ 15

Taula 3. Característiques de l’usuari ........................................................................... 36

Taula 4. Estudi dels percentatges de desnivell mitjos ................................................. 66

Taula 5. Estudi dels percentatges de desnivell mitjos separats en franges ................. 66

Taula 6. Comparativa propostes ponderació ............................................................... 69

Taula 7. Equivalències de l’Índex de dificultat proposat amb el llenguatge Natural ..... 74

Taula 8. Resultats índex de dificultat 1 ....................................................................... 82

Taula 9. Resultats índex de dificultat 2 ....................................................................... 83

Taula 10. Resultats índex de dificultat 3 ..................................................................... 83

Taula 11. Comparativa d’índexs ................................................................................. 84

Taula 12. Comparativa d’índexs normalitzada ............................................................ 85

Taula 13. Comparativa Índex IBP ............................................................................... 87

Taula 14. Cost aproximat del projecte ......................................................................... 91

Taula 15. Enquesta qualitat de l’índex proposat .......................................................... 99

6

Índex de fórmules

Fórmula 1. Definició de l’Índex FEEC ......................................................................... 14

Fórmula 2. Definició de l’Índex UTMB ......................................................................... 14

Fórmula 3. Distància Euclidiana .................................................................................. 16

Fórmula 4. Distància de Chevychev ............................................................................ 16

Fórmula 5. Distància de Manhattan ............................................................................ 17

Fórmula 6. Distància de Camberra ............................................................................. 17

Fórmula 7. Distància Euclidiana amb pesos ............................................................... 17

Fórmula 8. Llei Esfèrica dels cosinus .......................................................................... 61

Fórmula 9. Teorema de Pitàgores ............................................................................... 62

Fórmula 10. Càlcul aproximat del percentatge de desnivell ........................................ 62

Fórmula 11. Càlcul del percentatge de desnivell ......................................................... 62

Fórmula 12. Conversió d’un desnivell expressat en percentatge a graus .................... 63

Fórmula 13. Exemple de conversió d’un desnivell expressat en percentatge a graus . 63

Fórmula 14. Conversió d’un desnivell expressat en graus a percentatge .................... 63

Fórmula 15. Exemple de conversió d’un desnivell expressat en graus a percentatge . 63

Fórmula 16. Índex proposat 1 ..................................................................................... 71



Fórmula 19. Normalització d’atributs ........................................................................... 84

Portal intel�ligent de rutes i marxes de muntanya

7

1. Introducció

Amb la popularització de les activitats de muntanya durant els darrers anys, ha sorgit la necessitat de compartir informació de les rutes i Internet s’ha convertit en el lloc idoni per fer-ho degut a què és gratuït i fàcilment accessible pel públic en general, el qual pot obtenir la informació d’una ruta 24x7.

Abans de que els GPS’s es popularitzessin, la informació que es podia compartir d’una ruta es limitava a una descripció del recorregut i algunes fotografies d’aquest; és a dir, una simple ressenya.

Actualment, però, gràcies al GPS’s, disposem de moltes més dades com la localització exacta de la ruta sobre un mapa, la distància, el desnivell, el temps emprat i un llarg etcètera de variables que ens donen una visió molt més completa d’una ruta.

Amb tota aquesta informació disseminada, l’únic que falta és fer ús de les eines necessàries per tal de ser capaços de crear un portal que permeti que diversos individus no connectats a priori entre sí puguin compartir tota aquesta informació de forma senzilla i gratuïta. Aquest tipus de portals existeixen i tenen una gran popularitat (com són el cas de wikiloc, magnalox, everytrail, etc), degut al fet que els usuaris envien voluntàriament les seves rutes, per tal de compartir-les amb la resta de la comunitat.

Analitzant aquests portals, observem que malgrat tenen un gran nombre d’opcions interessants, (com són el fet que permeten pujar tracks1 en múltiples formats, pujar i comentar fotos, visualitzar la ruta en un mapa i mostrar certs detalls tècnics) la seva principal funció es limita a compartir informació de les rutes amb una bona interfície; és a dir, la informació que s’extreu del track es mostra directament sense extreure’n coneixement i és, en aquest punt, on centrarem el nostre treball.

La primera de les mancances que observem està relacionada amb la mesura de la dificultat d’una ruta, aquest tipus de portals no ens donen informació relativa a la duresa d’una ruta.

Nosaltres en aquest treball proposem un índex de dificultat d’una cursa a peu que serà calculat a partir de diferents aspectes com: la distància, el desnivell, l’altura en la qual transcorre la ruta, el nombre de Kilòmetres amb fort desnivell, etc.

Molts d’aquests paràmetres els obtindrem del track GPS, però caldrà realitzar un complex procés fins arribar a obtenir l’Índex, ja que caldrà corregir certes incoherències en el mateix, obtenir el desnivell acumulat de pujada i de baixada, obtenir les distàncies amb un determinat % de pujada i, finalment, obtenir la distribució dels trams de pujada.

Un cop fet això, obtindrem un Índex, però caldrà passar per una fase de proves i d’acceptació per part d’un conjunt d’experts per poder validar que l’Índex obtingut es correspon amb la duresa real de la ruta.

A partir de tota aquesta informació serem capaços de determinar de forma precisa la dificultat d’una ruta, tenint la capacitat de realitzar comparacions de dificultat fidedignes entre diferents rutes.

La segona gran mancança d’aquest tipus de portals, consisteix en el fet que aquests no permeten realitzar recomanacions de rutes als usuaris.

1 Fitxer que conté les posicions geogràfiques per les quals discorre una ruta.


8

Per tal d’implementar un recomanador de rutes, s’aplicaran tècniques d’Intel�ligència Artificial, que ens permetran realitzar recomanacions de rutes a l’usuari; aquestes es faran en base al perfil de l’usuari.

Per últim, i malgrat no es troba lligat directament amb cap millora respecte altres eines, es farà ús d’un Framework així com d’una metodologia de programació lligada amb aquest que ens permetran, per una banda, desenvolupar un codi degudament estructurat i, per altra, disposar d’un conjunt d’eines que facilitaran la tasca del programador.

El nostre treball per tant, té per objectiu la realització d’un portal que permeti afegir, compartir i visualitzar rutes a peu: fent especial ressò en l’extracció de coneixement d’un track, permetent-nos avaluar la dificultat real d’una cursa així com també realitzar recomanacions sempre en funció de les preferències dels usuaris.


9

2. Descripció conceptual de l’entorn de treball

2.1. Introducció

El projecte que presentem gira al voltant de les activitats de muntanya però tot el que afecta al projecte va molt més enllà d’un simple recull de caminades on-line.

Aquest girarà al voltant de 4 eixos:

• El GPS. Aquest sistema ens permetrà obtenir informació detallada de qualsevol activitat realitzada a l’exterior.

• Marxes oficials. Ens permetran enriquir el conjunt de dades que conformaran la nostra BBDD.

• Índex de dificultat. Ens permetrà obtenir informació de la dificultat de forma ràpida i precisa.

• Recomanador. A partir de les dades obtingudes de marxes i tracks serem capaços d’extreure coneixement valuós per als usuaris sent capaços de poder recomanar rutes als usuaris.

Tot seguit es detallaran les bases conceptuals de cadascun dels punts anteriorment esmentats.

2.2. El GPS

2.2.1. Introducció

El GPS (Global Positioning System) formalment conegut com a NAVSTAR-GPS és un sistema global que ens permet determinar la posició de qualsevol objecte arreu del món amb una precisió de metres. Aquest sistema està composat per:

• Xarxa de satèl�lits: Conjunt de 24 satèl�lits operatius (en trobem 3 més de recolzament) que es troben en òrbita a més de 20.000 km de la terra. Tal i com es veurà més endavant es necessitarà la cobertura en tot moment de com a mínim 3 satèl�lits per tal de poder obtenir resultats de posició fiables.

• Estacions terrestres: Encarregades d’enviar informació de control i manteniment als diferents satèl�lits.

• Receptors GPS: Són els aparells necessaris per captar les senyals dels satèl�lits GPS. Trobem 2 tipus diferents de receptors GPS:

o Estàndard: És el tipus més usat pel seu econòmic preu i per la seva comoditat d’ús (són lleugers, poden ser alimentats a través de bateries o piles).

o Diferencial o DGPS: És un tipus que té per objectiu l’obtenció de dades molt fiables. Aquest sistema està basat en el principi de que 2 receptors GPS pròxims tindran un error en el càlcul de la posició similar. Per tal de corregir l’error causat per la “Disponibilitat Selectiva” es fa ús d’una estació de referència que calcula la diferència entre la posició obtinguda mitjançant GPS i la posició real obtinguda per altres mitjans. Un cop es coneix aquesta diferència aquesta es propagarà als receptors GPS pròxims que corregiran la seva posició.

Al llarg d’aquest estudi ens centrarem únicament en els receptors GPS estàndard, pel fet que són els dispositius més comunament en la pràctica d’activitats de lleure a l’aire lliure.


10

El sistema GPS està basat amb el càlcul de la posició del receptor GPS a partir de la triangulació amb diferents satèl�lits però aquest procés és més complex i es divideix en 4 etapes diferents:

1. Triangulació: Consisteix en descobrir on estem situats a partir de la comunicació amb com a mínim 3 satèl�lits. Aquesta comunicació a grans trets té per objectiu descobrir la distància de la qual estem de cadascun dels satèl�lits.

2. Càlculs de distància: El càlcul de la distància que ens separa dels satèl�lits es realitza a partir del càlcul del temps de propagació de les ones de ràdio. El càlcul d’aquest temps és complex degut a què la velocitat de propagació de les ones de ràdio és de 300.000km/seg. i la distància que ens separa dels satèl�lits és d’ aproximadament 20.000km el que fa que les mesures de temps estiguin a l’ordre de centèsimes de segon (Ex: 0,06 seg.). Degut a què càlculs de temps d’aquest ordre requereixen de rellotges molt precisos i cars, és necessari obtenir cobertura de com a mínim un quart satèl�lit encarregat de compensar les possibles errades de medició del rellotge del nostre receptor GPS.

3. Posició dels satèl�lits a l’espai: Per tal de realitzar els càlculs de distància amb els satèl�lits anteriorment esmentats necessitem conèixer la posició exacta dels satèl�lits a l’espai. Els satèl�lits estan ubicats en unes òrbites concretes on el càlcul de la posició d’aquest és molt precís. Les petites variacions en la posició d’aquests satèl�lits són corregides pel Departament de Defensa Americà.

4. Correcció dels Errors: Els càlculs de posició anteriorment esmentats es veuen afectats per diferents fonts d’errors que cal corregir degudament. Les fonts d’errors més comuns són:

1. Desviacions causades pel pas de les ones per l’atmosfera: El pas de les ones de radio per l’atmosfera fa que aquestes perdin certa velocitat i per tant afecta en els càlculs de temps de propagació de les ones. Aquests desviacions depenen de certes característiques de la ionosfera que canvien diàriament. Aquestes desviacions es corregeixen predient les desviacions que es produeixen de mitjana.

2. Desviacions causades pel pas de les ones per la terra: Quan les ones arriben a la terra aquestes també poden patir certes desviacions causades per rebots causats per obstruccions d’edificis, muntanyes, etc.

3. Desviacions causades per petites errades dels satèl�lits: Malgrat la gran precisió dels satèl�lits aquests no són perfectes i també poden provocar certes desviacions.

4. Desviacions causades per l’angle d’incisió dels satèl�lits: L’angle que formen els satèl�lits amb el receptor GPS també és un factor que causa certa desviació. Així si el receptor GPS agafa cobertura de GPS molt pròxims a l’espai la medició serà menys precisa que si ho fes de GPS més distants.

5. Desviacions causades per errades intencionades: Per tal d’evitar que els receptors GPS puguin ser usats per fins terroristes el Departament de Defensa va incorporar una política anomenada “Disponibilitat Selectiva” que té per objectiu afegir certes errades en la mesura de les distància dels servidors.

Aquestes desviacions anteriorment assenyalades es poden resumir en la següent taula:


11

Fonts d’error Desviació mitja per

satèl�lit (m.) Rellotge del satèl�lit 1.5

Errors orbitals 2.5 Ionosfera 5

Troposfera 0.5 Soroll en el receptor 0.3

Soroll Fantasma 0.6 Disponibilitat Selectiva 30

Taula 1. Resum de les desviacions dels receptors GPS

Altres errades del GPS

Fins el moment hem analitzat el sistema GPS i els errors que el sistema porta de per si. Però trobem altres errades que malgrat no són causades pel sistema GPS directament també afectaran l’anàlisi posterior. Aquestes errades són:

• Posició física del receptor GPS: La posició física en la que estigui el receptor afectarà a la qualitat de recepció d’aquest. Aquest tret vindrà condicionat alhora pel tipus de GPS, si té una antena externa o no, etc.

• Errades durant els primers minuts del track: Durant els primers minuts de recepció del senyal dels satèl�lits es solen produir errades degudes a canvis sobtats d’altura. Aquests canvis són deguts a la falta de cobertura del quart satèl�lit que és l’encarregat de donar-nos informació relativa a l’altura. Fins que no tinguem cobertura d’aquest quart satèl�lit tindrem la posició correcta però l’altura serà inconsistent.

2.2.2. Tracks GPS

Un track és un fitxer normalment de text generat per un GPS o per un software de gestió de tracks que conté informació exhaustiva d’un camí.

A partir d’un track podem extreure grans quantitats d’informació d’un camí, i per aquest motiu resulta tan interessant gravar-los, compartir-los, editar-los, etc.

Les informacions més típiques que podem extreure d’un track són:

• Waypoints o punts de pas • Distancia • Altura Max/Min/Mitja • Desnivell Positiu/Negatiu • Temps emprat Total/En moviment • Velocitat mitja/màxima • Poblacions properes

Donada la recent popularització dels receptors GPS per a la realització d’activitats a l’exterior trobem múltiples fabricants de GPS així com múltiples software de gestió de tracks i mapes.

Per aquests motius exposats, avui en dia podem trobar tracks en múltiples formats, els més comuns són:

• GPX 1.0 (.gpx) • GPX 1.1 (.gpx) • CompeGPS (.trk, .wpt) • OziExplorer (.plt .wpt)


12

• Garmin Training Center (.crs, .tcx) • Garmin Mapsource (.gdb, .mps) • Magellan Mapsend (.trk, .wpt) • FAI/IGC Flight Recorder Data Format (.igc) • Geocaching (.loc) • Google Earth (.kml, .kmz)

Degut a aquesta gran diversitat de formats sorgeix la necessitat d’homogeneïtzació de la informació, i el format GPX que aparegué l’any 2002 sorgeix amb l’objectiu de convertir-se en l’estàndard actual d’intercanvi d’informació generada per aparells GPS.

Aquest format està caracteritzat per fer ús d’XML ja de per si considerat com un estàndard per a el intercanvi d’informació estructurada entre diferents plataformes. Alhora GPX compta amb l’avantatge que és un estàndard completament obert, i per aquest motiu trobem multitud d’aplicacions de gestió d’aquest tipus de fitxers.

Degut a què en l’actualitat el format GPX s’ha convertit en el format més comunament usat, aquest treball estarà basat únicament en la gestió d’aquest format.

Estructura dels fitxers GPX

Tot fitxer GPX seguirà la següent estructura, malgrat no és obligatori que contingui tots els camps:

• Metadata: Conté informació relacionada amb l’autor del track, copyright, nom i descripció de la ruta realitzada, etc.

• Wpt: Abreviació de waypoint. Conté informació dels waypoints d’una ruta. Els camps més comuns d’un waypoint són:

o Latitud i Longitud: Permeten situar el waypoint en un punt exacte de la superfície terrestre

o Nom del waypoint o Altura o Descripció del waypoint o Temps de pas

• Trk: Abreviació de Track. Format per un llistat ordenat de trackpoints (trkpt) que descriuen un camí. Els camps més comuns d’un trackpoint són:

o Latitud i Longitud: Permeten situar el trackpoint en un punt exacte de la superfície terrestre

o Altura o Temps de pas

• Rte: Abreviació de ruta. Conté una llista ordenada de waypoints (tècnicament reben el nom de route points, rtept) que condueixen a un destí. Els camps més comuns d’un rte són:

o Nom o Descripció o Rtept: Conté informació comuna amb un waypoint.


13

A tall d’exemple un fitxer GPX tindrà el següent format:

Figura 1. Format del fitxer GPX

2.3. Marxes Oficials i Rutes de muntanya

Les marxes oficials són rutes preparades per una organització en una localització i dates preestablertes, en les quals tota persona pot inscriure-s’hi pagant una quantitat fixada de diners. Tota marxa podrà tenir diferents edicions, i aquestes no necessariament han de respectar el traçat original ni els horaris de la 1a edició de la marxa.

Actualment trobem una gran quantitat de marxes oficials arreu del país, però és degut a què la majoria d’aquestes marxes estan organitzades per organitzacions independents entre sí, que la informació d’aquestes es troba disseminada en múltiples pàgines web.

Amb l’objectiu de que els marxaires puguin trobar tota la informació de les marxes centralitzada han sorgit pàgines com ropits.com, on l’usuari pot trobar un calendari de les marxes oficials classificades per múltiples criteris.

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> <gpx creator="MapSource 6.13.7" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance … > <metadata> <link href="http://www.garmin.com"> <text>Garmin International</text> </link> <time>2009-10-04T17:13:48Z</time>

<bounds maxlat="41.6405238" maxlon="2.5647739" minlat="41.6026831" minlon="2.4950752"/>

</metadata> <wpt lat="41.6281554" lon="2.5523261"> <ele>175.5651855</ele> <name>Avit 1</name> <desc>04-OCT-09 8:34:17</desc> </wpt> <wpt lat="41.6386469" lon="2.5346899"> <ele>367.3468018</ele> <name>Avit 2</name> <desc>04-OCT-09 9:08:01</desc> </wpt>

… <trk> <name>XIX marxa popular arenys de munt</name> <trkseg> <trkpt lat="41.6090119" lon="2.5403415"> <ele>75.6008301</ele> <time>2009-10-04T05:27:02Z</time> </trkpt> <trkpt lat="41.6090167" lon="2.5404273"> <ele>115.9761963</ele> <time>2009-10-04T05:28:24Z</time> </trkpt> <trkpt lat="41.6090272" lon="2.5404493"> <ele>119.3408203</ele> <time>2009-10-04T05:28:46Z</time> </trkpt> … </trkseg> </trk> </gpx>


14

Aquest tipus de pàgines però, no ens eviten haver de consultar la pàgina oficial de la marxa quan necessitem descarregar el track de la cursa, analitzar-ne el perfil, o observar-ne el mapa per analitzar per quines poblacions discorre la marxa.

Per tots aquests fets veiem una clara necessitat de millora d’aquest tipus de pàgines. Pel que fa a les rutes, aquestes es podrien definir com excursions per la muntanya no organitzades per cap entitat.

Actualment, es troben aplicacions que permeten pujar rutes però cap que permeti realitzar una distinció entre les rutes i les marxes oficials.

2.4. Índex Dificultat

En el món del senderisme trobem la necessitat d’avaluar la dificultat d’una ruta amb un únic nombre (índex), en comptes de fer-ho amb multitud de dades com són l’altitud, la distància, el desnivell positiu, el negatiu, etc.

Donada aquesta necessitat, algunes organitzacions de renom dins del món del senderisme han proposat els seus índexs de dificultat, com són:

• L’índex de la FEEC (Federació d’Entitats Excursionistes de Catalunya): Índex en el qual intervé la distancia i el desnivell acumulat d’una ruta. No es té en compte aspectes com l’altura o el nombre de kilòmetres amb un cert percentatge de desnivell.

�� = �� (��)10 + 1� + �� . ��. (�)1000 + 1�

Fórmula 1. Definició de l’Índex FEEC

• L’índex de la UTMB (Ultra Trail MontBlanc): Índex en el qual intervé la distància i el desnivell positiu d’una ruta. No es té en compte aspectes com l’altura o el nombre de kilòmetres amb un cert percentatge de desnivell.

�� = �� (��) + �� . ! . (�. )100 �

Fórmula 2. Definició de l’Índex UTMB

• L’índex IBP (Interactive Bicycling Parameters): A diferència dels anteriors índexs, l’IBP no es troba lligat amb cap organització de renom sinó que va ésser creat per conjunts d’entusiastes del ciclisme. L’IBP, però, es tracta d’un Índex específic per l’avaluació de la dificultat de rutes amb bicicleta de carretera i de muntanya.

Aquest índex es calcula realitzant una anàlisi del track. Aquesta anàlisi però, es realitza tenint en compte les limitacions / característiques del ciclisme i, per tant, els resultats obtinguts en algunes rutes poden distar molt dels obtinguts utilitzant altres índexs específics per a la pràctica del senderisme.

Aquesta diferència és deguda al fet que l’avaluació d’una ruta realitzada a peu o amb bicicleta presenta un conjunt de diferències rellevants que tot seguit esmentem:

1. Els pendents màxims que té en compte l’IBP són del 30%; la resta de pendents, amb un percentatge superior al 30%, són considerats errors pel fet que es considera que un pendent superior al 30% no és assolible amb


15

bicicleta. En el cas del senderisme en general es tenen en compte pendents molt més elevats.

2. L’IBP considera que els canvis de direcció vertical i horitzontal, així com els graus de gir, afegeixen una dificultat a la ruta. Aquesta informació no és rellevant en el cas del senderisme ja que no afegeix dificultat a una ruta canviar de direcció ni realitzar girs de qualsevol grau.

3. L’IBP considera que els recorreguts plans suposen un petit esforç pel fet que recórrer un tram pla suposa poc esforç amb bicicleta. En canvi, fent referència a la pràctica del senderisme, el desplaçament per un tram pla representa més esforç que fer-ho amb bicicleta.

Malgrat com s’ha vist, l’IBP presenta un conjunt important de diferències respecte als índexs que avaluen la dificultat de les rutes a peu. Tot i això, segueix essent un índex de referència pel fet que realitza una anàlisi rigorosa del track.

Tal i com es pot veure en la següent taula, l’anàlisi del track utilitzant aquesta eina ens dona un gran quantitat d’informació:

Taula 2. Resultats de l’Índex IBP

De l’estudi dels diversos índexs de dificultat de rutes de muntanya se’n desprèn una clara necessitat de crear un índex que, basant-se amb els avantatges dels diversos índexs analitzats permeti analitzar de forma precisa la dificultat de les rutes de muntanya, realitzades a peu.


16

2.5. Recomanador

Un recomanador té per objectiu suggerir una ruta a un usuari en funció del seu perfil i, si es desitja en funció d’altres fonts d’informació escollides per l’usuari com són: per dificultat, per proximitat, per temps, per distància etc.

Trobem infinitat de tècniques relacionades amb la Intel�ligència Artificial que ens permeten realitzar classificacions de dades com són els algorismes ID3 i C4.5, les Xarxes Neuronals, Naïve Bayes, els KNN’s (K-Nearest Neighbours), etc.

Algunes d’aquestes tècniques però, tenen un inconvenient important degut al fet que requereixen construir un model previ per poder realitzar classificacions. En canvi les tècniques englobades dins de la família de Instance Based Learning o Lazy Learners no requereixen fer-ho. Aquestes tècniques reben aquest nom pel fet que, només en el moment que hagin de classificar un nou cas examinaran la resta de casos.

És degut al fet que aquests mètodes no requereixen construir cap model previ, que aquest estudi únicament es centrarà en els algoritmes de la família Instance Based Learning.

Actualment, trobem 2 subfamílies d’algoritmes relacionades amb Instance Based Learning que ens permeten la recomanació d’informació als usuaris. Aquests algoritmes reben el nom de KNN i CBR i s’analitzaran en els següents apartats.

2.5.1. K-Nearest Neighbours

K-Nearest Neighbours, o més conegut com a KNN, és l’algorisme més bàsic dels que analitzarem en els següents apartats. Aquest algorisme a partir d’una nova instància realitza una cerca dels K veïns més pròxims a aquesta fent ús d’una funció de distància donada.

En aquesta cerca hi intervindran un conjunt de paràmetres que tot seguit detallem:

• Elecció de la K: L’elecció de la K vindrà condicionada per cada nou tipus de problema, per això no trobarem una K vàlida per tots els casos.

• Elecció de la funció de distància: De la mateixa manera que passava amb la K, l’elecció d’una funció de distància també depèn de les característiques de cada nou problema. Trobem un ampli conjunt de funcions de distància; les més rellevants són:

"(�, $) = %&(�' − $'))*'+,

Fórmula 3. Distància Euclidiana

"(�, $) = max,0'0* |�' − $'| Fórmula 4. Distància de Chevychev


17

"(�, $) = &|�' − $'|*'+,

Fórmula 5. Distància de Manhattan

"(�, $) = & |�' − $'||�' + $'|*'+,

Fórmula 6. Distància de Camberra

o Diferents tipus d’atributs: Cada nou problema pot tenir diferents tipus

d’atributs com són continus, discrets i desconeguts. Serà necessari aplicar diferents funcions de distància en funció del tipus d’atributs.

o Diferents rangs de valors: És habitual que els diferents atributs del nostre problema tinguin rangs diferents. Per tal de solucionar aquest problema i fer que aquest tret no afecti al resultat caldrà normalitzar tots els atributs.

Un cop vistos els diferents paràmetres que afecten a un algorisme KNN, també cal considerar diverses variacions d’aquest, com són:

o Distance-Weighted KNN: Els veïns pròxims a la nova instància tindran una major pes que les instàncies llunyanes. Aquest mètode dona una major robustesa a la classificació en el cas de presència d’instàncies amb soroll.

o Attribute-Weighted KNN: Consisteix en assignar pesos als atributs en funció de la importància d’aquests. Aquests pesos podran ser assignats fent ús de 2 mètodes:

� A partir d’un expert � A partir d’un algorisme que els ajusti de forma automàtica

Un exemple de funció de distància vàlida per aquest tipus d’algoritme és la funció euclidiana amb pesos:

"(�, $) = %& 2' (�' − $'))*'+,

Fórmula 7. Distància Euclidiana amb pesos

Tot seguit es detallaran els avantatges i inconvenients en l’ús d’aquest tipus d’algoritmes.

Avantatges:

• L’aprenentatge no té cap cost. • Comparat amb altres tècniques d’IA, els KNN són altament precisos.

Inconvenients:

• Els KNN simplement obtenen dades, no hi ha un aprenentatge en aquest procés.

• No es produeix una generalització de casos. • No es construeix un model global.


18

• En cas de tenir moltes instàncies amb molts atributs el rendiment d’aquest tipus d’algoritmes és baix.

2.5.2. Case-Based Reasoning

Case-Based Reasoning o altrament conegut com a CBR es podria definir com “un paradigma de resolució de problemes que empra coneixement específic de situacions prèvies anomenades casos” (Sancho A., 2008).

El CBR es basa en la classificació de casos a partir de la identificació d’altres prèviament classificats; es tracta d’un sistema incremental pel fet que cada nou cas serà emmagatzemat en una memòria de casos facilitant així la tasca de classificació de casos futurs similars als que es troben en la memòria de casos.

Malgrat que l’ús del CBR en aquest estudi es centrarà en la classificació de nous casos, els CBR’s són utlitzats en multitud d’aplicacions que tot seguit es detallen (Sancho A., 2008, Fornells A., 2007):

• Configuració de sistemes: Consisteix en identificar i agrupar elements d'un entorn per aconseguir un funcionament discret.

• Disseny: A partir d’un conjunt de requeriments es defineixen els mètodes o tècniques que millor acompleixen les necessitats plantejades.

• Planificació: Basat en situacions on cal produir un conjunt d’accions per tal d’aconseguir un objectiu

• Interpretació basada en casos: En base a un conjunt de regles cal realitzar interpretacions que ajudin a trobar relacions entre aquestes.

• Adquisició de coneixement: L’objectiu és ajudar a un l’expert d’un domini a extraure i classificar coneixement del domini per facilitar la seva tasca.

Segons Fornells, en l’actualitat ha sorgit una nova forma de classificar els CBR’s que combina una classificació purista d’aquests que fa referència a com s’adquireix el coneixement del problema amb una més actual que fa referència al tipus d’aprenentatge d’aquests sistemes.

Aquesta nova classificació es resumeix en la següent taula on es diferencien clarament els 2 tipus de classificacions anteriorment esmentades:

Figura 2. Classificació dels CBR’s2

2 Figura extreta de Fornells A., 2007


19

Tal i com s’observa en l’anterior figura, el tipus de CBR que millor s’adapta a l’objectiu del nostre problema és un “CBR orientat a cerca” degut al fet que el coneixement que obtenim del problema serà exclusivament de la BBDD i el nombre de casos que es necessiten emmagatzemar en la memòria de casos pot ser petit o fins i tot inexistent.

De forma genèrica, un CBR es troba format per 4 fases que tracten d’imitar la forma que tenim els humans de resoldre un problema, comparant aquest amb altres casos similars i, un cop resolt, identificar aquest com un nou problema que hem sabut resoldre d’una forma concreta.

Aquestes 4 fases venen resumides en el següent esquema:

Figura 3. Fases d’un CBR3

Tot seguit s’analitzaran en detall aquestes 4 fases (Sancho A., 2008):

• Fase de Recuperació o Retrieve: Fase que consisteix en la recuperació de tots els casos similars al nou cas que es troben emmagatzemats en la memòria de casos.

• Fase de Reutilització o Reuse: Fase que consisteix en l’adaptació dels casos recuperats en la fase anterior com a solució del nostre problema.

• Fase de Revisió o Revision: Fase en què es valida la solució proposada per part d’un expert o d’un algorisme adequat.

• Fase d’emmagatzematge o Retain: Fase en què es produeix l’emmagatzemament del nou cas prèviament validat a la memòria de casos. Trobem diverses polítiques d’emmagatzemament:

o DiffTest: No s’emmagatzemen els nous casos; simplement es fa ús de la memòria de casos com a repositori on consultar casos prèviament introduïts.

o DiffSim: Únicament s’emmagatzemen els nou casos en cas de que aquests siguin diferents segons la funció de similitud.

o DiffClass: S’emmagatzema el nou cas si aquest s’ha emmagatzemat incorrectament; és una barreja de les 2 anteriors polítiques.

3 Figura extreta de Fornells A., 2007


20

Tal i com s’observa en l’anterior esquema, i malgrat que la memòria de casos no és considerada dins de cap de les 4 anteriors fases, aquesta juga un paper important en tot el procés, degut a què és gràcies a aquesta que es produeix el procés d’aprenentatge. En la literatura trobem multitud de representacions diferents d’aquesta com són vectors, grafs, arbres, etc.

La representació de la memòria de casos anirà íntimament lligada amb el tipus de problema i alhora amb les limitacions d’aquest, que poden ser limitacions temporals (es necessita una determinada representació per accelerar el procés) o limitacions d’espai (es necessita una determinada representació per tal de minimitzar l’espai que ocupa emmagatzemar cada nou cas).

Tot seguit es detallaran els avantatges i inconvenients en l’ús d’aquest tipus d’algoritmes.

Avantatges:

• Es produeix aprenentatge en les diferents fases que conformen un CBR, com: o Aprenentatge de prototipus. o Aprenentatge de la millor funció de distància.

• Es produeix una generalització de casos. • Permet adaptar tècniques de clustering per reduir el nombre de casos a

analitzar. • Es poden realitzar configuracions i ajustaments en totes les seves fases així

com en la pròpia memòria de casos.

Inconvenients:

• Complex d’implementar. • Requereix d’un expert o d’un algorisme que ens validi les solucions proposades

en la fase de revisió.


21

3. Estat de l’art

3.1. Introducció

En l’actualitat trobem diverses aplicacions que permeten realitzar anàlisi de tracks i compartir aquesta informació entre una comunitat d’usuaris. Tot seguit analitzarem les aplicacions similars més rellevants, tot estudiant-ne els punts forts i fluixos.

Dintre d’aquest conjunt d’aplicacions en distingim 2 tipus clarament diferenciats, aquelles a les quals s’accedirà via web, i aquelles que caldrà instal�lar i executar en local. Seguidament analitzarem en detall ambdós tipus d’eines tot destacant-ne els seus avantatges i inconvenients més importants.

3.2. Aplicacions Web

Trobem un gran nombre d’eines Web degut al fet que són molt còmodes ja que no cal cap tipus d’instal�lació ni sistema operatiu concret per poder-ne fer ús. Aquest tipus d’aplicacions ens permeten accedir a les nostres dades des de qualsevol lloc sense necessitat de transferir informació de les rutes, i això les fa un tipus d’aplicacions àmpliament usades. Tot seguit s’analitzaran en detall les aplicacions web més rellevants.

3.2.1. Wikiloc

Wikiloc 4és una pàgina molt coneguda per tota la comunitat excursionista en general i pels amants dels esports a l’aire lliure en particular amb més de 100.000 usuaris que comparteixen més de 120.000 rutes diferents. Wikiloc començà l’any 2006 i avui en dia es podria considerar la pàgina líder de compartició de rutes a nivell mundial. És una eina concebuda per ser molt genèrica i aquest tret com veurem seguidament presenta alguns avantatges però també alguns inconvenients.

Figura 4. Captura de Wikiloc

Punts forts eina: 4 http://www.wikiloc.com


22

• Permet pujar els tracks amb un gran nombre de formats diferents, com són: gpx, trk, plt, crs, gdb, igc, loc, kml, kmz, etc.

• És una eina molt genèrica i permet la compartició i cerca de rutes relacionades amb múltiples disciplines esportives (escalada, rutes a peu, amb bici, esquiant, etc) o de lleure en general (rutes en 4x4, quad, moto, vaixell, etc).

• Integrada completament amb Google Maps. Té la possibilitat de veure els mapes en múltiples formats.

• Permet la descàrrega del track en múltiples formats (GPX, KML, CRS) així com també permet limitar el nombre de punts del track (només amb el format GPX).

• Permet realitzar cerques pel nom dels punts d’interès (waypoints) de qualsevol ruta pujada.

• És una eina molt usable i amb una interfície molt atractiva. • Mostra rutes pròximes a l’actual. • Permet pujar fotos i vídeos associats a la ruta. • Permet que qualsevol usuari registrat pugui comentar qualsevol ruta. • Permet visualitzar imatges de Panoramio sobre el mapa de ruta. • Permet crear rutes sense track (manualment).

Punts fluixos de l’eina:

• No ens dona moltes dades importants per la pràctica de qualsevol esport com són les velocitats totals i en moviment, poblacions properes inici i fi de ruta, altura mitjana, etc.

• Trobem diferències notables entre els càlculs de distància i/o desnivells entre aquesta eina i altres eines d’anàlisi de tracks com CompeGPS o OziExplorer.

• Pel fet que és una eina molt genèrica actualment no disposa d’un índex de valoració de la dificultat d’una ruta calculat a partir d’una anàlisi del track.

• El mapa de perfil de ruta no mostra altures ni distàncies. • No es realitza una diferenciació de les rutes iguals però pujades per diferents

usuaris. • No es realitza cap diferenciació entre rutes i marxes oficials. • No permet compartir la ruta a través de xarxes socials tipus Facebook. • No disposa d’un reproductor de la ruta.

3.2.2. Garmin Connect

Eina de Garmin5 que permet l’anàlisi, gestió i compartició de rutes. Es tracta d’una eina orientada específicament a dispositius Garmin. L’objectiu de l’eina és el de gestionar els entrenaments dels usuaris, fent especial ressò en intentar aconseguir certs objectius.

5 http://connect.garmin.com/


23

Figura 5. Captura del detall d’una ruta de Garmin Connect

Figura 6. Captura del perfil d’una ruta de Garmin Connect

Punts forts de l’eina:

• Eina amb una interfície molt agradable i intuïtiva. Tots els gràfics i perfils estan realitzats amb Flash fet que els hi dona una aparença agradable i vistosa.

• Permet obtenir de forma senzilla la distància, altitud, velocitat i freqüència cardíaca de qualsevol punt de la ruta.

• Permet recuperar i pujar fàcilment les dades de la darrera ruta que es trobi al GPS.

• Disposa d’un calendari on es situen les diverses activitats realitzades. • Permet la realització d’informes. • Permet realitzar una supervisió del progrés de l’usuari. • Permet assignar reptes de distància, temps, freqüència o calories. • Permet compartir una ruta a través de Facebook, Twitter, Blogger, Wordpress,

MySpace, etc. • Permet carregar i exportar rutes en format TCX, GPX o Google Earth. • Permet crear rutes sense track (manualment). • Disposa d’un reproductor de la ruta que ens permet recórrer tota la ruta a

diferents velocitats i mostrant diferents informacions (altura, velocitat, freqüència cardíaca, etc).


24


• No fomenta la compartició de rutes, no permet penjar fotos, comentaris, etc. • No permet la recomanació de rutes. • No es calcula cap índex de dificultat d’una ruta. • No es realitza una diferenciació de les rutes iguals però pujades per diferents

usuaris. • No es realitza cap diferenciació entre rutes i marxes oficials.

3.2.3. Mis Rutas

Mis Rutas 6 es tracta d’una web àmpliament coneguda i usada per la comunitat biker Espanyola. L’eina permet compartir rutes GPS realitzades específicament amb Mountain Bike. Es tracta d’una eina molt senzilla però que permet realitzar gran nombre d’accions com visualitzar el perfil de l’etapa, descarregar el track amb múltiples formats, visualitzar la ruta sobre Google Maps, etc.

L’eina està dissenyada per tal de que els usuaris que no disposin d’un receptor GPS també puguin treure profit de les rutes penjades. Per fer-ho, trobem informacions d’utilitat com són els comentaris de l’autor i de tota la comunitat d’usuaris, la dificultat, els mapes, etc.

Figura 7. Captura del detall d’una ruta de Mis Rutas

Punts forts:

• Mostra multitud de dades tècniques com són temps, distància, desnivells, velocitats, % de desnivells, etc.

• Mostra l’índex de dificultat IBP associat a la ruta. • Permet visualitzar el perfil de la ruta. • Permet visualitzar la ruta sobre Google Maps. • Realitza classificacions de les rutes més populars, dels usuaris amb més rutes,

del país on es troben les rutes, etc. • Realitza classificacions de les darreres rutes pujades, actualitzades, en

disseny. • Permet separar les rutes d’1 sol dia de les rutes de gran recorregut (múltiples

dies).

6 http://www.misrutas.net


25

Punts fluixos:

• Té una interfície molt pobre i poc usable. • És una eina específica per a la pràctica de Mountain Bike. • No es realitza una diferenciació de les rutes iguals però pujades per diferents

usuaris. • No permet compartir la ruta a través de xarxes socials tipus Facebook. • No disposa d’un reproductor de la ruta.

3.2.4. Wandermap

Wandermap 7 és una eina desenvolupada per una empresa d’Alemanya anomenada Toursprung. Aquesta empresa auto definida com a desenvolupadora de software social per a viatgers, compta amb múltiples eines similars a wandermap però especialitzades en compartició de rutes en bici (bikemap), en patins (inlinemap), en moto (mopedmap) i per córrer (runmap). Wandermap es tracta d’una eina específica per a la compartició de rutes a peu.

Aquesta eina disposa d’una interfície agradable i intuïtiva però permet mostrar molt poques dades tècniques de la ruta, alhora Wandermap no és una web gens popular a Catalunya i es disposen de molt poques rutes properes.

Figura 8. Captura del detall d’una ruta de Wandermap

Punts forts:

• Disposa d’una interfície molt agradable i usable • Permet pujar rutes sense estar registrat. • Permet dibuixar rutes manualment sobre un mapa. • Permet compartir informació de les rutes a través de Facebook. • Permet afegir imatges i comentaris a la ruta. • Permet pujar i exportar tracks en format gpx i kml.

Punts fluixos:

• Mostra molt poques dades tècniques de la ruta, únicament la distància i el desnivell acumulat.

• Disposa de poques rutes a Catalunya.

7 http://www.wandermap.net


26

• No realitza el càlcul d’un Índex de dificultat de la ruta. • No permet recomanar rutes. • No disposa d’un reproductor de la ruta.

3.2.5. Magnalox

Magnalox 8 (Magnificient Log) es tracta d’una eina de compartició de rutes GPS genèrica. Aquesta disposa d’una interfície molt pobra i poc intuïtiva però disposa de diverses funcionalitats que la converteixen en una eina de referència.

L’eina disposa d’un cercador molt potent que ens permet cercar rutes a partir de múltiples paràmetres com són tipus d’activitat, país, duració, llargada, ubicació, etc.

Una altra funcionalitat rellevant es tracta del reproductor de rutes que ens situa cada punt del mapa sobre el perfil de la ruta i alhora ens mostra diferents comentaris associats a punts concrets de la ruta.

Figura 9. Captura del detall d’una ruta de Magnalox

Punts forts:

• Disposa d’un gran nombre de rutes d’arreu del món • Permet reproduir el recorregut de la ruta animat, on s’observa el mapa, i les

gràfiques de desnivells i velocitat. • Permet cercar rutes per una gran quantitat de criteris com país, regió, activitat,

duració, distància, autor, etc. • Permet pujar imatges i vídeos associats amb la ruta. • Permet pujar i exportar tracks en els formats gpx, kmz, ovl. • Disposa d’una opció que facilita la impressió de la ruta.

Punts fluixos:

• Té una interfície molt pobre i poc usable. • Mostra poques dades tècniques de la ruta. • No permet compartir la ruta amb a través de xarxes socials tipus Facebook. • No permet recomanar rutes.

8 http://www.magnalox.net


27

3.2.6. Everytrail

Everytrail 9 es tracta d’una eina que permet la compartició de rutes a l’aire lliure però fent més ressò en la forma de presentar la informació que en la quantitat d’informació tècnica de la ruta.

L’eina disposa d’un reproductor de la ruta realitzat en Flash que ens va mostrant les imatges de forma geo-localitzada. L’eina alhora permet mostrar estadístiques de la ruta a mesura que aquesta s’està reproduint mostrant informacions com la distància, l’altitud i la velocitat.

Figura 10. Captura del reproductor de l’eina en la modalitat slideshow

Figura 11. Captura del reproductor de l’eina en format stadistics

9 http://www.everytrail.com


28

Punts forts:

• Disposa d’un gran nombre de rutes d’arreu del món • Permet reproduir el recorregut de la ruta animat, on s’observa el mapa, imatges

i estadístiques de velocitat, altura, etc. • Disposa d’un cercador avançat que permet cercar rutes per país, activitat, nom,

durada, llarga, etc. • Disposa de versions de l’eina per a tot tipus de dispositius mòbils com Iphone,

Android, Windows Mobile i Blacberry. • Permet pujar rutes a partir d’un track o bé dibuixant-les de forma manual. • Permet pujar imatges associades amb la ruta. • Permet compartir informació de rutes a partir de Facebook, Twitter, Blogger,

Myspace, etc. • Permet pujar tracks en qualsevol format. • Permet exportar tracks en format GPX. • Permet visualitzar la ruta a Google Earth. • Mostra rutes relacionades amb l’actual.

Punts fluixos:

• Mostra poques dades tècniques de la ruta. • No permet recomanar rutes. • No realitza el càlcul d’un Índex de dificultat de la ruta. • No es realitza cap diferenciació entre rutes i marxes oficials.

3.2.7. Altres aplicacions

Altres aplicacions similars que per les seves característiques no hem considerat oportú descriure en detall són:

• Bici Rutas: Aplicació que permet la compartició de rutes GPS únicament per Mountain Bike. Mostra poques dades de la ruta, únicament distància, desnivell i perfil.

• Motionbased: Es tracta d’una divisió de Garmin International. A data 31/09/2009 Motionbased no s’accepten càrregues de dispositius Garmin degut a què es centralitzarà tota la informació d’aquests tipus de dispositius al portal Garmin Connect.

3.3. Aplicacions Instal�lables

Aquest tipus d’aplicacions malgrat són similars a les aplicacions web acostumen a disposar d’un major nombre de funcionalitats com són el cas d’edició i unió de tracks, agregació de waypoints, visualització de mapes, etc.

Cal fer notar però, que aquest tipus d’aplicacions no permeten la compartició de rutes sinó que únicament permeten editar tracks prèviament descarregats d’un receptor GPS o d’una pàgina de compartició de rutes.

Tot seguit s’analitzaran les aplicacions instal�lables més rellevants.

3.3.1. CompeGPS

CompeGPS es tracta d’una eina desenvolupada per una empresa catalana que desenvolupa software que permet gestionar tota la informació relativa a l’orientació de multitud d’activitats a l’aire lliure.


29

Entre el conjunt de productes de CompeGPS destaquem CompeGPS Land (útil per a la pràctica d’esports terrestres), ComeGPS Air (útil per a la pràctica d’esports aeris) i CompeGPS TwoNav que combina la gestió d’activitats terrestres amb la orientació a través de carrers i carreteres.

Ens centrarem exclusivament en l’anàlisi de CompeGPS Land per guardar més relació amb l’estudi que estem realitzant.

El principal objectiu de l’eina és l’edició de tracks. Altres funcionalitats rellevants de l’eina són l’extracció d’informació tècnica del track i la generació de mapes i gràfics de rutes.

Figura 12. Captura de CompeGPS

Punts forts:

• Disposa d’una interfície intuïtiva i amigable. • Permet carregar multitud de tracks sobre un mapa i editar-los tots alhora. • Permet carregar diversos mapes alhora i unir-los fent ús de geo-referències. • Permet obrir i guardar tracks amb multitud de formats. • Permet obrir i guardar fitxers de rutes. • Permet obrir i guardar fitxers de waypoints amb multitud de formats. • Permet obrir i guardar mapes i relleus 3D amb multitud de formats. • Permet exportar el mapa i la ruta com a pàgina web o com a imatge.

Punts fluixos:

• Eina de pagament. • Eina complexa de controlar pel seu gran nombre de funcions malgrat disposi

d’una interfície amigable.


30

3.3.2. OziExplorer

Aplicació amb més de 5 anys d’història que es podria considerar pionera en el món de la gestió de tracks GPS. En l’actualitat trobem 3 versions diferents d’aquesta eina. Tot seguit en detallarem les seves característiques:

1. OziExplorer, versió de l’eina que permet gestionar mapes i tracks fent ús de PC.

2. OziExplorerCE, versió per a dispositius mòbils tipus Pocket PC. 3. OxiExplorer 3D, versió 3D que permet rotar en totes les direccions dins del

mapa 3D.

Ens centrarem exclusivament en l’anàlisi d’OziExplorer per guardar més relació amb l’estudi que estem realitzant.

Aquesta eina es podria considerar molt similar a CompeGPS en quant al tipus de funcionalitats de les que disposa ja que també permet editar de tracks, i generar mapes o gràfiques d’aquests.

Figura 13. Captura d’OziExplorer

Punts forts:

• Permet realitzar tracking en temps real fent ús d’’un portàtil i un GPS connectat a ell.

• Permet obrir i guardar tracks amb multitud de formats. • Permet obrir i guardar fitxers de rutes. • Permet obrir i guardar fitxers de waypoints amb multitud de formats. • Permet obrir i guardar mapes i relleus 3D amb multitud de formats. • Permet exportar el mapa i la ruta com a pàgina web o com a imatge • Permet obtenir informació de GIS.

Punts fluixos:

• Eina de pagament. • Eina amb una interfície molt pobra i passada de moda. • Eina complexa de controlar pel gran nombre de funcionalitats que té.


31

• No permet mostrar un track sense disposar d’un mapa d’aquella zona prèviament carregat.

• No permet carregar mapes al GPS.

3.3.3. SportsTracks

Eina que permet l’anàlisi, gestió i compartició de rutes. L’objectiu de l’eina és el de gestionar els entrenaments i les competicions dels usuaris, fent especial ressò en intentar aconseguir certs objectius.

L’eina està clarament enfocada en aconseguir un cert rendiment esportiu, permetent analitzar dades com l’evolució del pes i la freqüència cardíaca i per aquest motiu l’anàlisi que es realitza del track no és tan detallada com en altres aplicacions.

Figura 14. Captura d’SportsTracks en la vista d’Activitat Diària

Punts forts de l’eina:

• Eina gratuïta, malgrat s’accepten donatius. • Eina amb una interfície molt agradable i intuïtiva. • Permet obtenir de forma senzilla la distància, altitud, velocitat i freqüència

cardíaca de qualsevol punt de la ruta. • Permet recuperar i pujar fàcilment les dades de la darrera ruta que es trobi al

GPS. • Disposa d’un calendari on es situen les diverses activitats realitzades. • Permet la realització d’informes (logbook’s). • Permet realitzar una supervisió del progrés de l’usuari. • Permet carregar i exportar rutes en múltiples formats entre els que es troben

GPX, KML, fitlog, TCX, etc. • Permet crear rutes sense track (manualment). • Permet realitzar gràfics amb multitud de variables diferents.


32


• No realitza una anàlisi exhaustiva de les dades del track. • La compartició de les rutes no és efectiva, únicament es pot veure la última ruta

pujada per cada usuari i no se’n pot descarregar el track.

3.3.4. Altres aplicacions

Altres aplicacions similars que per les seves característiques no hem considerat oportú descriure en detall són:

• Perfils: Aplicació d’anàlisi de tracks específica per a la pràctica d’esports amb bicicleta. Permet realitzar una detallada anàlisi del track i disposa d’un gran nombre d’opcions de configuració que la fan una eina útil per a l’anàlisi de tracks realitzats en la pràctica de qualsevol activitat a l’aire lliure.


33

4. Especificació dels Requisits de Software

4.1. Introducció

Aquest document té com a propòsit especificar els requisits funcionals i no funcionals del sistema a desenvolupar així com el seu abast. S’ha escrit basant-se en les directrius de l’estàndard “IEEE Std 830-1998 Recommended Practice for Software Requirements Specifications”

El document va dirigit al client i al futur equip de desenvolupament.

4.1.1. Propòsit del document

El propòsit d’aquest document consisteix en recollir de la forma més precisa possible les funcionalitats de l’aplicació. Està dirigit principalment a la persona/es responsables de realitzar l’adequat seguiment al projecte. Alhora el document també serà d’utilitat com a base per documentar el software que volem implementar per facilitar-ne la seva comprensió.

El document serà degudament revisat abans de ser aprovat.

4.1.2. Abast

L’objectiu d’aquest projecte és el de crear un portal que ens permeti pujar i compartir rutes de muntanya a peu entre una comunitat d’usuaris. El valor afegit que representa aquest portal, i el que el farà diferent de tots els existents és el fet de que aquest ens permeti realitzar recomanacions de rutes a usuaris.

4.1.3. Definicions, sigles i abreviacions

Definicions:

• Login: Acció d’iniciar sessió, amb un nickname i un password.

• Logout: Acció de tancar la sessió.

• Nickname: Identificador d’usuari amb el que ens autenticarem al sistema.

• Password: contrasenya d’usuari

• Usuari Loguejat: Usuari que s’ha autenticat al sistema.

• Usuari no Loguejat: Usuari que no s’ha autenticat al sistema

Sigles:

• ERS: Especificació de Requeriments de Software

• SRS: Software Requirements Specification..

4.1.4. Referències

IEEE Std 830-1998 Recommended Practice for Software Requirements Specifications. The Institute of Electrical and Electronics Engineers, Inc. ISBN 0-7381-0332-2.


34

4.1.5. Estructura del document

El present document consta de tres apartats principals. Tot seguit les descriurem:

• Apartat 1: En aquest apartat trobarem la introducció, on s’indica l’objectiu del documento i es delimita l’abast del projecte.

• Apartat 2: En aquest apartat trobarem una descripció general, on es descriu el sistema a desenvolupar especificant les principals funcionalitats, les característiques dels usuaris i les restriccions.

• Apartat 3: En aquest apartat trobarem els requisits específics, on s’especifiquen en detall tan els requeriments funcionals del sistema així com els no funcionals.

4.2. Descripció general

4.2.1. Perspectiva del producte

Seguidament veurem el diagrama de desplegament de la nostra aplicació:

Figura 15. Diagrama de desplegament

En l’anterior diagrama observem com trobem 3 nodes clarament diferenciats, el Workstation i els servidors Web i de BBDD.

S’observa com la connexió entre la Workstation i el Servidor Web es farà fent ús del protocol http, i la connexió entre el Servidor Web i el Sistema Gestor de Bases de Dades fent ús del protocol TCP/IP.


35

4.2.1.1. Interfícies

1. Interfícies del sistema • Sistema Operatiu: Windows XP SP2

2. Interfícies de l’usuari

1) Aspectes estructurals

Degut a què es tracta d’una aplicació basada en la localització geogràfica de rutes de muntanya, trobarem diferents interfícies en les que es mostraran mapes i en les que serà important que l’usuari sigui capaç d’interactuar amb aquestes de forma simple.

Cal destacar altres interfícies en les que es mostrarà el desnivell d’una determinada ruta sobre les quals l’usuari també haurà de poder interactuar-hi fàcilment.

2) Aspectes d’accessibilitat

La aplicació haurà de ser fàcilment usable per qualsevol tipus d’usuari. Es tindrà molt en compte que l’aplicació sigui molt usable i intuïtiva, fent especial ressò en la claredat en la forma de presentar les dades així com en la possibilitat d’accedir en tot moment a qualsevol part de la pàgina.

3. Interfícies del hardware

El Servidor Web (Apache) usarà el port per defecte, 80 (HTTP). MySQL també usarà el port per defecte 3306.

4. Interfícies del software

Disposem de les següents interfícies de software:

• Apache HTTP Server: Ens permetrà servir als diferents clients les diferents pàgines web que conformen l’aplicació.

• PHP: Permetrà la execució de codi php en el servidor web. • MySQL: Permetrà l’emmagatzemament de les dades dels diferents usuaris,

de les rutes realitzades per aquests així com també de les metadades. • API de Google Maps: API que ens permetran mostrar l’itinerari seguit en

una ruta sobre un mapa. • API de Flot: API que ens permetrà pintar el perfil d’una ruta. • Sistema Operatiu: Windows XP XP2.

5. Interfícies de comunicacions

El servidor Web serà accessible mitjançant el protocol HTTP des de la xarxa Local. Totes les connexions es realitzaran mitjançant TCP/IP.

4.2.1.2. Operacions ja existents

No es requereixen operacions a realitzar per part de l’usuari.


36

4.2.2. Funcions del producte

El producte disposarà de les següents funcions:

1. Càrrega i emmagatzemament de tracks. 2. Càlcul de l’índex de dificultat d’una ruta. 3. Visualització de la informació d’un track, complementada amb informació

addicional d’una ruta. 4. Cerca de rutes. 5. Llistat de les Càrregues d’un usuari. 6. Registre Marxes fetes. 7. Recomanació de rutes al usuari fent ús de raonament basat en casos.

4.2.3. Característiques de l’usuari

Capacitat

Act

or

Cer

cad

or

Vis

ual

itza

do

r R

ute

s

Càr

reg

a tr

acks

Reg

istr

e M

arxe

s F

etes

Rec

om

anad

or

Ru

tes

Lli

stat

Mev

es

Càr

reg

ues

Visitant x x

Usuari Loguejat x x x x x x

Taula 3. Característiques de l’usuari

4.2.4. Restriccions/Limitacions

a) Les polítiques reguladores

Es tindrà en compte una política de privacitat de dades, degut a què l’aplicació emmagatzemarà dades personals de cada un dels usuaris que es registrin.

b) Les limitacions del Hardware

Es limitaran el nombre de connexions per tal d’evitar que baixi el rendiment de l’aplicació en cas de que es connectin un gran nombre d’usuaris.

c) Les Interfícies a altres aplicacions

Es limitarà el nombre de peticions a Google Maps.

d) Operacions en Paral�lel

No existeixen limitacions entre operacions.

e) Les funcions de la Auditoria

S’emmagatzemaran dades personals de tots els usuaris, el responsable d’aquestes dades serà l’administrador del sistema.


37

f) Les funcions de Control

Es portaran a cap els següents controls:

• Distància: 0 – 1000 km • Desnivell: 0 – 50.000m. • Dificultat: 0 – 500

g) Els requisits del llenguatge

L’aplicació estarà programada en PHP i per aquest motiu el servidor necessitarà tenir instal�lat el mòdul de PHP.

h) Els protocols senyalats

Usarem el protocol HTTP.

i) Requisits de Fiabilitat

S’assegurarà la consistència de la BBDD, degut a què tota la aplicació dependrà d’aquesta. S’haurà d’assegurar un 100% de fiabilitat de resposta de la BBDD.

j) Seguretat i consideracions de seguretat

Els passwords s’emmagatzemaran encriptats. Apart, es portarà a cap un log de totes les acciones realitzades pels usuaris amb l’objectiu de diagnosticar problemes.

4.2.5. Suposicions i dependències

Suposarem que el servidor tindrà instal�lat el sistema operatiu Windows XP SP2 així com també Apache HTTP Server 2.2 i MySQL 5.4.

4.2.6. Línies de futur

La principal línea de futur serà l’estudi de noves tècniques d’Intel�ligència Artificial que permetin obtenir millors resultats (millors recomanacions).

4.3. Requeriments específics

A continuació es descriuen els requeriments plantejats pels usuaris durant les reunions d’extracció de requeriments.

4.3.1. Requeriments funcionals

Aquesta subsecció de l’ERS especifica els requeriments funcionals. Aquests defineixen la expectativa de l’usuari en front al sistema. Aquests han estat descrits a un nivell essencial sense detallar els mecanismes informàtics requerits per tal de resoldre’l.


38

Per cadascun dels següents requeriments se’n donarà una descripció, es descriuran les dades necessàries per portar a cap l’acció i finalment es descriurà la sortida esperada del sistema.

• El sistema ha de permetre el registre de nous usuaris: o Serà necessari introduir les dades personals de l’usuari. o Un cop s’hagin introduït totes les dades i aquests s’hagin validat

satisfactòriament, l’usuari serà donat d’alta en el sistema. • El sistema ha de permetre que els usuaris registrats es loguegin:

o Serà necessari introduir el login i el password. o Si les dades són vàlides accedirem a la zona privada del sistema.

• El sistema ha de permetre que els usuaris loguejats, puguin fer logout o Cap entrada necessària. o Tornarem a la zona pública.

• El sistema ha de permetre la cerca de rutes: o Serà necessari introduir el nom de la ruta o de la zona. o Es realitzarà una cerca en la BBDD i es retornaran totes les rutes que

compleixin amb el criteri fixat. • El sistema ha de permetre la càrrega de rutes

o Serà necessari introduir el track de la ruta així com les dades complementaries a aquest (tipus de terreny, material necessari, etc)

o Un cop analitzat el track i introduïdes totes les dades complementàries s’inseriran les dades en la BBDD.

• Visualització de rutes o Serà necessari haver realitzat una cerca prèvia. o La visualització ens mostrarà la ruta dibuixada sobre un mapa.

• Recomanació de rutes o Serà necessari disposar d’un conjunt de rutes i d’uns criteris de

referència de l’usuari (si l’usuari es principiant o expert, l’edat, altres rutes...)

o El resultat serà una o diferents rutes que compleixin amb els criteris fixats per l’ usuari.

4.3.2. Usabilitat

Tot seguit assenyalarem un conjunt de normes que ens permetran millorar la usabilitat del nostre sistema:

o Ha de limitar-se l’ús de llistes desplegables en camps que tinguin més de 10 elements.

o Es desitjable que els camps de text de més d’una línia permetin l’edició (canviar tipus lletra, mida, etc) del text.

o Es desitjable que les cerques alfabètiques ignorin la diferència entre majúscules i minúscules. Això no es tindrà en compte en el cas que les dades a cercar hagin de diferenciar-se explícitament.

o Des de qualsevol pàgina s’haurà de poder accedir a la resta de pàgines de l’aplicació i de forma senzilla.

o L’aplicació haurà d’usar una paleta de colors així com unes fonts agradables a la vista.

4.3.3. Fiabilitat

o La fiabilitat del sistema s’assegurarà portant a cap Backup’s diaris de la BBDD i de les dades del servidor

o El Gestor de la BBDD està preparat per recuperar-se de tot tipus de fallades.


39

4.3.4. Rendiments

o Es limitaran el nombre de connexions per evitar que baixi el rendiment de l’aplicació.

o S’optimitzarà el codi per tal d’obtenir un millor rendiment.

4.3.5. Suport

o La BBDD estarà preparada per tal de que sigui fàcil la traducció a múltiples idiomes.

4.3.6. Altres requeriments

a) Requeriments/Restriccions de la implementació: L’aplicació estarà basada en llenguatge PHP i s’usarà l’API de Google Maps. Per tal d’usar aquesta API, haurem d’estar prèviament donats d’alta.

b) Requeriments/Restriccions de la interfície: No trobem requisits de la interfície.

c) Requeriments/Restriccions del software: Trobem un conjunt de requeriments i restriccions d’ús de la API de Google Maps.

d) Requeriments/Restriccions de la base de dades: La BBDD haurà de permetre l’emmagatzemament de punts geogràfics. MySQL permet el tractament d’aquest tipus de dades. Cal tenir en compte que la Base de dades haurà de ser accessible 24x7 i ha d’estar preparada per recuperar-se de fallades.

e) Requeriments/Restriccions de comunicació: El servidor haurà de ser accessible tant des de la xarxa interna com a través d’Internet. El servei serà 24x7.

f) Requeriments/Restriccions legals: Haurem de complir amb els requisits de les llicències de la API de Google Maps així com també amb els de les llicències d’ús d’Apache HTTP Server i MySQL.


40

4.4. Annexos

4.4.1. Diagrama d’activitats

Figura 16. Diagrama d’activitats

Com es pot observar en el diagrama, en el cas que un usuari no es loga únicament serà capaç de realitzar cerques i visualitzar el detall de les rutes.

En canvi, quan un usuari si que es loga apart de poder cercar i visualitzar el detall de rutes, podrà realitzar càrregues de tracks, registrar marxes i sol�licitar recomanacions de rutes.

.


41

4.4.2. Diagrama de casos d’ús

Figura 17. Diagrama de casos d’ús

Com es pot observar en el diagrama de casos d’ús, a l’aplicació hi accediran 2 tipus d’usuaris. Els usuaris no loguejats que tindran un accés limitat a aquesta i per altra banda, els usuaris loguejats que podran accedir a totes les opcions de la aplicació.


42

5. Disseny i implementació del Portal de Gestió

5.1. Introducció

En aquest apartat es descriurà tot el procés de disseny de l’eina. En una primera part es descriurà la metodologia de desenvolupament seguida, tot descrivint-ne la seva instal�lació i ús. En una segona part es descriuran les diferents decisions de disseny que s’han hagut de prendre durant el desenvolupament de l’eina relacionades amb el càlcul de distàncies, l’elaboració d’un índex de dificultat així com també la implementació d’un recomanador.

5.2. Metodologia de desenvolupament

5.2.1. Introducció

La metodologia de desenvolupament usada ha girat al voltant de 2 pilars claus, l’ús d’un Framework i d’un sistema de control de versions.

Descripció del Framework

Per tal de desenvolupar tot el projecte ens hem recolzat d’un Framework anomenat Framework Lite. L’ús d’aquest Framework ens dóna un conjunt de beneficis que tot seguit s’esmenten:

• Permet desenvolupar de forma més segura, degut al fet que certs “forats negres” de PHP com és l’ús de les variables globals $_GET i $_POST es troben degudament protegits.

• Disposa de la llibreria Smarty incorporada, aquesta llibreria es troba en la capa de presentació i facilita molt la tasca de desenvolupament de plantilles.

• Permet desenvolupar codi seguint el patró MVC. Aquesta arquitectura de software consisteix en separar tot el codi en 3 capes clarament diferenciades: o Model: Component on es realitza tot el tractament de les dades. Les

consultes sobre la BBDD es faran exclusivament en aquest mòdul. o Vista: Altrament conegut com a capa de presentació. És el component amb

el qual els usuaris interactuaran. Aquest component està dissenyat exclusivament fent ús de Smarty.

o Controlador: És el component que interactua amb el Model i la Vista. Alhora aquest component serà l’encarregat de respondre als events de l’usuari.

Figura 18. Arquitectura de software MVC


43

• Permet desenvolupar aplicacions de forma genèrica degut al fet que disposa d’un conjunt de llibreries que ens permeten tenir portabilitat amb diferents BBDD’s, servidors de correu, etc. Aquestes llibreries són:

o AdoDB: Llibreria que facilita la connexió i realització de consultes amb una Base de Dades. AdoDB permet interactuar amb múltiples BBDD’s diferents com són MySQL, PostreSQL, Informix, Oracle, etc d’una forma genèrica. És a dir la sintaxi de connexió o consulta és comuna amb qualsevol BBDD fent ús d’aquesta llibreria.

o Php Mailer: API que simplifica el procés d’enviament de mails a través de PHP.

Tot seguit s’assenyalaran altres aspectes a considerar en l’ús d’aquest Framework:

o Estructura de directoris fixada: Com ja comentàvem anteriorment aquest Framework segueix un patró MVC, i per aquest motiu trobem definida una estructura de directoris com la següent.

o Engine: Motor del Framework o Instances: Guarda una còpia de cadascun dels projectes actius.

Cada una de les instàncies contindrà: � Config: Fitxers de configuració � Htdocs: Carpeta pública on guardarem CSS, JS, HTML, etc. � Model: Directori on trobarem els models � Controller: Directori on trobarem els controladors � Templates: Directori on trobarem les vistes � Templates_c: Cache de Smarty.

Els directoris model, controller i templates contindran tants subdirectoris com mòduls tingui el projecte. Per exemple com a norma general si definim un mòdul principal, trobarem aquest subdirectori en els 3 directoris anteriorment esmentats.

o Pas de paràmetres SEO friendly: El pas de paràmetres mitjançant URL es fa tenint en compte que les URL siguin SEO friendly. Les URL SEO friendly són aquelles que per les seves característiques són fàcils de recordar per un usuari. Els avantatges d’aquests tipus d’URL’s respecte les clàssiques o dirty URL’s són:

o Són més usables: Les dirty URL’s són difícils de recordar per la seva llargada i complexitat

o Són mes segures: Les URL’s SEO friendly no revelen informació sensible a ser utilitzada per hackers, per exemple la tecnologia usada (per mitja de l’extensió jsp, php, asp, pl).

o Permeten una major mantenibilitat: L’ús de les URL SEO friendly permeten realitzar canvis de tecnologia de forma més ràpida ja que en la URL no apareix cap informació relacionada amb la tecnologia.

Exemple de dirty URL: http://www.exemple.com/cgi-bin/genera.pl?id=4&view=basic Exemple d’URL SEO Friendly: http://albertv.local/fitxa/1


44

o Classe Filter: Classe utilitzada com a substitució de les variables globals $_GET i $_POST. S’ha fet ús de la classe Filter pel fet que aquesta ens permet filtrar totes les dades que es reben tan per GET com per POST. Alguns dels filtres més comuns ens permeten validar emails, IP’s, URL’s etc.

o Restricció ús de Variables Globals: El Framework ens dona totes les eines necessàries per evitar fer ús de variables globals ja que aquestes tenen multitud d’inconvenients com són un menor grau de mantenibilitat del codi, trenquen amb l’estructuració del codi, etc.

o Json: El Framework permet tractar fitxers amb format JSON (JavaScript Object Notation). Aquest és un format per a el intercanvi de dades, que s’està popularitzant com a alternativa a XML per la seva lleugeresa i la seva facilitat de parseig.

o Organització per mòduls: Les pàgines estan formades per diferents mòduls. Cadascun d’aquests mòduls serà un controlador diferent. Per tal de que aquests mòduls puguin passar-se informació entre elles usarem els mètodes:

o setParams: Permet fixar informació a variables. o getParams: Permet recuperar la informació prèviament fixada.

S’han seguit els següents estàndards de codi:

o Estàndard camelCase en mètodes i classes. o Variables separades per _. Ex: $distancia_acumulada o Claus en línea nova. o Documentació de tots els mètodes, classes, atributs. o Nomenclatura de noms de fitxers: S’ha seguit una nomenclatura concreta

alhora de donar nom a controllers i models d’acord amb l’estructura de directoris fixada. Tot seguit detallarem aquesta nomenclatura:

o Controller: � Nom fitxer: nom_controller.ctrl.php � Carpeta: controller

o Model: � Nom fitxer: nom_model.model.php � Carpeta: models

Ex: Volem crear un model que realitza tasques relacionades amb l’índex de dificultat en el formulari el denominaríem: dificultat.model.php i estaria ubicat a la ruta /pfc/albertv/models/form/ dificultat.model.php.

o Nomenclatura de noms de classes: De la mateixa manera que definim una nomenclatura de noms de fitxers també definirem una nomenclatura dels noms de les classes. Tot seguit detallarem aquesta nomenclatura:

o Controller: Nom directori + Nom Classe + Controller � Ex: PrincipalPrincipalController

o Model: Nom directori + Nom Classe + Model � Ex: FormConsultaModel

Per tal de comprovar el correcte ús d’aquests estàndards s’ha fet ús de phpCodeSniffer, que analitza el codi i comprova que es respecten tots els estàndards definits.


45

Sistema de Control de Versions

S’ha usat un sistema de control de versions per tal de facilitar la tasca de guardar, recuperar i mesclar informació de les versions de codi. Concretament s’ha usat Subversion que és una millora de CVS.

Subversion també conegut com SVN és un Software Lliure sota una llicència Apache/BSD, aquest permet accedir al repositori de versions de forma on-line i per tant permet que diversos programadors treballin sobre el mateix codi des d’ubicacions completament diferents. Aquest tret fomenta la col�laboració i per tan millora el rendiment de l’equip de treball.

Alguns dels avantatges més rellevants de l’ús de Subversion són:

• Les modificacions sobre els fitxers són atòmiques, és a dir, són impossibles de trencar, es realitza la modificació correctament o no es realitza.

• Maneig eficient dels arxius binaris. • Pot ser servit fent ús d’Apache juntament amb WebDAV/DeltaV fet que permet

que clients WebDAV utilitzin Subversion de forma completament transparent • Només es realitza l’enviament de les diferències dels arxius entre servidor i

client. • Quan s’usa integrat amb Apache permet incorporar totes les tècniques

d’autenticació de fitxers com són PAM, LDAP, etc.

Trobem multitud de Clients SVN, com són TortoiseSVN, Subclipse, Subversive, etc.

Les principals operacions que ens ofereix qualsevol client SVN són:

• Checkout: Operació que es realitza 1 únic cop per màquina ja que consisteix en descarregar tot el codi del servidor i emmagatzemar-lo de forma local.

• Commit: Operació que consisteix en enviar els fitxers que es troben en local al servidor. Aquesta operació cal realitzar-la com a mínim 1 cop al dia per tal de que tots els programadors del projecte puguin disposar de la darrera versió del codi.

• Update to HEAD: Descarrega la darrera versió dels fitxers del servidor i l’emmagatzema de forma local.

• Update to Version: Descarrega la versió que escollim del servidor i l’emmagatzema de forma local.

5.2.2. Instal�lació de l’entorn de desenvolupament

El software que forma el nostre entorn de desenvolupament està composat per les següents eines:

• Servidor Web amb mòdul PHP: Encarregat de processar i servir les diferents pàgines que conformen el projecte.

• Servidor BBDD: Encarregat d’emmagatzemar totes les dades relatives a rutes, marxes, usuaris, etc.

• Gestor Querys: Facilita la tasca alhora de realitzar querys de prova sobre la BBDD.

• Eclipse: IDE que ens permet desenvolupar tot el projecte fent ús de les múltiples eines que aquest ens ofereix.

• Client SVN: Encarregat de gestionar el control de versions.

A la pràctica però, aquest conjunt d’eines es troben incloses en 2 únics programes:


46

• Xampp 1.72: Aquesta eina porta integrat un conjunt d’eines útils per a desenvolupar aplicacions Web des d’entorns Windows. De les eines que aquest entorn integra hem usat:

o Apache 2.2: Servidor Web amb l’ intèrpret de PHP. o MySQL 5.1.37: Base de Dades MySQL. o phpMyAdmin 3.2.0.1 : Gestor de querys SQL.

• Eclipse Galileo SR1: IDE per al desenvolupament d’aplicacions PHP. o Subclipse 1.6.5: Client SVN instal�lable com a plugin d’Eclipse.

Per tal de preparar l’entorn de desenvolupament seguirem el següents passos:

• Instal�lació de Xampp: La instal�lació de Xampp no representa cap dificultat perquè es realitza a partir d’un instal�lador i no requereix cap configuració especial. Cal fer notar però que d’ara en endavant es suposarà que la ruta on es troba instal�lat Xampp és C:\xampp

• Configuració de la BBDD: Caldrà importar l’estructura i contingut de la BBDD, per fer-ho es pot fer ús de PhpMyAdmin accessible a partir de http://127.0.0.1/phpmyadmin/. Les dades de la BBDD són:

o Usuari: root o Password: “”(en blanc) o Nom BBDD: projecte2

• Configuració del fitxer hosts: Per tal de poder executar el codi del projecte cal configurar el fitxer hosts (En Windows XP: C:\Windows\system32\drivers\etc\hosts) de Windows per tal que aquest reconegui albertv.local com la IP de loopback. Per fer-ho aquest fitxer haurà de contenir les següents línies:

Figura 19. Configuració del fitxer de hosts

• Configuració dels Virtual Hosts: Cal configurar els virtual hosts de tal forma que quan s’accedeixi per la direcció http://albertv.local se’ns redirigeixi a un directori concret. Per tal de fer-ho caldrà editar el contingut del fitxer de Virtual hosts de Xampp (c:\xampp\apache\conf\extra\httpd-vhosts.conf) amb el següent contingut:

127.0.0.1 localhost

127.0.0.1 albertv.local


47

Figura 20. Configuració del fitxer de Virtual Hosts

Configuració inicial del Framework

Un cop descarregat i descomprimit Eclipse, aquest ja es podrà executar degut al fet que no es requereix cap instal�lació del mateix. Un cop Eclipse hagi arrencat caldrà fixar el workspace en la següent ruta: C:\xampp\htdocs\

Fet això, seguidament es descriuran els passos que s’hauran de realitzar per tal d’instal�lar i fer ús de Subclipse (client SVN):

• Instal�lació de Subclipse: Per tal d’instal�lar Subclipse caldrà afegir-lo com a complement d’Eclipse. Per fer-ho caldrà seguir els següents passos i disposar de connexió a Internet:

o Menú Help. o Opció Install Software. o Afegir la ruta http://subclipse.tigris.org/update_1.6.x i clicar Add. o Del llistat de Plugins seleccionem Subclipse, i cliquem Next. o Finalment cliquem Finish i es procedirà a la descàrrega i instal�lació del

Plugin. o Caldrà reiniciar Eclipse per completar la instal�lació.

• Invocació de Subclipse: Un cop instal�lat Subclipse, caldrà afegir-lo com a pestanya d’Eclipse. Per fer-ho es seguiran els següents passos:

o Menú Window o Opció Show View, seleccionar l’opció Other del Menú desplegable. o Apareixerà un llistat amb tots els mòduls que es poden afegir a Eclipse.

D’aquest llistat seleccionar SVN. o Despleguem SVN i seleccionem la opció SVN Repositories o Seguidament Clicar Ok

• Configuració dels Repositoris: Un cop afegit el mòdul de SVN caldrà afegir els repositoris de Codi. Tot seguit detallarem quins respositoris tenim i com afegir el codi:

o Repositori Framework: Aquest repositori conté tot el codi associat amb el Framework. Per tal d’afegir-lo seguirem els següents passos:

� Opció Add SVN Repository � Farem ús de la URL:

http://svn.senderators.webfactional.com/frameworklite

<VirtualHost *:80>

ServerAdmin [email protected]

DocumentRoot "C:/xampp/htdocs"

ServerName localhost

</VirtualHost>

<VirtualHost *:80>

DocumentRoot C:/xampp/htdocs/frameworklite/instances/albertv/htdocs

ServerName albertv.local

<Directory "C:/xampp/htdocs/frameworklite/instances/albertv/htdocs">

Options Indexes FollowSymLinks

Order allow,deny

Allow from all

</Directory>

</VirtualHost>


48

� Fet això tindrem afegit el repositori, però encara resta descarregar el codi. Per fer-ho clicarem amb el botó dret sobre el repositori i seleccionarem l’opció Checkout.

� Seguidament ens apareixerà un nova pantalla, on seleccionarem l’opció “Check out as a project in the Workspace”, on el nom de projecte serà frameworklite.

� Finalment cliquem Finish o Repositori albertv: Aquest repositori conté tot el codi associat amb

l’eina desenvolupada. El nostre objectiu és obtenir el codi d’aquest repositori i emmagatzemar-lo en el subdirectori \frameworklite\instances\albertv. Per fer-ho ens caldrà canviar de workspace per tal de descarregar el codi en l’anterior subdirectori, i fet això tornar a canviar pel workspace original. Tot seguit descriurem aquests passos en detall:

� Canviar al workspace C:\xampp\htdocs\frameworklite\instances\ � En cas de que no aparegui la finestra de subclipse s’haurà

d’invocar novament seguint els passos anteriorment descrits � Opció Add SVN Repository � Es farà ús de la URL:

http://svn.senderators.webfactional.com/pfc/albertv � Fer un checkout en aquest workspace, seguint els passos

anteriorment descrits. � Canviar novament al workspace C:\xampp\htdocs\ � Refrescant el PHP Explorer (prement F5) s’observarà que es

disposa del projecte albertv degudament descarregat.

Un cop configurats els repositoris i descarregat degudament el codi encara mancaran algunes configuracions prèvies a poder executar tot el codi. Tot seguit es detallen les configuracions necessàries:

• Configuració del fitxer db.config: Aquest fitxer emmagatzema els paràmetres d’accés a la BBDD. Permet diferenciar els paràmetres de configuració de la BBDD d’un entorn en desenvolupament amb els d’un entorn en producció. Els paràmetres utilitzats en la nostra BBDD són:

o Usuari: root o Password: “”(en blanc) o Nom BBDD: projecte2

• Configuració del fitxer general.config: Fitxer de configuració general del Framework. Es podran configurar les següents dades:

o URL absoluta: URL a partir de la qual es visualitzarà la nostra pàgina. o Paths del Framework: Paths que fan referència als directoris rellevants

del Framework. Es podran configurar els següents paths: � Root: Path que fa referència al directori arrel. � Instance: Path que fa referència al directori on es troben les

diverses instàncies (projectes diferents). � Engine: Path que fa referència al directori on trobem el motor

(codi) del Framework. � Configure: Path que fa referència al directori on trobem els

fitxers de configuració de la instància on ens trobem. � Smarty: Path que fa referència al directori on trobem el codi de

Smarty. � Controllers: Path que fa referència al directori on es troben els

controladors de la instància on ens trobem. � Models: Path que fa referència al directori on es troben els

models de la instància on ens trobem.


49

� Templates: Path que fa referència al directori on es troben les vistes de la instància on ens trobem.

� Templates_c: Path que fa referència al directori on es troben els arxius temporals (caché) de les vistes que genera Smarty.

• Configuració del fitxer email.config: Fitxer de configuració que ens permet definir els paràmetres de connexió a un servidor de correu per tal de fer possible l’enviament de mails des del portal. Els paràmetres que es podran definir són:

o Protocol del mail: Per defecte smtp. o Host: Direcció del servidor que té instal�lat el servidor de correu. o Autorització smtp: Booleà que ens permet definir si el servidor de

correu requereix autenticació (cert) o no (fals). o Mail del remitent: Ens permet especificar el correu amb el qual

s’enviaran els correus. o Nom del remitent: Ens permet especificar el nom amb el qual

s’enviaran els correus.

Arribats aquest punt es disposarà de l’entorn de desenvolupament completament instal�lat i configurat. Seguidament es descriurà com desenvolupar codi fent ús del Framework.

5.2.3. Estructura genèrica de les capes MVC

Un cop el Framework ha estat degudament instal�lat caldrà seguir una metodologia de programació així com una configuració concreta del mateix perquè tot el codi que s’escriu sigui degudament executat.

Seguidament definirem la estructura genèrica que han de seguir les 3 capes que conformen el patró MVC.

Estructura genèrica del Controller

Com es veurà detalladament, un controlador està format per una classe amb un nom que segueix una nomenclatura concreta i amb la implementació d’un conjunt de mètodes. Tot controlador haurà de seguir la següent estructura bàsica:

• Herència de la classe Controller: L’herència de la classe Controller és necessària en la definició de qualsevol controlador degut al fet que aquesta classe és la que ens defineix un conjunt de mètodes necessaris en la implementació de qualsevol Controller. Tot seguit es detallen els mètodes més rellevants definits per aquesta classe:

1. assign(nom_variable): Mètode que permet assignar variables a la vista. És la forma que tenim de passar variables del controlador a la vista.

Ex: Volem assignar la variable rutes (variable del controlador) a la variable rutes_vista (variable de la vista). $this->assign( 'rutes_vista', $rutes );

2. setLayout(nom_vista): Mètode que permet cridar a una vista des del controlador.

Ex: Volem cridar a la vista exemple $this->setLayout(exemple/exemple.tpl' );

3. setParam(nom_param): Permet fixar el valor d’un paràmetre. 4. getParams(): Permet recuperar tota la informació prèviament fixada

fent ús de la funció setParams(). Retorna un array.


50

5. getParam(nom_param): Permet recuperar el valor d’un paràmetre prèviament fixat fent ús de la funció setParam(). Retorna el valor d’una variable.

6. getClass(nom_classe): Aquest mètode és usat en substitució de l’operador New. Usem aquest mètode pel fet que realitza un new de la classe però validant prèviament si la classe existeix i està degudament afegida en els fitxers de configuració.

• Implementació del mètode build: Aquest mètode és el primer mètode que s’executarà quan es cridi a un Controller. L’estructura mínima d’un Controller ha d’incloure la implementació d’aquest mètode obligatòriament.

• Implementació del mètode loadModules: Mètode que permet carregar un conjunt de mòduls (Controllers) en el Controller actual. Un cop carregat aquest conjunt de mòduls podrem cridar-los fàcilment en la vista.

Tot seguit trobem la implementació del codi mínim que haurà de tenir tot Controlador:

Figura 21. Codi mínim del Controlador

Observem com en aquest cas en el mètode loadModules es carreguen únicament els mòduls per defecte head i footer (encapçalament i peu d’una pàgina).

Estructura genèrica del Model

Com es veurà detalladament, un model està format per una classe amb un nom que segueix una nomenclatura concreta. Tot model haurà de seguir la següent estructura bàsica:

• Herència de la classe Model: L’herència de la classe Model és necessària en la definició de qualsevol model. Aquesta classe alhora hereta de la classe Database que és l’encarregada de realitzar la vinculació amb la llibreria ADOdb.

<?php class ExempleExempleController extends Controller {

/** * Es obligatori implementar aquest mètode. * Serà el primer mètode que s'executarà */ public function build( ) { } /** * Mètode que ens permet carregar diversos mòduls a la vista * @return array */ public function loadModules() { $modules['head'] = 'SharedHeadController'; $modules['footer'] = 'SharedFooterController'; return $modules; } } ?>


51

Tot seguit trobem la implementació del codi mínim que haurà de tenir tot Controlador:

Figura 22. Codi mínim del Model

Estructura de les Consultes

Degut al fet que es fa ús de la llibreria ADOdb les consultes han de seguir una sintaxi concreta per tal que aquestes s’executin correctament.

Seguidament detallarem la sintaxi i el format de les consultes més comunes que es realitzen a una BBDD:

• Select: Permet consultar aquelles dades d’una taula/es que compleixin la condició especificada en el tag WHERE. Exemple:

Figura 23. Exemple de Select usant ADOdb

El mètode getAll ens permet obtenir les dades que retorni la query. Típicament aquestes dades es guardar en un array.

• Insert: Permet inserir dades a una taula/es. Exemple:

Figura 24. Exemple d’insert usant ADOdb

El mètode Execute executa la query. En cas de que la query contingui algun error, aquest mètode retornarà fals.

$sql = <<<QUERY INSERT INTO edicio (id_marxa,num_edicio) VALUES (?,?) QUERY; if($this->Execute($sql,$dades)==false){

echo "error".$this->ErrorMsg(); }

$sql = <<<QUERY

SELECT t.* FROM track t WHERE id_track=$this->id_track QUERY; return $this->getAll( $sql );

<?php class ExempleExempleModel extends Model { } ?>


52

Observem que aquest mètode rep 2 paràmetres:

� Sql: El codi SQL. � Dades: Un array on s’emmagatzemen els valors de les dades

que es volen inserir. • Delete: Permet esborrar aquelles dades d’una taula/es que compleixin la

condició especificada en el tag WHERE.

Figura 25. Exemple de Delete usant ADOdb

Novament es fa ús del mètode Execute, però, en aquest cas, aquest només rebrà un únic paràmetre pel fet que les dades de la query les escribim directament sobre aquesta.

• Update: Permet realitzar modificacions sobre aquelles dades d’una taula/es que compleixin la condició especificada en el tag WHERE.

Figura 26. Exemple d’update usant ADOdb

Novament es fa ús del mètode Execute, però en aquest cas aquest només rebrà un únic paràmetre pel fet que les dades de la query les escrivim directament sobre aquesta.

Estructura genèrica de la Vista

El codi de la vista està implementat exclusivament fent ús de Smarty.

Smarty és un generador de plantilles per a PHP que permet agilitzar el procés de disseny i implementació de la vista. Smarty permet separar eficientment la capa de Negoci de la capa de presentació, per fer-ho es fa ús dels paràmetres que es passen entre ambdues capes així com del conjunt d’eines que ens ofereix Smarty per realitzar el tractament d’aquestes dades.

$sql = <<<QUERY UPDATE edicio SET id_track=$id_track WHERE id_edicio=$this->id_edicio QUERY; if($this->Execute($sql)==false){


$sql = <<<QUERY

DELETE FROM track WHERE id_track=$id_track QUERY; if($this->Execute($sql)==false){



53

Amb això s’aconsegueix separar completament el codi de les 2 capes, i qualsevol canvi a la capa de negoci relacionat amb el tractament de les dades no afectarà al codi de presentació d’ aquestes.

En la capa de presentació per tant, (i sempre i quan el programador així ho desitgi) no hi haurà necessitat de disposar de codi de tractament de dades. Pel que fa al codi relacionat amb la capa de presentació aquest si que podrà ser present i per tant tasques com la inclusió d’altres plantilles, la inclusió de sentències condicionals o la realització de bucles per a la visualització de dades seran possibles en la capa de presentació fent ús de Smarty.

Per tal de realitzar aquestes accions Smarty requereix ser compilat abans de poder ser executat. El procés de compilació de codi Smarty, converteix aquest codi a codi PHP directament interpretable per Apache

Tot seguit es resumeixen les principals característiques de Smarty:

• Es un llenguatge ràpid: Malgrat es requereix compilar el codi Smarty, aquest procés únicament es realitzarà 1 únic cop gràcies al fet que es disposa d’una caché de plantilles.

• Disposa d’un ampli conjunt de sentències de tractament de dades: Les principals sentències de tractament de dades que ofereix Smarty són:

o {if},{else},{/if}: Sentència condicional, molt útil per tal de diferenciar la capa de presentació de diferents tipus d’usuaris.

o {foreach},{/foreach}: Sentència iterativa, molt útil en la presentació de dades que es troben emmagatzemades en un array. Per exemple quan volem mostrar dades d’una consulta.

o {literal},{/literal}: Tags que permeten la inclusió de codi que no es vol que sigui compilat sinó interpretat directament. Tag necessari en la inclusió de codi Javascript.

o {include}: Tag que permet la inclusió d’altres plantilles en la plantilla actual.

• Fàcil tractament dels paràmetres: Per tal d’accedir als paràmetres que han estat passats des de la capa de negoci ho farem a partir de dollar + nom de variable. Així si volem accedir a la variable nom_ruta des de la capa de presentació i accedirem així $nom_ruta.

• Permet la creació de funcions pròpies: Permet la redefinició de tags propis d’HTML com són els tags img, radio, table, checkbox, etc.

• Disposa d’una bona documentació: Disposa d’una comunitat d’usuaris així com d’una bona documentació oficial.

• Llenguatge fàcil d’aprendre: Es tracta de la combinació de codi HTML amb sentències similars a les de PHP i per tant aprendre aquest llenguatge un cop es coneix PHP no representa cap dificultat.

El codi mínim que haurà de tenir tota vista serà:

Figura 27. Codi mínim de la Vista

{$modules.head} <div id="content"> Codi HTML + Codi Smarty </div> {$modules.footer}


54

5.2.4. Casuístiques Framework

Seguidament es descriuran diverses casuístiques amb les que ens podem trobar desenvolupant fent ús del Framework.

Casuística bàsica, consulta i mostra d’un conjunt de dades de la BBDD

Volem escriure un codi que ens permeti consultar un conjunt de dades a la BBDD i mostrar els resultats en una interfície adient. El codi per realitzar això es trobarà separat en les 3 capes que conformen el model MVC. En aquest cas, cada una de les capes realitzarà les següents accions:

• La capa model ens realitzarà la consulta sobre la BBDD • La capa de presentació ens mostrarà els resultats • La capa controladora gestionarà tot el procés i s’encarregarà d’interactuar amb

el model i la capa de presentació.

Suposem que volem realitzar una consulta a la Taula Track, per tal d’obtenir les rutes amb més de 50 km. Fet això en volem mostrar el nom, distància i els desnivells positiu i negatiu.

Per tal de portar a cap aquestes accions haurem de seguir un conjunt de passos que tot seguit es descriuen:

• Implementació del controlador: El controlador cridarà al model, en recollirà els resultats i fet això els passarà a la vista. Els passos que es seguiran per crear-lo són:

o Es crea una nova carpeta al directori controller, en aquest cas carpeta prova.

o Es crea un nou fitxer php en aquesta carpeta, amb el nom prova.ctrl.php, on prova és el nom que posarem en aquest exemple.

o Cal fer notar que el nom de la classe segueix la nomenclatura establerta degut a què ens trobem al directori Prova i la classe també l’hem denominat Prova.


55

Tot seguit veurem en detall la implementació d’aquest:

Figura 28. Controlador de la casuística bàsica

• Implementació del Model: El model realitzarà una select sobre la taula track i en retornarà el resultat en un array. Els passos que es seguiran per crear-lo són:

o Es crea una nova carpeta al directori models, en aquest cas carpeta prova.

o Es crea un nou fitxer php en aquesta carpeta, amb el nom prova.model.php, on prova és el nom que posarem en aquest exemple.

o Cal fer notar que el nom de la classe segueix la nomenclatura establerta degut a què ens trobem al directori Prova i la classe també l’hem denominat Prova.

<?php /** * Prova controller: Controlador d'exemple */ class ProvaProvaController extends Controller { public function build( ) { //Realitzem una instancia del Model $prova_model = $this->getClass( 'ProvaProvaModel' ); //Cridem a la funció getRutes, retorna l’array rutes $rutes = $prova_model->getRutes(); /* Assignem l’array rutes a la variable rutes_vista * per fer-la accessible des de la vista (smarty) */ $this->assign( 'rutes_vista', $rutes ); //Crida a la vista prova $this->setLayout( 'prova/prova.tpl' ); } public function loadModules() { $modules['head'] = 'SharedHeadController'; $modules['footer'] = 'SharedFooterController'; return $modules; } } ?>


56


Figura 29. Model de la casuística bàsica

• Implementació de la vista: La vista mostrarà les dades que li passa el

controlador per pantalla. Els passos que seguirem per crear-lo són: o Creem nova carpeta al directori, templates en aquest cas carpeta prova. o Creem un nou fitxer en aquesta carpeta, amb el nom prova.tpl, on prova

és el nom que posarem en aquest exemple.


Figura 30. Vista de la casuística bàsica

{$modules.head} <div id="content"> <br> <table border="1"> <tr> <td><b><center>Nom ruta</center></b></td> <td><b>Distancia</b></td> <td><b>Des. Pos.</b></td> <td><b>Des. Neg</b></td> </tr> {foreach from=$rutes_vista item=dada} <tr>

<td><center>{$dada.nom_ruta}</center></td> <td><center>{$dada.distancia} km</center></td> <td><center>{$dada.des_pos} m</center></td> <td><center>{$dada.des_neg} m</center></td> </tr>

{/foreach} </table> </div> {$modules.footer}

<?php /** * Classe que ens permeterà obtenir informacio * de les rutes amb mes de 50km * @author albert */ class ProvaProvaModel extends Model { /** * Funció que ens consulta les dades

* de les rutes amb mes de 50 Km * @return array */ public function getRutes() { $sql = <<<QUERY SELECT t.* FROM track t WHERE t.distancia > 50 QUERY; return $this->getAll( $sql ); } } ?>


57

Tal i com es pot observar trobem codi Smarty (entre claus {}) barrejat amb codi HTML. En el codi es pot observar com es crea una taula i es mostren totes les dades d’una ruta per cada fila.

• Configuració del fitxer dispatcher.config: Per tal de que es reconegui cada nou controlador que creem caldrà afegir aquest en el fitxer dispatcher.config.php seguint el següent format:

Figura 31. Configuració del fitxer dispatcher.config

• Configuració del fitxer base.config: Per tal de que es reconegui cada nova classe que creem la ruta d’aquestes s’haurà d’afegir en el fitxer base.config.php seguint el següent format:

Figura 32. Configuració del fitxer base.config

• Execució del codi: Per tal d’executar el codi que acabem d’escriure cal posar http://albertv.local seguit del nom que hem escrit al fitxer dispatcher. Així, per accedir a l’exemple que haurem d’escriure la URL: http://albertv.local/prova

El resultat de l’exemple el podem observar en la següent imatge:

Figura 33. Resultat de la casuística bàsica

Com s’ha pogut observar, realitzar una consulta a la BBDD i mostrar-ne els resultats a través de la interfície fent ús d’aquest Framework requereix seguir un llarg conjunt de passos. Malgrat a priori es pugui considerar un procés complex, aquest és un procés que es realitza sempre de la mateixa manera i per tant un cop aquest s’ha realitzat una primera vegada ja no comporta cap dificultat.

Casuística Google Maps

Volem que una pàgina del nostre portal ens permeti visualitzar una ruta en un mapa de Google Maps. Per fer això disposem de la API de Google Maps (s’ha fet ús de la Versió 2), que ens ofereix un ampli conjunt de mètodes que ens permeten realitzar multitud d’accions sobre un mapa. Aquesta API disposa de 2 versions la estàtica i la de Flash. Es farà ús de la versió estàtica de l’API.

Per tal de visualitzar una ruta sobre el mapa es necessiten consultar les dades de la ruta a la BBDD i això representa un problema fent ús de l’API de Google Maps degut al fet que aquesta no disposa de cap mètode per realitzar consultes directament sobre la BBDD.

$config['ProvaProvaController']= PATH_CONTROLLERS.'prova/prova.ctrl.php'; $config['ProvaProvaModel']= PATH_MODELS.'prova/prova.model.php';

$config['prova']='ProvaProvaController';


58

Per tal de solucionar això per tant es necessita fer ús d’algun mètode que ens permeti que l’API de Google Maps obtingui les dades de la BBDD sense accedir directament a ella. La solució la trobem en llenguatges tipus XML o JSON que permeten l’ intercanvi d’informació estructurada entre plataformes.

Nosaltres farem ús d’XML per ser un estàndard més ben documentat per Google10.

Així, per tal de poder pintar una ruta sobre un mapa fent ús de Google Maps s’hauran de seguir els següents passos:

1. Consulta de les dades de la ruta a la BBDD 2. Generació del XML 3. Parseig del XML per part de la API de Google Maps 4. Pintar mapa

Aquests passos es tradueixen en 2 controllers, 1 model i 2 vistes que tot seguit detallem:

1. Model XML: Ens realitza la consulta de les dades de la ruta sobre la BBDD. Apart de la consulta de les dades es generarà l’xml fent ús del mètode de PHP domDocument. Les dades que es consulten són:

a. Latitud i longitud de 500 punts: Malgrat una ruta pot contenir més de 6000 punts diferents s’ha comprovat que escollint 500 punts de tota la ruta podem pintar el recorregut de la ruta de forma precisa. D’aquesta forma per tant, es millorarà el rendiment de l’eina sense perdre qualitat.

b. Coordenades màximes/mínimes de la ruta: Per tal de poder definir la localització i el zoom del mapa la API de Google Maps requereix disposar d’un conjunt de dades que tot seguit es detallen:

i. Màxima latitud ii. Mínima latitud iii. Màxima longitud iv. Mínima longitud

c. Punt inici i final: Per tal de poder diferenciar sobre el mapa els punts d’inici i fi de ruta de la resta aquests es consultaran de forma independent de la resta

d. Waypoints: Per tal de poder mostrar la informació dels diferents waypoints d’una ruta sobre el mapa, per cada waypoint s’obtindran les següents dades:

i. Latitud ii. Longitud

iii. Nom del Waypoint iv. Altura del Waypoint

2. Vista XML: Mostra l’XML generat pel model. 3. Controller XML: Realitza el control del procés de creació de l’XML 4. Vista Google Maps: Per tal de pintar el mapa, es segueixen els següents

passos: a. Autenticació a partir de la clau de la API b. Posicionament i nivell de zoom del mapa c. Parseig de l’XML d. Mostra del mapa

5. Controller Google Maps: Realitzarà el control del pintatge del mapa.

10 http://code.google.com/intl/es-ES/apis/maps/articles/phpsqlajax.html


59

El resultat el podem observar en la següent imatge:

Figura 34. Resultat casuística Google Maps

Casuística Perfil de Ruta

Per tal d’obtenir el perfil d’una ruta i tal i com es troba degudament justificat en l’apartat de decisions de disseny s’ha fet ús d’una eina anomenada flot.

El procés de realització del perfil de ruta és força similar al descrit en la casuística de Google Maps degut al fet que es necessària l’obtenció prèvia de les dades de la ruta de la BBDD per tal de pintar el perfil.

El procés però, resulta en part diferent. Això és degut a què s’ha decidit canviar XML per JSON. El canvi ve motivat pel fet que flot en ser una llibreria escrita amb Javascript permet gestionar de forma més eficient fitxers en format JSON (JavaScript Object Notation) que en format XML. Apart d’això, JSON es un llenguatge ràpid i fàcil de generar i interpretar tan per les màquines com pels humans tret que facilita la detecció d’errades.

Així, per tal de poder pintar el perfil d’una ruta fent ús de flot s’hauran de seguir els següents passos:

1. Consulta de les dades de la ruta a la BBDD 2. Generació del fitxer JSON 3. Parseig del fitxer JSON per part de la llibreria flot 4. Pintar perfil

Aquests passos es tradueixen en 2 controllers, 1 model i 2 vistes que tot seguit detallem:

1. Model JSON: Ens realitza la consulta de les dades de la ruta sobre la BBDD. Apart de la consulta de les dades es generarà el codi JSON fent ús del mètode json_encode($arr) de PHP. Les dades que es consulten són:

a. Altura i Distancia de 500 punts: De la mateixa manera que fèiem a l’hora de pintar la ruta fent ús de Google Maps, obtenint 500 punts en tindrem suficient per pintar un perfil de la ruta de forma precisa.

2. Vista JSON: Mostra el JSON generat pel model. 3. Controller JSON: Realitza el control del procés de creació del JSON 4. Vista Flot: Encarregada de parsejar el fitxer JSON i pintar el perfil.


60

5. Controller Flot: Realitzarà el control del pintatge del perfil de la ruta

Casuística AJAX

AJAX (Asyncronous Javascript and XML) és una conjunció de tecnologies àmpliament usada en el disseny de pàgines web degut al fet que permet refrescar únicament una part d’una pàgina després de realitzar una determinada acció. AJAX dona dinamisme a una pàgina i és àmpliament usat en formularis pel fet de que permet consultar i mostrar els resultats a mesura que l’usuari escriu dades.

Figura 35. Cerca amb AJAX

AJAX segueix el següent flux d’execució en una pàgina que no fa ús del patró MVC:

1. Disposem d’una pàgina HTML on l’usuari clica o introdueix alguna dada. 2. Un codi javascript envia una petició al servidor passant-li la informació

introduïda per l’usuari. 3. El servidor processa la petició consultant les dades passades a una BBDD. 4. El servidor retorna el resultat de la petició a l’script. 5. El mateix script refresca la pàgina.

Fent ús del patró MVC però, aquest procés esdevé molt més complex d’implementar pel fet que el codi es troba segmentat en 3 capes diferents trencant el flux estàndard d’AJAX.

Ara si intentem encabir l’anterior procés en les 3 capes del patró MVC ens trobarem amb el següent:

• Vista: Sembla prou evident que en la vista hi trobarem el fitxer HTML juntament amb el codi javascript per detectar l’event i transmetre la petició al servidor així com també el codi necessari per refrescar la pàgina un cop haguem rebut el resultat de la petició.

• Model: En aquest hi trobarem el codi que ens realitzarà la consulta de la petició sobre la BBDD.

• Controlador: Pensant en el controlador s’observa com la implementació d’aquest no és tan trivial com la del Model o la de la Vista. Això és degut a què sorgeix la necessitat de fraccionar les accions que ha de portar a cap el controlador en 2 controladors independents que tot seguit es detallen:

o Controlador client-side: Aquest controlador és l’encarregat de mostrar el formulari i un cop s’ha rebut l’event és l’encarregat de realitzar la crida al controlador server-side.

o Controlador server-side: Aquest controlador és l’encarregat de rebre la petició i d’enviar-la al Model. Fet això s’enviarà el resultat al controlador client-side.

Degut a la complexitat de la implementació d’AJAX fent ús del patró MVC alguns frameworks de PHP inclouen solucions AJAX transparents per al programador.


61

5.3. Decisions de disseny

Al llarg del treball ens ha sorgit la necessitat de prendre gran quantitat de decisions relacionades amb l’elecció dels millors mètodes o tècniques per calcular o obtenir certes dades.

Tot seguit detallarem les principals decisions de disseny.

5.3.1. Càlcul de la distància entre coordenades GPS

Per tal de calcular la distancia entre 2 parells de punts (dels quals disposem de la latitud i la longitud) hem trobat diferents tècniques per fer-ho, com són el mètode de Haversine i la Llei esfèrica dels cosinus.

Tal i com hem llegit 11 el mètode de Haversine ens dona una menor precisió que la Llei Esfèrica dels cosinus i malgrat la diferència entre ambdós mètodes és petita 12 hem preferit fer ús del segon mètode assenyalat per tal de guanyar major precisió.

La formula de la Llei Esfèrica dels cosinus vindrà expressada per: dist = cos9,:sin(<��,) × sin(<��)) + cos(<��,) × cos(<��)) × cos:(<!�)) − (<!�,)>> × ? on R, és el Radi de la Terra en Km (6731km) Fórmula 8. Llei Esfèrica dels cosinus

Conversió distància sobre pla horitzontal a distància real

Donat a què el càlcul de la distància entre 2 coordenades (lat,lon) ens dona la distància recorreguda en el pla horitzontal hem hagut de realitzar la conversió d’aquesta distància per tal de trobar la distància real transcorreguda.

Figura 36. Triangle Rectangle

Per tal de realitzar aquest conversió podem aplicar el Teorema de Pitàgores degut a què disposem de la distància sobre el pla horitzontal (en el dibuix c) així com de l’altura (en el dibuix b).

11 http://www.movable-type.co.uk/scripts/latlong.html 12 http://sgowtham.net/blog/2009/08/04/php-calculating-distance-between-two-locations-given-their-gps-coordinates/


62

D’aquesta forma per tal de conèixer la distància real (en l’anterior dibuix a), apliquem Pitàgores:

� = K�) + L)

Fórmula 9. Teorema de Pitàgores

5.3.2. Càlcul del percentatge de desnivell

Per tal de realitzar els càlcul del percentatge de desnivell d’una ruta hem trobat diversos mètodes 13.

El primer mètode que trobem, resulta més senzill de calcular però a la vegada menys precís. Aquest mètode consisteix en dividir els metres ascendits entre els metres recorreguts.

M�� % = �� O��< �� O��!OO�P�� ∗ 100

Fórmula 10. Càlcul aproximat del percentatge de desnivell

Seguint aquest mètode una pendent del 100% voldria dir que per cada 100 metres avançats ascendim 100 metres. Si calculem l’angle real tenint en compte aquestes condicions obtenim que 90o equivalen al 100% de pendent, i 45o equivaldrien al 70,2% de pendent.

El segon mètode que descriurem és l’ anomenat mètode topogràfic, aquest mètode resulta més rigorós ja que té una base matemàtica però menys pràctic ja que la distancia sobre el pla horitzontal no és una dada de que la disposem sense fer ús de trigonometria. Aquest mètode consisteix en dividir els metres ascendits entre els metres recorreguts sobre el pla horitzontal.

M�� % = �� O��< �� <� ℎ!O��S!��< ∗ 100

Fórmula 11. Càlcul del percentatge de desnivell

Tal i com veiem en la figura del Triangle Rectangle, aquest mètode ens permet calcular l’angle β (en tan per cent) disposant de la distància sobre el pla horitzontal en aquest cas c, i de la distancia vertical en aquest cas b.

Seguint aquest mètode una pendent del 100% voldria dir que per cada 100 metres avançats en recorrem 100 sobre el pla horitzontal, és a dir que depenent del pendent recórrer 100 metres en horitzontal ens implicarà recórrer un major nombre de metres reals.

En aquest cas una pendent d’un 100% equival a 45o.

Finalment s’ha decidit aplicar el mètode topogràfic ja que permet obtenir uns resultats més acurats. Malgrat això val a dir que el primer mètode descrit segueix essent un mètode vàlid ja que ens permet obtenir resultats fiables per percentatges de desnivell petits (pròxims al 20%) que són els més comuns en rutes de muntanya a peu.

13 http://www.altimetrias.net/articulos/4ComoPendiente.asp


63

Conversions entre percentatges de desnivell i graus

• Pas de % de desnivell a graus

PO�� = tan9, � �O��P�100 �

Fórmula 12. Conversió d’un desnivell expressat en percentatge a graus

Exemple: Suposem un percentatge del 35%, a quants graus equival?

tan9, � 35100� = 19.29W

Fórmula 13. Exemple de conversió d’un desnivell expressat en percentatge a graus

• Pas de graus a % de desnivell

�O��P� �� << = tan(PO�� ) ∗ 100

Fórmula 14. Conversió d’un desnivell expressat en graus a percentatge

Exemple: Suposem un pendent amb 15o de desnivell, a quin percentatge equival? tan(15) ∗ 100 = 26,79%

Fórmula 15. Exemple de conversió d’un desnivell expressat en graus a percentatge

5.3.3. Definició de l’índex de dificultat

Tal i com hem vist en l’Apartat 2.4 actualment trobem diversos índexs que ens donen una idea general de la dificultat de la ruta analitzant dades com la distància o el desnivell però no avaluen molts altres aspectes que considerem importants.

Per aquest motiu creiem oportú la definició d’un índex propi que ens permeti avaluar la dificultat real amb més dades apart de la distància i el desnivell.

Centrant-nos en l’anàlisi dels desnivells, inicialment vàrem pensar en utilitzar dades com el desnivell positiu o el desnivell acumulat (utilitzades en els càlculs dels índex de dificultat de la FEEC i de la UTMB) però vàrem considerar oportú d’anar més enllà i avaluar més detalladament aquest desnivell fragmentant-lo amb els metres amb un percentatge concret de desnivell i ponderant-los en funció de la dificultat que impliqués superar aquest determinat desnivell.

Per tal de calcular i determinar els percentatges més comuns de les rutes de muntanya a peu s’ha realitzat el següent estudi.


64

Estudi dels percentatges de desnivell

Per tal de realitzar el càlculs dels percentatges de desnivell hem usat l’ anteriorment descrit mètode topogràfic, però com apliquem aquest mètode? Per tal d’aplicar aquest mètode, varem implementar un algorisme que ens calculava i acumulava el nombre de metres amb un cert desnivell cada X metres recorreguts sobre el pla horitzontal.

Per realitzar aquests càlculs però, ens va sorgir el dubte de quin valor havia d’agafar X per tal d’obtenir els millors resultats possibles, així com també, com havia de respondre l’algorisme en cas de trobar un canvi en la direcció del desnivell.

Quan ens referim a com havia de respondre l’algorisme en front a canvis en la direcció del desnivell volem dir que en el cas de que estiguem calculant un percentatge de desnivell positiu (pujada) què ha de fer l’algorisme en el cas que trobem un desnivell negatiu (baixada). Sembla prou obvi que tot canvi de desnivell s’ha d’obviar per tal d’obtenir un resultats correctes i per tant el nostre algorisme quan detecta un canvi en el desnivell realitza el càlcul del percentatge fins arribar en aquest punt d’inflexió malgrat no hagin transcorregut els X metres sobre el pla horitzontal.

Per tal de trobar el nombre de metres que ens permetia trobar un percentatge de desnivell el més realista possible varem realitzar un estudi amb 10 rutes de diferents característiques (curtes, llargues, planes, amb molt desnivell).

Aquest estudi tenia per objectiu obtenir els desnivells mitjos fent ús de 3 distàncies diferents sobre el pla horitzontal 50m, 25m i 10m. Varem escollir aquestes 3 pel fet que són unes distàncies que dintre de les rutes a peu ens permeten avaluar correctament un desnivell sostingut. Resulta important recalcar la importància d’analitzar els desnivells sostinguts ja que són aquests els que ens donen una mesura realista de la dificultat de vèncer un determinat percentatge de desnivell.

Figura 37. Estudi dels percentatges de desnivell positiu

0,00%

4,00%

8,00%

12,00%

16,00%

20,00%

Comparativa percentatges desnivell positiu

Mitjanes 50m.

Mitjanes 25m.

Mitjanes 10m.


65

Figura 38. Estudi dels percentatges de desnivell negatiu

Analitzant aquestes gràfiques observem que com major és la distància de referència sobre el pla horitzontal es tendeixen a suavitzar més les pendents. És a dir, el percentatge de metres amb un pendent entre l’1% i el 5% és major agafant una distància de referència sobre el pla horitzontal de 50 m. (un 18,98%) que agafant una distància de 10 m. (16,49%).

Analitzant la resta de percentatges observem com aquesta tendència es manté i per tant podem concloure que com major sigui el nombre de metres de referència sobre el pla horitzontal major serà la tendència a suavitzar tots els pendents.

Finalment, hem considerat oportú quedar-nos amb 25 metres com a distància de referència sobre el pla horitzontal.

Un cop fixada aquesta distància de referència hem extret les següents taules que ens permetran avaluar quins són els percentatges de desnivells més comuns i com podem ponderar-los.

Desniv. Positius

Desniv. negatius

0%-5% 17,76% 23,65%

5%-10% 11,66% 14,46%

10%-15% 5,93% 6,90%

15%20% 3,18% 3,94%

20%-25% 2,11% 2,39%

25%-30% 1,36% 1,20%

30%-35% 0,74% 0,78%

35%-40% 0,45% 0,60%

40%-45% 0,38% 0,29%

45%-50% 0,26% 0,24%

50%-55% 0,18% 0,19%

55%-60% 0,26% 0,12%

60%-65% 0,13% 0,08%

65%-70% 0,05% 0,04%

70%-75% 0,07% 0,04%

75%-80% 0,05% 0,04%

0,00%4,00%8,00%

12,00%16,00%20,00%24,00%28,00%

Comparativa percentatges desnivell negatiu

Mitjanes 50m.

Mitjanes 25m.

Mitjanes 10m.


66

80%-85% 0,03% 0,03%

85%-90% 0,02% 0,01%

90%-95% 0,05% 0,00%

95%-100% 0,03% 0,01%

100%-173% 0,12% 0,13%

173%-275% 0,03% 0,05%

TOTALS 44,83% 55,17%

Taula 4. Estudi dels percentatges de desnivell mitjos

Com podem observar en la taula els percentatges més comuns es troben entre el 0% i 45% de desnivell. Pel que fa desnivells de les franges 100%-173% i 173-275% són desnivells que equivalen a les franges 45o-60o i 60o-70o respectivament que malgrat es puguin considerar pendents difícilment assolibles caminant trobem alguns trams de rutes amb pendents pròxims als 60o.

Pel que fa a la diferència entre els percentatges de desnivell positiu i negatiu, aquesta és deguda a què la majoria de rutes escollides per l’estudi tenen més metres de baixada que de pujada. Aquesta característica per tant no ens afectarà pels successius estudis i decisions.

Un cop vista aquesta primera taula passarem a veure una segona taula on dividirem aquests percentatges en franges que ens permetran analitzar més acuradament com assignem les ponderacions a les diverses franges de percentatges.

Desniv. Positius

Desniv. negatius

0%-5% 17,76% 23,65%

5%-10% 11,66% 14,46%

10%-15% 5,93% 6,90%

15%20% 3,18% 3,94%

20%-25% 2,11% 2,39%

25%-30% 1,36% 1,20%

30%-35% 0,74% 0,78%

35%-40% 0,45% 0,60%

40%-45% 0,38% 0,29%

45%-100% 1,11% 0,80%

100%-173% 0,12% 0,13%

173%-275% 0,03% 0,05%

TOTALS 44,83% 55,17%

Taula 5. Estudi dels percentatges de desnivell mitjos separats en franges

Analitzant novament aquesta taula observem com malgrat hem agrupat els percentatges del 45% al 100% aquests continuen representant un petit percentatge del total.

Pel que fa als percentatges del 100% al 173% i del 173% al 275% hem decidit d’incloure’ls en la taula pel fet que són desnivells reals però que considerarem de màxima duresa.


67

5.3.3.1. Càlcul de l’Índex de dificultat

Per tal de definir un índex el més realista possible s’analitzaran diverses propostes que ens conduiran a la proposta definitiva d’un índex que ens permetrà avaluar de forma precisa la dificultat que representa realitzar una ruta.

Cadascun dels índexs que proposarem seguidament té en comú una ponderació dels percentatges que conformen una ruta. Tot seguit estudiarem com avaluar aquests desnivells.

Estudi pesos

Aquest estudi té per objectiu determinar quins són els pesos (increments de dificultat) més adequats per a cadascuna de les franges de desnivells anteriorment descrites. Per a la realització d’aquest estudi hem provat els diferents pesos en un conjunt de 10 rutes representatives (fàcils, mitjanes, difícils).

Definim els següents pesos:

• +5% per cada nova franja • +25% per cada nova franja • +50% per cada nova franja • +100% per cada nova franja

Figura 39. Estudi comparatiu de pesos

Tal i com observem en la gràfica observem grans diferències entre els índexs de dificultat obtinguts en rutes amb fort desnivell.

Aquestes diferències molt notables en l’ús dels increments del 50% i 100% de dificultat ens fan pensar que aquests increments no són adequats. L’opinió d’experts consultats confirma aquesta suposició ja que aquests ens han assegurat que no és cert que la dificultat entre les franges anteriorment assenyalades escali a raó del 50% o del 100% dificultat.

Analitzant els altres 2 pesos restants, 5% i 25% i consultant també l’opinió d’experts aquests han assegurat que un increment del 5% de dificultat entre franges és un increment massa petit que no dona valor a l’ increment de dificultat entre per exemple superar un desnivell del 6% i un del 14%.

050

100150200250300350400450500

Estudi comparatiu pesos

+5%

+25%

+50%

+100%


68

Per tots els motius anteriorment assenyalats considerem que assignar un increment del 25% de dificultat entre franges és un increment que dona un valor real a la dificultat afegida que suposa superar desnivells situats en diferents franges.

Estudi propostes ponderació

Un cop decidit l’ increment de dificultat entre marxes realitzarem un nou estudi que té per objectiu proposar i decidir quina de les polítiques de ponderació següents ens permet obtenir un resultats el més realistes possibles:

1. Es ponderen igual les pujades que les baixades: Es considera que pujar X metres representa el mateix esforç que baixar aquests X metres.

2. Es ponderen més les pujades que les baixades: Es considera que pujar X metres representa més esforç que baixar aquests X metres. Pujar sempre representa un 50% més d’esforç que baixar.

3. Es ponderen més les pujades que les baixades de forma lineal. En la franja del 100% al 275% es pondera igual pujar que baixar: Es considera que pujar representa més esforç (un 50% més) que baixar però, pujar i baixar un fort pendent representa un esforç aproximadament igual. Tenint en compte aquest tret hem definit els següents increments:

a. Del 0% al 100%: Pujar és un 50% més difícil que baixar. b. Del 100% al 275%: Pujar representa el mateix esforç que baixar, 15

vegades el pes inicial. 4. Es ponderen més les pujades que les baixades però de forma no lineal.

En la franja del 100% al 275% es pondera igual pujar que baixar: Es considera que pujar representa més esforç que baixar però aquest esforç no és lineal. És a dir pujar un cert desnivell no és sempre el 50% més difícil que baixar-ho. Tenint en compte aquest tret hem definit els següents increments:

a. Del 0% al 20%: Pujar és un 25% més difícil que baixar. b. Del 20% al 45%: Pujar és un 50% més difícil que baixar. c. Del 45% al 100%: Pujar és un 75% més difícil que baixar. d. Del 100% al 275%: Pujar representa el mateix esforç que pujar, 15

vegades el pes inicial.

Per tal de realitzar aquest estudi, novament hem realitzat les proves sobre un conjunt de 10 rutes representatives.

Els resultats d’aquest estudi novament han hagut de ser interpretats per experts degut a què resulta impossible avaluar la qualitat de l’índex sense tenir un coneixement ampli de les característiques de les rutes realitzades.

Seguidament analitzarem la qualitat de les diverses propostes utilitzant els resultats obtinguts en 2 rutes que per les seves característiques ens facilitaran la tasca de realitzar aquesta comparativa.


69

Figura 40. Comparativa propostes ponderació

Com ja s’ha esmentat anteriorment, s’han escollit aquestes 2 rutes pel fet que malgrat tenen unes característiques molt diferents:

• Carros de Foc: o Distància:60 Km o Desnivell acumulat: 8000 m

• Matagalls Montserrat: o Distància: 80 Km o Desnivell acumulat: 6000 m

Aquestes ens permeten descobrir realment si les nostres propostes ponderen més la distància que el desnivell. Com es pot observar en el gràfic les 4 propostes donen Carros de Foc com una ruta més difícil que Matagalls Montserrat, però això no permet descobrir quina de les 4 propostes és la millor.

Per fer-ho analitzarem la següent taula:

Carros de foc Matagalls Montserrat Diferència

Proposta 1 183 176 7



Proposta 4 199 185 13

Taula 6. Comparativa propostes ponderació

Analitzant la taula observem com la proposta 1 és la que ens dona una menor diferència entre els índexs de dificultat obtinguts. Aquest resultat és degut a què es considera que representa el mateix esforç pujar que baixar. Els experts han assegurat que això no és cert i per tant la descartarem directament.

Pel que fa a les altres propostes s’observa una clara similitud entre les propostes 2 i 3. Això és degut a què malgrat són propostes diferents, l’única diferència que tenen consisteix en avaluar de diferent forma el tram del 100% al 275%, que té una petita repercussió en aquests 2 rutes.

160

165

170

175

180

185

190

195

200

205

Proposta 1 Proposta 2 Proposta 3 Proposta 4

Comparativa propostes ponderació

Carros de foc

Matagalls Montserrat


70

Novament els experts consultats han assegurat que aquestes 2 propostes no es poden considerar correctes perquè no és cert que pujar sempre representi un 50% més de dificultat que baixar.

Finalment, analitzant la proposta 4, els experts consultats coincideixen en considerar que és la millor de les 4 propostes degut a què s’avaluen els pendents d’una forma pròxima a la dificultat real. Alhora, analitzant la taula i tenint en compte les característiques de les rutes analitzades es considera encertat que la proposta 4 sigui la que ens dona una major diferència entre l’índex de dificultat de les rutes analitzades ja que Carros de foc és una ruta més curta que Matagalls Montserrat però amb un desnivell molt més pronunciat i per aquest motiu cal considerar-la com una ruta molt més difícil que Carros de foc.

Elements exclosos de l’índex

Trobem un conjunt d’elements que malgrat condicionen la dificultat d’una ruta no són mesurables o bé depenen de l’estat físic de cada persona.

Els principals elements als que ens referim són:

• Climatologia: És un tret que pot afectar molt la dificultat d’una ruta però ens trobem amb el doble problema que és difícilment quantificable i apart és una dada que no la podrem obtenir del track. Diem que és difícilment quantificable pel fet que malgrat es pugui arribar a conèixer la climatologia d’un determinat període de temps no serem capaços de determinar com afecta aquella climatologia a la ruta perquè no depèn només de la climatologia actual sinó de la climatologia durant les hores anteriors així com del tipus de terreny. Per els motius anteriorment assenyalats la climatologia no formarà part de l’índex de dificultat.

• Terreny: De la mateixa manera que passa amb la climatologia el terreny és un tret que no podrem obtenir del track. Per aquest motiu hem decidit que aquest no formi part de l’índex de dificultat ja que incloure’l podria portar a errors provocats per un mala introducció dels tipus de terreny.

• Temps emprat: El temps que dura una certa ruta així com si és de nit o de dia són dades directament extraïbles del track. Com veurem més endavant però, i malgrat inicialment es va considerar oportú fer ús d’aquesta dada, finalment es va decidir que aquesta no formés part del track. Això és degut a un conjunt de problemes associats a l’ús d’aquesta dada que es detallaran més endavant.

Proposta Índex 1

En l’índex proposat hi intervindran 3 termes:

• Distància total: Distància total de la ruta en metres. • Ponderació de desnivells: Consisteix en ponderar les diferents franges de

percentatges anteriorment descrites amb un pes concret. • Ràtio altitud superiors als 2000m: Aquesta ràtio consisteix en dividir la

distància d’una ruta que transcorre per sobre els 2000m d’altitud per la distància total de la marxa. D’aquesta forma una ruta que no sobrepassi els 2000m d’altitud obtindrà una ràtio de 0 i en canvi les rutes amb algun tram sobre 2000m obtindran una ràtio superior a 0. Per tal de limitar el valor d’aquesta ràtio i evitar així resultats exagerats en les rutes amb un gran nombre de kilòmetres per sobre dels 2000m s’ha decidit que aquesta ràtio no pugui superar el 35%.


71

La formula de l’Índex de dificultat que proposem la definirem de la següent forma:

�� = �� !��<(�) + !��O��! �� << ∗ �1 + �� !LO� 2000� (�)�� !��< (�) �1000

Fórmula 16. Índex proposat 1

Trobem els resultats de l’Índex 1 a l’apartat 6.2.1.

Proposta Índex 2

Analitzant els resultats de l’enquesta de l’índex 1 (veure apartat 6.2.2) es pot observar com un ampli percentatge dels enquestats troben alguna deficiència en la forma com l’índex pondera certes rutes. Per aquest motiu s’ha decidit proposar un nou índex tenint en compte els diversos aspectes que els diferents enquestats han assenyalat.

Proposem els següents canvis respecte l’anterior índex:

• Ràtio Hores nit: Afegirem a l’índex la ràtio hores nit, amb l’objectiu d’afegir dificultat a una ruta en funció del nombre d’hores que s’han recorregut de nit. Aquesta ràtio consisteix en la divisió entre el nombre d’hores que es recorren de nit i el nombre d’hores totals.

• Eliminació terme Distància total: Analitzant l’anterior formula de l’índex hem pogut comprovar com el terme distància en metres no afecta al resultat de l’índex ja que és una dada que ja trobem expressada en la ponderació de desnivells i per tan únicament afegeix un offset a l’índex. Per aquest motiu hem decidit eliminar aquest terme de la fórmula.

Proposem el següent índex de dificultat:

�� = !��O��! �� << ∗ X1 + �� !LO� 2000� (�)�� !��< (�) � + � ℎ!O� �� (ℎ)ℎ!O� �!��< (ℎ)�Y1000


Aplicant aquest índex sobre el conjunt de les 12 rutes anteriorment usat, hem trobat un conjunt de problemes associats amb el càlcul de la ràtio de les hores de nit que recollim en el següent gràfic:


72

Figura 41. Problemes de càlcul de la ràtio hores nit

Tot seguit analitzarem cadascun dels problemes amb els quals ens hem trobat en realitzar el càlcul de la ràtio hores nit:

• Falta de dades: No tots els tracks dels quals disposem disposen del temps. Això pot ser degut a múltiples factor que tot seguit comentarem:

o Ús de receptors GPS antics: Certs receptors GPS no graven el temps en el track i per tant tots els tracks generats amb aquest tipus de receptors haurien de ser descartats.

o Tracks generats a partir de mapa: Actualment podem trobar tracks generats fent ús d’aplicacions que ens permeten traçar un recorregut d’una ruta sobre un mapa. Degut a què el track generat és una simulació no es graven els temps en el track. Novament hauríem de descartar els tracks generats a partir d’aquest tipus d’aplicacions.

o Tracks formats per múltiples tracks units: Podem trobar tracks generats a partir de la unió de múltiples tracks més curts. En aquest cas dependrà de la política de l’aplicació que utilitzem que podrà eliminar o mantenir els temps trobant-nos en aquest cas amb incoherències de temps.

• La dificultat es converteix en un tret subjectiu: Això és així pel fet que estem calculant aquesta ràtio a partir del temps que ha tardat l’autor del track en realitzar la ruta, i per tant la dificultat d’aquesta estarà condicionada pel fet en qüestió. Amb això es vol dir que la dificultat de la ruta pot variar molt en funció del temps que trigui cada individu en realitzar-la, i alhora si ho fa de nit o de dia.

Degut als problemes amb què ens hem trobat a l’hora de realitzar el càlcul de l’Índex 2 els resultats que es desprenen d’aquest índex no són complerts, és a dir, no hem pogut aplicar l’índex en totes les rutes que conformen l’estudi. Trobem els resultats de l’Índex 2 a l’apartat 6.2.3.

0

1

2

3

4

5

6

Unió de tracks Receptor Antic Realitzada

sobre mapa

Cap

Tipus problemes Temps

Nombre rutes


73

Proposta Índex 3

Tot seguit proposem un nou índex on es corregeixen tots els aspectes negatius dels índexs anteriorment assenyalats.

Proposem els següents canvis respecte l’anterior índex:

• Eliminació ràtio hores nit: Per tots els motius anteriorment assenyalats hem considerat oportú eliminar aquesta ràtio ja que aquesta no ens permet que l’índex de dificultat que proposem funcioni per totes les rutes.

• Ràtio de desnivell positiu: Afegirem a l’índex la ràtio desnivell positiu amb l’objectiu d’afegir dificultat a una ruta en funció del nombre del nombre de metres d’ascens positiu respecte de la distància total de la ruta. Aquesta ràtio per tant afegirà dificultat a aquelles rutes que malgrat puguin ser curtes tenen un gran desnivell positiu, per exemple la Travessa del Montseny.

Proposem el següent índex de dificultat:

�� !��O��! �� << ∗ X1 + �� !LO� 2000� (�)�� !��< (�) � + �� . ! . (�)�� !��< (�) �Y1000


Analitzant els resultats de l’índex 3 que trobem en l’apartat 6.2.4 i comparant-los amb els obtinguts en la proposta de l’índex 1 i alhora amb les conclusions extretes de l’enquesta al grup d’experts observem:

• No s’ha aconseguit que la dificultat associada a la Marxa dels Castells superi la Marxa del Garraf malgrat la diferència de dificultat entre ambdues s’ha vist reduïda. Això és degut a què són 2 rutes molt similars en quant a desnivell i distància. Considerem però que els experts es troben influenciats pel tipus de terreny que trobem en aquestes rutes (més dur en la marxa del Garraf) i per tant trobem correcte aquest resultat.

• S’ha aconseguit que la dificultat associada a la Travessa del Montseny incrementi fins al punt de superar a la Marxassa. Això és degut al fet que la Travessa del Montseny (45km) malgrat ser molt més curta que la Marxassa (63km) té un desnivell positiu molt fort i per aquest motiu i gràcies a la ràtio de desnivell positiu de la Travessa 57% respecte un 28% de la Marxassa s’ha aconseguit compensar la diferència de km entre ambdues marxes.

• S’ha aconseguit augmentar la dificultat de la TDS. Malgrat es pugui considerar que l’augment no és significatiu considerem que els experts han exagerat la dificultat d’aquesta ruta malgrat que 40Km són sobre 2000m pel fet que això només representa ell 32% del total del recorregut.

Fuzzificació de la dificultat de la ruta

Un cop obtingut un índex de dificultat numèric sembla necessari que els usuaris puguin associar aquest índex a una descripció de la dificultat de la ruta més pròxima al llenguatge natural.

Ens referim al fet que és positiu obtenir un valor numèric de la ruta perquè aquest ens dona precisió però alhora és important trobar una conversió directa d’aquest valor numèric a informació més fàcilment intel�ligible pels usuaris com és si la ruta és fàcil, mitjana, difícil, etc.


74

És important tenir en compte que aquest procés implica una subjectivació de la informació degut al fet que dependrà de l’estat de cada persona per considerar una certa ruta com una ruta fàcil o difícil. Hem agafat com a terme mig la referència d’una persona físicament preparada per a realitzar marxes de resistència a una velocitat mitja de 4Km/h i una velocitat d’ascens de 300m /hora.

Seguidament donarem aquestes equivalències:

Dificultat numèrica

Dificultat Llenguatge

Natural

0<Índex<60 Fàcil 60<Índex<150 Mitjana

150<Índex<300 Difícil Índex>300 Extrema

Taula 7. Equivalències de l’Índex de dificultat proposat amb el llenguatge Natural

5.3.4. Elecció generador perfil de ruta

Per tal de realitzar el perfil de la ruta vàrem decidir fer ús d’alguna llibreria que ens permetés pintar-lo sense necessitat d’entrar al pintat a baix nivell.

Per fer-ho inicialment vàrem fer ús d’una eina anomenada Jpgraph, aquesta és una llibreria de creació de Gràfics Orientada a Objectes. Aquesta llibreria està feta completament amb PHP i permet la creació de multitud de gràfics de forma senzilla. Aquesta llibreria internament usa una altre llibreria gràfica de PHP anomenada GD.

Figura 42. Perfil de ruta generat amb Jpgraph

Posteriorment vàrem observar com l’ús d’aquesta llibreria ens podria portar possibles problemes de rendiment pel fet que tot el procés de càlcul de tots els gràfics els realitza el servidor ja que tot el codi PHP és executat server-side.

Per aquest motiu vàrem realitzar una recerca d’alguna llibreria que ens permetés pintar gràfics però en aquest cas amb el prerequisit que fos client-side, es a dir que tot el procés de càlcul del gràfic el realitzés el client, no el servidor.

Aquesta recerca ens va portar a un llibreria anomenada flot, aquesta llibreria realitzada amb Javascript (llenguatge client-side) permet pintar gràfiques de forma senzilla i ràpida i amb un cost computacional 0 pel servidor.

Flot està desenvolupada amb Javascript però més concretament fent ús de Jquery que es tracta d’una llibreria que simplifica moltes operacions del llenguatge Javascript original. Algunes dels avantatges de l’ús de Jquery són una major simplicitat en el tractament d’events i en el tractament de les interaccions amb Ajax.


75

Aquesta llibreria ens ofereix un conjunt ampli de tipus de gràfiques diferents entre les quals es troben gràfiques de barres, línies, punts.

Altres funcionalitats interessants que ens ofereix l’eina són:

1. Possibilitat d’interactuar amb el gràfic podent ampliar, reduir o desplaçar-nos a través d’aquest.

2. Possibilitat d’obtenir informació d’un punt concret del gràfic clicant sobre aquest.

3. Possibilitat d’afegir sèries de dades al gràfic clicant a un botó de la pàgina.

Per tal de portar a cap la majoria d’aquestes funcionalitats es fa ús d’AJAX.

Típicament l’obtenció de les dades per l’elaboració de gràfics fent ús de flot es realitzarà a partir d’una consulta a una BBDD fent ús d’un llenguatge tipus PHP que ens permetrà extreure la informació necessària, serialitzar-la amb JSON i finalment la llibreria flot s’encarregarà de representar aquestes dades gràficament.

Per tal d’elaborar el perfil de ruta s’ha fet ús d’un gràfic de línies on a l’eix X trobem els km i a l’eix Y l’altitud.

Figura 43. Perfil de ruta generat amb flot

5.3.5. Correccions del track

Tot track presenta un conjunt d’incoherències degudes generalment a problemes de cobertura del receptor així com també d’errades degudes a mantenir-se molt temps en un mateix punt. Per tal d’intentar corregir aquests errors s’han pres algunes decisions que ens permeten filtrar certs punts susceptibles de contenir errades.

Aquestes correccions giren al voltant de 2 aspectes que tot seguit esmentarem:

1. Distància mínima entre punts: S’ha considerat oportú fixar un llindar mínim de metres que ens permetessin diferenciar si la persona que estava realitzant la ruta es trobava aturada o bé es trobava en moviment. Analitzant diversos tracks de diferents característiques s’ha determinat que una persona que es troba caminant ha de realitzar un mínim de 3.5 metres entre 2 punts del track. El problema que trobem ve donat pel fet que el receptor GPS recull dades a intervals no coneguts que solen trobar-se entre els 4s i els 30s. Suposant però el cas més restrictiu, és a dir un interval de 4s, obtenim que la velocitat mínima per ser considerat que estem en moviment ha de ser de 0.875 m/s (3.5m/4s) o 3.15Km/h velocitat que considerem prou baixa com per no descartar punts vàlids dels track.


76

2. Desnivell mínim: De la mateixa manera que passava amb la distància mínima entre punts s’ha considerat oportú fixar un llindar mínim de desnivell per ser considerat que estem ascendint / descendint. Aquest llindar es fa molt necessari en el càlculs dels desnivells en rutes on el marxaire s’ha aturat molta estona. Això és degut al fet, que quan el receptor GPS es troba en una mateixa posició es produeixen petites variacions en l’obtenció de l’altura. Si no tinguéssim aquest llindar aquestes petites variacions serien considerades com una diferència de desnivell i per tant estaríem introduint un error en el càlcul dels desnivells. Per tal de corregir aquestes errades, varem fixar un desnivell mínim d’1 metre. Això significa que per tal de considerar que estem realitzant un cert desnivell positiu o negatiu la distància vertical entre 2 punts d’un track ha de superar 1 metre.

Això però, tampoc impedia introduir un cert error en el càlcul dels desnivells i per aquest motiu es va decidir combinar aquest llindar amb el llindar anteriorment definit.

D’aquesta forma per considerar un cert desnivell entre 2 punts d’un track aquests 2 punts hauran de complir les 2 condicions anteriorment esmentades:

• La distància entre ambdós punts haurà de ser com a mínim de 3.5 metres • La distància vertical entre ambdós punts haurà de ser com a mínim d’1

metre.

5.3.6. Tipus d’informació a carregar en l’aplicació

Tal i com es descrivia en l’apartat 2.3, l’aplicació que s’està dissenyant ha de permetre la càrrega d’informació relativa a marxes oficials (aquelles rutes organitzades per una entitat) i de rutes (aquelles sortides no organitzades per cap entitat). Fins el moment però, no s’ha definit què passa amb aquelles rutes o marxes de les quals no se’n disposa el track.

Degut al fet que l’objectiu primordial de l’aplicació que s’està dissenyant és compartir la major quantitat de rutes o marxes possible s’ha decidit que també es puguin afegir aquelles rutes o marxes de les quals no se’n disposi del track.

Aquesta decisió origina la distinció entre 4 casos diferents que cal distingir degudament:

1. Rutes amb track: En aquest cas, únicament es donarà a l’usuari la possibilitat d’editar aquella informació sensible a contenir errades o no trobar-se complerta com és el cas de:

a. Nom de la ruta b. Descripció de la ruta

2. Rutes sense track: En aquest cas i degut al fet que no es disposa del track es demanarà a l’usuari tota aquella informació més rellevant d’una ruta com:

a. Nom de la ruta b. Descripció de la ruta c. Distància d. Desnivell Positiu e. Desnivell Negatiu

3. Marxa amb track: En aquest cas es demanarà a l’usuari de complementar totes aquelles dades de l’edició que no són extraïbles del track. D’entre aquest conjunt de dades però, caldrà distingir aquelles que cal complimentar de forma obligada d’aquelles que no. Les dades que cal omplir de forma obligada són:


77

a. Nom Marxa b. Numero d’edició

Cal fer notar que el nom de la marxa i el numero d’edició són 2 dades rellevants que ens permetran classificar les marxes respectant la següent casuística:

• Nom de la marxa inexistent en la BBDD: En aquest cas s’inserirà la nova marxa juntament amb tota la informació relacionada amb l’edició.

• Nom de la marxa existent en la BBDD: En aquest cas i degut al fet que la marxa ja es troba definida en la nostra BBDD inserirem en la BBDD únicament aquella informació relacionada amb l’edició.

Aquest procés ens permetrà definir les característiques de les diferents edicions d’una mateixa marxa.

Per altra banda trobem un conjunt de dades que no s’han de complementar obligatòriament però, que ens permetran captar informació rellevant de l’edició de la marxa com són:

a. Pàgina Web b. Nombre d’Avituallaments líquids c. Qualitat dels Avituallaments líquids d. Nombre d’Avituallaments sòlids e. Qualitat dels Avituallaments sòlids f. Tipus de Senyalització g. Grau de Senyalització h. Data i. Hora de sortida j. Preu k. Màxim de participants l. Temps mínim m. Temps màxim n. Material necessari o. Tipus de terreny

4. Marxa sense track: Aquest cas serà complementari de l’anterior ja que en aquest es demanaran a l’usuari totes aquelles dades extraïbles i no extraïbles del track. En aquest cas també es distingirà entre aquelles dades que cal complementar obligatòriament d’aquelles que no. Així el conjunt de dades que cal complementar obligatòriament són:

a. Nom Marxa b. Numero d’edició c. Distància Oficial d. Desnivell Positiu Oficial e. Desnivell negatiu Oficial

En aquest cas, també tindrà lloc el procés de diferenciació de les edicions d’una mateixa marxa definit anteriorment.

Pel que fa al conjunt de dades que no s’han de complementar obligatòriament, aquestes són comunes amb l’anterior cas.


78

5.3.7. Implementació del Recomanador

Objectiu del recomanador

La implementació d’un recomanador té per objectiu suggerir certes rutes als usuaris a partir d’un conjunt de criteris i condicions que tot seguit detallem:

Es pretén realitzar les recomanacions a partir d’un conjunt d’atributs que tot seguit es detallen:

1. Distancia 2. Desnivell acumulat 3. Altitud mitjana 4. Altitud màxima 5. Nombre de kilòmetres amb +2000m altitud

L’objectiu del recomanador serà mostrar-nos els parells de rutes més pròximes tenint en compte els anteriors atributs. Aquesta cerca obeirà 3 criteris diferents:

1. Recomanar rutes que siguin pròximes a la ruta més difícil realitzada per l’usuari fins el moment. Quedaran excloses de la recomanació aquelles rutes que l’usuari ja hagi realitzat.

2. Recomanar rutes que siguin pròximes a la dificultat mitja de les rutes realitzades per l’usuari fins el moment. Quedaran excloses de la recomanació aquelles rutes que l’usuari ja hagi realitzat.

3. Recomanar rutes que obeeixin als criteris especificats per l’usuari.

Elecció del mètode a implementar

Un cop analitzades les diferents tècniques que ens permeten realitzar recomanacions als usuaris (Apartat 2.5) en aquest apartat s’estudiarà quina de les tècniques s’ha implementat i quines decisions s’han hagut de prendre en la implementació d’aquesta.

Per tal de decidir si implementar un KNN o un CBR inicialment va sorgir la necessitat de descriure les característiques del problema que es pretén resoldre. Aquest es troba caracteritzat per:

• Es disposa inicialment d’unes 25 rutes amb un gran nombre d’atributs per cada una d’elles

• No és rellevant que hi hagi aprenentatge degut al fet que la resposta que el recomanador dona no té perquè ser sempre la millor possible

Un cop definides les característiques del problema que ens afecta es considera que un KNN no satisfà els objectius als quals es pretén arribar degut al fet que aquest ens permet recuperar dades però, un cop fet això no es produeix un feedback amb l’usuari (en aquest cas cada usuari serà considerat un expert).

És a dir, el KNN permet recuperar dades però no disposa d’una fase de revisió en què l’usuari pugui rebutjar les dades obtingudes en cas de que aquest no hi estigui d’acord. És per aquest motiu que sorgeix la necessitat d’implementar un CBR.


79

Implementació del CBR

Tal i com s’explicava en l’apartat 2.5 d’aquesta memòria, un CBR disposa de 4 fases.

La implementació d’un CBR però, no implica que s’hagin d’implementar obligatòriament les 4 fases. Així un CBR amb 2 de les 4 fases seguirà essent considerat un CBR.

El problema que es vol resoldre no necessita fer ús de les 4 fases d’un CBR. Tot seguit s’indicarà quines fases s’han implementat i els motius que han portat a no implementar-ne d’altres:

o Fase de recuperació: En aquesta fase es produirà la recuperació de les rutes que compleixin amb els criteris anteriorment esmentats. Prèvia a aquesta recuperació es portarà a cap un procés de normalització de les dades pel fet que no fer-ho causaria problemes de predominança de certs atributs per sobre d’altres. Aquesta recuperació es farà fent ús d’una funció de distància Euclidiana. S’ha decidit fer ús d’aquesta funció de distància pel fet de que és una funció que resulta adequada per la gran majoria de problemes. Apart i com ja s’ha esmentat anteriorment, el procés de cerca de la millor funció de distància per el nostre problema és un punt que ha quedat fora de l’abast del nostre projecte.

o Fase de reutilització: Aquesta fase no s’implementarà pel fet que no ens caldrà adaptar els casos recuperats en la fase de recuperació.

o Fase de revisió: En aquesta fase l’usuari que serà considerat un usuari expert revisarà el resultat obtingut i el podrà acceptar o rebutjar en el cas de no estar d’acord amb la solució proposada. En cas de rebutjar una solució es repetirà el procés fins que l’usuari aprovi la solució proposada.

o Fase d’emmagatzemament: Aquesta fase no s’implementarà pel fet que no es farà ús de la memòria de casos. El recomanador no tindrà aprenentatge.


80

5.4. Disseny Tècnic

5.4.1. Diagrama Entitat Relació

Figura 44. Diagrama Entitat Relació

Aquest diagrama Entitat Relació s’ha definit fent ús de la notació Chen, en el qual tal i com i es pot comprovar únicament apareixen les relacions entre les diverses taules.

S’observa com les entitats principals són Edició i Track.


81

5.4.2. Diagrama de Paquets

Figura 45. Diagrama de paquets

En el diagrama s’observen els principals paquets de l’aplicació que presentem. Pot sobtar que no tots els paquets es trobin relacionats entre sí. Això és degut a que són paquets independents entre si. Tots aquests paquets seran cridats des d’una pàgina principal.


82

6. Resultats

6.1. Introducció

En aquest apartat es recolliran i comentaran els resultats obtinguts al llarg de tot l’estudi. Els resultats que presentem seran extrets de les diferents proves realitzades sobre l’índex de dificultat així com del recomanador de rutes.

6.2. Resultats de l’Índex de dificultat

En els següents apartats trobarem l’anàlisi dels resultats obtinguts dels diferents estudis que ens han portat a la definició d’una proposta definitiva d’un índex de dificultat propi.

6.2.1. Resultats Índex 1

Aplicant l’índex 1 al conjunt de 12 rutes següents hem obtingut els següents resultats:

Ruta Dificultat

Carros de foc 199

Matagalls Montserrat 185

Marxassa 145

Viladrau - La Garriga 72

Trav. Montseny 139

UTSM 248

Marxa del Garraf 109

UTMB CCC 310

NQ 309

Marxa dels castells 123

UTMB TDS 342

UTMB 514

Taula 8. Resultats índex de dificultat 1

6.2.2. Resultats de l’Enquesta de qualitat de l’índex 1

Per tal de valorar la qualitat de l’índex 1 es va decidir passar una enquesta (veure Annex) a un grup d’experts per tal de valorar si trobaven encertat l’índex, i en cas negatiu que esmentessin com es podria millorar.

Tot seguit presentem els resultats que hem extret de l’enquesta:

• Un 40% dels experts ens han comentat que l’índex de dificultat assignat a la marxa dels castells és massa alt en comparació a la Marxa del Garraf ja que la dificultat real de la Marxa del Garraf és força major que la marxa dels castells

• Un 20% dels experts ens han comentat que la TDS hauria de ser més dura pel fort desnivell que cal superar i pels més de 40 Km que transcorren per sobre dels 2000m.

• Un 40% dels experts ens han comentat que l’índex de dificultat assignat a la Travessa del Montseny hauria de ser major, fins al punt de superar a l’Índex de la Marxassa.


83

• Un 13% dels experts han comentat que Carros de Foc no és pot valorar en aquest estudi pel fet que és la única marxa que no està marcada explícitament.


Aplicant l’índex 2 al conjunt de 12 rutes següents hem obtingut els següents resultats:

Ruta Dificultat

Carros de foc No calculable

Matagalls Montserrat No calculable

Marxassa No calculable


Trav. Montseny 132

UTSM 207

Marxa del Garraf 78

UTMB CCC No calculable

NQ No calculable


UTMB TDS No calculable

UTMB No calculable


Han quedat exclosos de l’enquesta els comentaris relacionats amb dades no extraïbles del track com són tipus de terreny, temperatura, etc. Això és degut a què ens interessa dissenyar un índex calculable exclusivament a partir de dades que puguem extreure del track pel fet que això ens permetrà ser menys dependents de la fiabilitat de les dades que introdueixi l’usuari.


Aplicant aquest índex al conjunt de 12 rutes usat al llarg de tot l’anàlisi de l’índex hem obtingut els següents resultats:

Ruta Dificultat

Carros de foc 202

Matagalls Montserrat 147

Marxassa 106


Trav. Montseny 131

UTSM 212

Marxa del Garraf 85

UTMB CCC 327

NQ 337


UTMB TDS 353

UTMB 540



84

6.2.5. Comparativa de l’Índex proposat amb altres Índexs

Un cop arribat a un índex de dificultat definitiu es necessari realitzar una comparativa amb d’altres Índexs existents per tal avaluar la fiabilitat d’aquest índex proposat. La comparativa es realitzarà amb 3 índexs que són el de la FEEC, el de la UTMB i finalment l’IBP.

Cal fer notar que en aquesta comparativa s’ha afegit l’índex IBP perquè és un índex de referència dintre del món del ciclisme i malgrat afegir-lo en l’estudi ens suposi grans diferències respecte índexs específicament dissenyats per senderisme considerem interessant observar i analitzar les diferències entre aquests índexs.

Per tal de realitzar aquesta comparativa inicialment vàrem realitzar el càlcul de tots els índexs per totes les rutes que conformen el nostre estudi obtenint la següent taula:

Ruta Índex

Proposat FEEC UTMB IBP

Viladrau - La Garriga 58 6 40 103

Marxa del Garraf 85 9 62 127

Marxa dels castells 90 9 63 125

Marxassa 106 12 81 109

Trav. Montseny 131 11 73 233

Matagalls Montserrat 147 15 107 221

Carros de foc 202 16 102 182

UTSM 212 20 146 279

CCC 327 24 168 497

NQ 337 26 173 378

TDS 353 25 175 533

UTMB 540 40 280 425

Taula 11. Comparativa d’índexs

Tal i com es pot observar les dades obtingudes dels diversos índexs tenen diferents rangs numèrics i per tant a simple vista resulta impossible realitzar una comparativa entre aquestes.

Per tal de solucionar això es va considerar oportú realitzar un normalització d’aquestes a partir de la següent fórmula:

��O�L��ZW[*\'] = X��O�L��\�] − min_�!<��_�!< − min_�!< Y ∗ 100

Fórmula 19. Normalització d’atributs


85

Un cop aplicada aquesta normalització obtenim els següents valors, ordenats pel valor de l’índex proposat:

Ruta Índex

proposat FEEC UTMB IBP

Viladrau - La Garriga

0,00 0,00 0,00 0,00

Marxa del Garraf 5,57 8,82 9,17 5,58

Marxa dels castells

6,61 8,82 9,58 5,12

Marxassa 9,94 17,65 17,08 1,40

Trav. Montseny 15,23 14,71 13,75 30,23


18,41 26,47 27,92 27,44

Carros de foc 29,96 29,41 25,83 18,37

UTSM 31,91 41,18 44,17 40,93

UTMB CCC 55,90 52,94 53,33 91,63

NQ 57,89 58,82 55,42 63,95

TDS 61,21 55,88 56,25 100,00

UTMB 100,00 100,00 100,00 74,88

Taula 12. Comparativa d’índexs normalitzada

Cal fer notar que la normalització aplicada força el valor 0 a la ruta amb un índex més petit i un valor de 100 a la ruta amb un índex més gran. Aquest fet no condicionarà excessivament el nostre estudi pel fet que únicament ens caldrà excloure aquests valors de l’estudi per tal de que aquest sigui el més precís possible.

Observant aquesta taula ens adonem com els resultats de l’Índex proposat respecte als índexs de la FEEC i de la UTMB són força similars. En canvi comparant l’Índex proposat amb l’IBP observem notables diferències.

Seguidament es passarà a analitzar en detall tots els índexs realitzant una comparativa d’aquests respecte a l’índex proposat.

Comparativa de l’índex proposat respecte l’índex de la FEEC

En aquesta primera comparativa observem com els resultats obtinguts en ambdós índexs són molt similars. Les diferències més notables les trobem en rutes molt llargues però amb un desnivell petit. Això és degut al fet que l’Índex proposat assigna poca dificultat als trams amb poc desnivell. Malgrat aquest fet, considerem que els resultats obtinguts són molt positius.


86

Figura 46. Comparativa Índex proposat respecte l’Índex de la FEEC

Comparativa de l’índex proposat respecte l’índex de la UTMB

En aquesta segona comparativa observem com els resultats malgrat segueixen essent similars són lleugerament més diferenciats que en l’anterior comparativa. Aquesta diferència és deguda al fet que l’índex UTMB pondera més la distància que el desnivell i per tant la diferència entre ambdós índexs es fa notable en les rutes amb un gran nombre de kilòmetres i un desnivell positiu petit en comparació amb la seva distància com són els casos de la UTSM (100 Km i 4500 m de desnivell positiu) i la Matagalls Montserrat (78 Km i 2900 m de desnivell positiu).

Figura 47. Comparativa Índex proposat respecte l’Índex de la UTMB

0,00

10,00

20,00

30,00

40,00

50,00

60,00

70,00

Comparativa respecte l'índex FEEC

Index proposat

Index FEEC

0,00

10,00

20,00

30,00

40,00

50,00

60,00

70,00

Comparativa respecte l'índex UTMB

Index proposat

Index UTMB


87

Comparativa de l’índex proposat respecte l’índex IBP

En aquesta darrera comparativa observem com els resultats obtinguts són molt diferents que en les anteriors comparatives pel fet que l’índex IBP és un índex específicament dissenyat per l’avaluació de la dificultat de les rutes realitzades amb bicicleta.

Tenint en compte aquest tret i analitzant en detall el gràfic observem com s’han exclòs del gràfic 3 de les 12 rutes que conformen l’estudi. Això és degut al fet que la normalització força el valor de 0 a la ruta amb un índex més petit (Viladrau - La Garriga) i un valor de 100 a la ruta amb un índex més gran. En aquesta comparativa analitzant la taula observem com la ruta amb un índex proposat més elevat és la UTMB amb un valor de l’índex proposat de 540, i en canvi la ruta amb un índex IBP més elevat és la TDS amb un valor de 533. Aquest fet provoca que un cop normalitzem totes les dades, les rutes anteriorment esmentades agafin un valor de 100, fet pel qual ens hem vist obligats a excloure del gràfic.

Analitzant el gràfic observem grans diferències entre els índexs de diverses rutes, això és degut al fet que l’índex IBP pondera molt les rutes amb forts desnivells pròxims al 30%, pel fet que aquests requereixen un gran esforç de superar amb bicicleta.

Així, analitzant en detall els valors obtinguts en la ruta CCC i comparant-los amb les de la NQ observem una gran diferència entre els índexs IBP (malgrat són 2 rutes molt similars) i en canvi una petita diferència entre els índexs proposats. Com ja hem esmentat aquesta diferència entre els IBP’S és deguda als forts desnivells. Seguidament observarem una taula resum que ens permetrà analitzar aquest fet més detalladament:

CCC NQ

20%-25% 4204 2152

25%-30% 2210 1453

Taula 13. Comparativa Índex IBP

Tal i com observem en la taula resum, la gran diferència entre aquests índexs ve donada pel fet que la ruta CCC té un nombre major de metres amb fort desnivell que la NQ i malgrat aquestes rutes tinguin unes característiques molt similars (en quant a distància i desnivells) aqueta diferència de desnivell es sobreposa a qualsevol altre factor.


88

Figura 48. Comparativa Índex proposat respecte l’Índex IBP

6.3. Tests de l’Aplicació

Per tal de comprovar el correcte funcionament de l’aplicació s’han realitzat un ampli conjunt de tests.

El procediment que s’ha seguit per tal de testejar cada mòdul de l’aplicació ha estat:

• Proves de caixa negra: Amb l’objectiu de comprovar si els resultats obtinguts coincidien amb els resultats esperats (calculats amb d’altres mètodes). Aquestes proves degut al fet que nosaltres mateixos actuàvem a l’hora de programador i de tester ens han permès evitar un dels inconvenients de les proves de caixa negra anomenat blind exploring que significa que el tester desconeix quines són les parts del mòdul més sensibles a produir errades.

• Proves de caixa blanca: Amb l’objectiu d’analitzar amb profunditat certs detalls de la implementació interna susceptibles de produir errades. Aquests proves a nivell dels mòduls de l’aplicació es consideren proves d’unitat pel fet que tenen per objectiu provar cadascun dels mètodes de cadascuna de les nostres classes.

Un cop testejats els diferents mòduls de l’aplicació s’han portat a cap els test d’integració que tenen per objectiu comprovar que la integració de 2 mòduls que no contenien errades pugui provocar algun tipus d’errada.

Els tipus de test d’integració que s’han portat a cap han consistit en testejar la integració de pocs mòduls alhora (generalment 2) per tal de facilitar la tasca de detecció d’errades.

Un cop descrit el procediment general que s’ha seguit per testejar l’aplicació, tot seguit es detallaran els procediments específics que tenen per objectiu testejar certes parts rellevants de l’aplicació.

6.3.1. Tests dels tracks

Per tal d’assegurar-nos que tots els tipus de tracks siguin correctament parsejats i analitzats per l’aplicació es van realitzar un conjunt de tests amb un conjunt de 25 tracks diferents.

0,00

20,00

40,00

60,00

80,00

100,00

Comparativa respecte l'Índex IBP

Index proposat

Index IBP


89

Aquests tracks presentaven un conjunt de diferències amb l’objectiu de detectar i corregir els problemes que aquestes poguessin ocasionar en els diferents elements que depenen directament de la informació del track com són:

• Parser d’XML: Aquest és l’encarregat de parsejar tot el track i hem d’assegurar que ho fa de forma correcte i en tots els casos.

• Analitzador del track: Aquest és l’encarregat de realitzar els càlculs de distància, desnivell, temps, etc un cop el parser ja ha processat tot el track.

• BBDD: Encarregada d’emmagatzemar tota la informació del track. Hem d’assegurar que ho fa de forma correcta.

• Interfície: Encarregada de mostrar la informació del track emmagatzemada en la BBDD. Cal assegurar que la informació consultada fa referència al track correcte i que aquesta mostra la informació adequada en totes les casuístiques possibles.

Tot seguit analitzarem cadascuna de les diferències entre el conjunt de tracks de test:

• Tracks amb un nombre diferent de punts: S’han analitzat tracks amb un nombre molt diferent de punts, des dels 300 punts a més de 11000. Aquesta prova tenia per objectiu observar el rendiment del parser i de la BBDD alhora d’analitzar tracks amb un gran nombre de punts.

• Tracks de diferent longitud: S’han analitzat tracks de distància molt diferent, dels 4km als 200km. Aquesta prova tenia per objectiu comprovar si els càlculs de distància seguien essent correctes fos quina fos la distancia d’aquests.

• Tracks amb diferent desnivell: S’han analitzat tracks amb un desnivell molt diferent, dels 500 m de desnivell positiu/negatiu als 10000m, amb l’objectiu de comprovar si els càlculs de desnivell són correctes en tots els casos.

• Tracks circulars i no circulars: S’han analitzat tan tracks circulars com no circulars amb l’objectiu de comprovar si l’analitzador reconeix els tracks circulars. Aquesta prova apart permet comprovar si els càlculs de desnivell són correctes pel fet que les rutes circulars han de tenir un desnivell positiu i negatiu molt similars.

• Tracks geogràficament molt dispersos: S’han realitzat proves amb tracks d’arreu del món per tal de comprovar si el mapa es mostra correcte amb independència del punt geogràfic on ens trobem. Alhora aquesta prova tenia per objectiu comprovar si el mètode que ens permetia trobar les població d’inici i fi de ruta funcionava correctament.

• Tracks amb i sense waypoints: S’han realitzat proves amb tracks que contenien waypoints per tal de comprovar si el parser els detectava correctament i aquests eren emmagatzemats a la BBDD i mostrats sobre el mapa satisfactòriament. També s’han realitzat proves amb tracks sense waypoints per tal de comprovar si aquests provocaven errades en el parseig d’aquests.

• Tracks amb i sense el camp time: El camp time és el camp que ens dona informació del temps de pas per un determinat trackpoint o waypoint. Les proves de tracks amb el camp time han permès comprovar la correctesa dels càlculs de:

o Temps total o Temps moviment o Velocitat mitjana total o Velocitat mitjana en moviment


90

Relacionat amb el camp time s’han realitzat proves amb tracks amb moltes aturades per tal de comprovar si el càlcul del temps en moviment i de retruc el càlcul de la velocitat mitjana en moviment es veien afectats pel nombre i/o per la durada d’aquestes. Aquestes proves van ocasionar errades en l’aplicació que varen ser corregides i es troben documentades degudament en l’apartat anomenat “Correccions del track”.

Les proves sense el camp time tenien per objectiu comprovar si l’absència d’aquest era correctament gestionada tan pel parser com per la interfície.

• Tracks extrets de diferents activitats: S’han realitzat proves amb tracks realitzats durant la pràctica de diferents esports apart del senderisme, com córrer, bicicleta, esquí nòrdic, etc. Aquestes proves tenien per objectiu comprovar si un canvi en la velocitat a la qual va l’esportista podria generar problemes a l’hora d’analitzar el track.

Com s’ha pogut observar les proves amb tracks diferents tenien per objectiu comprovar el correcte funcionament dels elements que depenien directament del track.

6.3.2. Tests dels formularis

Per tal de realitzar proves sobre els formularis s’han realitzat els següents tests:

• Proves amb camps buits: S’han realitzats proves deixant buits certs camps dels formularis. Tots aquells camps que deixant-los buits es generava algun error s’ha assegurat que l’usuari no pugui deixar buits mitjançant javascript.

• Camps amb dades de tipus incorrecte: S’han realitzat proves introduint dades de tipus incorrectes sobre certs camps. Per exemple, en el camp distància s’ha introduït text en comptes de nombres. Tots aquells camps que per aquest fet han provocat un error ja sigui a la BBDD com al controlador s’ha assegurat que l’usuari no pugui provocar aquests errors fent ús de codi javascript.

• Proves amb caràcters “perillosos”: S’han realitzat proves introduint caràcters que poden provocar problemes de seguretat i d’inserció a la BBDD com són els caràcters “;” “-“ “‘”.


91

7. Cost de realització del projecte

En aquest apartat realitzarem una estimació de les hores dedicades a desenvolupar aquest Projecte Final de Carrera.

Aquesta estimació vindrà dividida en 6 etapes:

• Estudi i investigació • Anàlisi de requeriments • Disseny de l’aplicació • Implementació • Tests • Elaboració de la Memòria

La següent taula mostra la distribució de les hores dedicades en cadascuna de les etapes anteriorment definides:

Hores

estimades Percentatge

Estudi i investigació 250 30,67%

Anàlisi de requeriments 45 5,52%

Disseny de l’aplicació 100 12,27%

Implementació 235 28,83%

Tests 35 4,29%

Elaboració de la Memòria 150 18,40%

TOTAL 815 100,00%

Taula 14. Cost aproximat del projecte

Tal i com es pot veure en la taula la fase d’estudi i investigació ha esdevingut la més gran degut a la necessitat de familiaritzar-nos amb els GPS, el Framework, CBR, etc.


92

8. Conclusions

Les conclusions, les estructurarem en 4 parts clarament diferenciades: la primera farà referència a l’eina implementada analitzant-ne els seus avantatges i inconvenients respecte altres eines similars; la segona farà referència a l’elecció de l’entorn utilitzat; la tercera, a l’anàlisi de la metodologia de programació usada; i, per últim, es descriurà què ens ha aportat a càrrec personal la realització d’aquest projecte.

Considerem que malgrat existeixen diferents eines que realitzen una funció similar a la nostra, hem realitzat una eina en certa mesura innovadora. Considerem això pel fet que no només es dóna importància a l’extracció de coneixement de les rutes sinó que, alhora, es permet que els usuaris puguin disposar de tota la informació útil de marxes oficials de forma centralitzada sense la necessitat de consultar el lloc web de cadascuna de les marxes.

L’extracció de coneixement s’ha realitzat en dues línies d’actuació diferents. Per una banda, en la proposta i implementació d’un índex de dificultat, que permet avaluar la dificultat de rutes de forma precisa, realitzant una anàlisi detallada del track. I per altra banda, en la implementació d’un recomanador que permet realitzar recomanacions als usuaris en funció del seu perfil i de les seves preferències.

Pel que fa a la gestió d’informació de marxes oficials, tot usuari podrà afegir i consultar informació d’aquestes que es trobarà organitzada per data i agrupada per edicions. Això permetrà que qualsevol usuari pugui consultar informació relativa a qualsevol edició de qualsevol marxa i de forma senzilla.

Com a contrapartida, la nostra eina no disposa d’algunes funcionalitats que d’altres eines sí que disposen. Pel que fa a l’anàlisi de diferents tipus de tracks, la nostra eina únicament és capaç de parsejar tracks tipus GPX, en canvi altres eines (com Wikiloc) permeten analitzar tracks amb multitud de formats diferents. Això, malgrat pugui semblar un gran desavantatge respecte altres eines no ho és, pel fet que GPX és un format estàndard compatible amb la gran majoria de dispositius GPS.

En referència a la interfície de presentació de la ruta considerem que malgrat s’ha aconseguit presentar la informació de forma clara i concisa, altres eines (com són el cas de Garmin Connect o EveryTrail) ho fan d’una forma més amigable. Això és degut al fet que l’objectiu de l’aplicació que presentem no es troba centrat en la presentació dels resultats sinó en l’extracció d’informació valuosa de les dades.

En relació a l’elecció de l’entorn utilitzat, des d’un inici es va definir que es faria ús d’un entorn Web degut a dos motius principals: el primer es troba lligat amb l’objectiu de l’aplicació, basat amb el fet de poder compartir informació de rutes entre un comunitat d’usuaris i el segon, lligat estretament amb el primer, consisteix en que els usuaris puguin accedir a aquesta informació de forma fàcil, sense instal�lar cap software addicional.

Pel que fa a l’elecció del llenguatge de programació amb que desenvoluparíem l’aplicació varem avaluar diverses possibilitats entre les que es trobaven ASP, Java i PHP. Finalment es va elegir PHP pel fet de ser un llenguatge conegut per nosaltres, àmpliament usat per un gran comunitat de programadors, amb molta documentació disponible i amb una llicència de software lliure.


93

Potser el punt del qual cal fer-hi un èmfasi especial és la metodologia de programació usada. Aquesta s’ha caracteritzat, bàsicament, per fer ús d’una arquitectura de software Model-Vista-Controlador. Fer ús d’aquesta arquitectura, juntament amb l’ús d’Smarty per al disseny de les interfícies ens ha permès desenvolupar l’aplicació d’una forma estructurada i ràpida.

La principal característica d’aquesta arquitectura però, consisteix en que l’aplicació és fàcilment escalable i permet realitzar un acurat manteniment degut a la gran modularitat d’aquesta, podent d’aquesta forma realitzar canvis en un dels mòduls sense que els altres se’n vegi afectats.

Relacionat amb la facilitat per a realitzar canvis en l’aplicació, i gràcies al fet que s’ha fet ús de la llibreria ADOdb, s’ha aconseguit deslligar completament les querys d’un Sistema de Gestió de BBDD concret, d’aquesta forma qualsevol canvi de Sistema Gestor no implicarà haver d’alterar el codi.

Pel que fa als estàndards de codi que s’han seguit (com són seguir una nomenclatura concreta en els noms dels fitxers així com en els noms de les classes entre d’altres) ens han permès aconseguir un doble objectiu: per una banda, facilitar-nos la tasca com a programadors de l’aplicació i, per altra, facilitar la tasca a futures persones que puguin arribar a millorar l’aplicació.

A càrrec personal la realització d’aquest projecte ens ha aportat un gran nombre de coneixements en diferents camps.

Des d’un inici ens va aportar familiaritzar-nos amb eines àmpliament utilitzades en el disseny de projectes diversos com és el fet de redactar un SRS (Software Requirements Specification). Això malgrat que inicialment ens va causar alguns inconvenients ens ha estat de gran utilitat pel fet que ens va obligar a especificar des d’un inici els diferents mòduls que composaven l’aplicació, així com aspectes relatius al sistema operatiu, hardware i software addicional.

Relacionat amb la programació de l’aplicació, la realització d’aquest projecte ens ha aportat conèixer un gran nombre d’eines i metodologies. Ens referim al fet de seguir una metodologia MVC, fer ús d’un Framework, fer ús d’un sistema de Control de Versions i en definitiva conèixer el conjunt d’eines i tècniques que caracteritzen la realització de grans aplicacions Web (entorn professionalitzador).

En referència amb els llenguatges de programació usats, s’han consolidat els conceptes de PHP i s’ha observat la importància que té actualment Javascript i les seves variants com és el cas de Jquery àmpliament usats en aquest projecte així com en la gran majoria d’aplicacions avui en dia. Això és així pel fet que Javascript té multitud d’aplicacions com són AJAX, control de formularis, gràfics etc.

Per altra banda, i en referència als llenguatges que permeten el intercanvi d’informació estructurada entre diferents plataformes com són XML i JSON, s’ha observat com malgrat JSON presenta avantatges substancials respecte XML, aquest segueix essent àmpliament usat. Això és degut al fet que JSON permet serialitzar estructures de dades poc complexes de forma senzilla però, per altra banda, malgrat XML és més costós de parsejar, permet gestionar dades de qualsevol mida i complexitat. D’aquesta forma concloem que en funció de les característiques dels problemes que es vulguin resoldre caldrà escollir un o altre llenguatge.


94

Per últim, la realització d’aquest treball també ens ha aportat conèixer a petita escala com es realitza recerca, en aquest cas relacionada amb la proposta d’un Índex de dificultat propi. Considerem això pel fet que la proposta d’aquest índex ha requerit passar per un conjunt de fases com són documentació, anàlisi, disseny, realització de proves amb un gran nombre de tracks i atributs diferents, estudi dels resultats, tests per part d’experts, etc..


95

9. Línies de futur

Un cop finalitzat aquest Projecte Final de Carrera i tal i com ja s’ha anat comentat al llarg de tot el treball, aquest obre un conjunt de línies de treball en els diferents mòduls que el composen.

Tot seguit es detallaran les línies de treball relacionades amb la gestió dels tracks:

1. A l’actualitat la nostra aplicació només és capaç de parsejar tracks GPX, una important línia de treball podria ser ampliar el nombre de tipus de tracks a parsejar incloent altres tipus de tracks àmpliament usats com el format trk dels dispositius Magellan, el format gdb generat pel software de gestió de tracks dels dispositius Garmin, així com els formats kml i kmz generats per Google Earth.

2. Permetre la descàrrega de tracks de l’aplicació en múltiples formats. D’aquesta forma qualsevol usuari que es volgués descarregar un track ho podria fer amb els formats anteriorment esmentats és a dir GPX, trk, gdb, kml i kmz. Això evitaria que els usuaris haguessin de recórrer a programes de conversió de tracks en el cas que desitgessin obtenir tracks en un format determinat.

3. Permetre la descàrrega avançada de tracks que contemplaria 2 possibles solucions al conegut problema d’alguns receptors GPS que no són capaços de treballar amb tracks de més de 500 punts. Aquestes solucions consistirien en:

a. Permetre la descàrrega de tracks simplificats a un màxim de 500 punts, essent necessari realitzar un estudi previ del track per tal de simplificar el track sense eliminar punts crítics d’aquest.

b. Permetre la descàrrega de múltiples tracks de 500 punts com a màxim. 4. Realitzar una neteja del track per tal de corregir les incoherències que es

puguin trobar en aquest. Tal i com ja s’ha comentat al llarg del treball els GPS són sensibles a patir petites errades en l’obtenció de l’altura i/o del posicionament deguts generalment a problemes de falta de cobertura del receptor GPS. Aquestes errades afecten l’anàlisi del track en general i el càlcul de la distància, el desnivell, la velocitat i el temps en moviment en particular.

5. Permetre la detecció automàtica de l’activitat a la qual correspon un determinat track per tal de poder realitzar correccions específiques d’aquest, lligades amb les limitacions pròpies de l’activitat a la qual correspon. Per exemple, i suposant el cas que estiguéssim analitzant un track generat practicant senderisme es podrien considerar situacions impossibles una velocitat superior als 20 km/h o una velocitat de descens major de 3m/s. Un cop detectades aquelles situacions impossibles lligades amb la realització d’una activitat concreta es podrien aplicar multitud de tècniques relacionades amb la IA que ens permetessin eliminar totes aquelles incoherències que provoquen errors en l’anàlisi del track.


96

Un cop analitzades les línies de treball relacionades amb la gestió de tracks es passarà a analitzar aquelles línies de treball relacionades amb la millor de l’índex de dificultat:

1. Una millora de l’índex actual es troba relacionada amb la possibilitat d’obtenir el tipus de terreny pel qual discorre una determinada ruta. Si es conegués aquesta informació i sempre i quan aquesta fos fiable es podria ponderar molt millor la dificultat d’una ruta ja que aquesta es troba en gran mesura afectada pel tipus de terreny. Aquesta millora però, depèn en gran mesura de la possibilitat d’obtenir aquesta informació d’alguna font fiable. A nivell de Catalunya de l’ICC.

2. Una altra millora de l’índex actual es troba relacionada amb l’ús del camp temps. El temps que es triga en recórrer una determinada distància ens dona una idea de la dificultat d’aquesta, però alhora ens genera dubtes relacionats amb la fiabilitat d’aquesta informació. Es considera això, pel fet que el temps es troba condicionat per la forma física d’una determinada persona, així com pel nombre i durada de les aturades al llarg de la ruta. Per tal de fer ús d’aquesta informació, seria necessari prendre les següents mesures:

a. Escollir diverses rutes de diferents característiques. b. Calcular el temps que tarden persones de diferent forma física. c. Assegurar-nos que els temps d’aturada queden exclosos del còmput

total del temps.

Un cop es poguessin recollir aquestes dades i amb les mesures anteriorment esmentades, seria necessari calcular-ne una mitjana per tal de finalment poder fer ús d’aquesta informació.

Finalment s’analitzaran les millores relacionades amb la implementació del recomanador:

1. Relacionat amb la fase de recuperació del CBR, observem 2 possibles millores d’aquesta:

a. En primer lloc observem una clara necessitat de que un expert o eina assigni uns pesos concrets a cadascun dels atributs per tal de que el procés de recuperació de casos sigui més precís.

b. La segona millora de la fase de recuperació guarda relació amb l’elecció de la millor funció de distància per al nostre problema. Aquesta elecció es realitza a través d’un complex procés consistent en aplicar un conjunt de funcions de distància auto-generades pel sistema sobre un conjunt de dades. Finalment s’escollirà aquella funció que ens permet obtenir el mínim error.

2. Tenint en compte que el CBR que s’ha implementat no disposa d’una fase d’emmagatzematge, observem una clara necessitat d’implementació d’aquesta fase per tal de que es produeixi un aprenentatge del perfil de cada un dels usuaris. Així, el recomanador cada cop podria realitzar recomanacions més acurades a cadascun dels usuaris.

3. Relacionat amb l’aprenentatge del recomanador, una altre línia de treball interessant es trobaria relacionada en realitzar recomanacions amb un objectiu prèviament definit. Així tot usuari podria escollir entre un conjunt d’objectius predefinits, entre els quals es trobaria mantenir el nivell de dificultat durant tot l’any o bé realitzar recomanacions de rutes cada cop més difícils fins arribar a un determinat objectiu de dificultat o de distància.


97

10. Bibliografia

Llibres

PUCH, C (2008). GPS: Aplicaciones prácticas. 3a edició. Ediciones Desnivel. Pàg 144 ISBN: 978-84-9829-147-6

PUCH, C (2007). Manual Completo de GPS. 1a edició. Ediciones Desnivel. Pàg 224 ISBN: 978-84-9829-116-2

PUCH, C (2007). La guía esencial para iniciarse en la navegación terrestre. 1a edició. Ediciones Desnivel. Pàg 60 ISBN: 978-84-9829-108-7

MCNAMARA, J (2008). GPS for Dummies. 2a edicio. Wiley Publishing Inc. Pàg 361. ISBN: 978-0-470-15623-0

HINCH, S (2007). Outdoor Navigation with GPS. 2a edició. Wilderness Press. Pàg 204. ISBN: 978-0-89997-445-3

MITCHELL,T.M.(1997). Machine Learning. 1a edició. Mcgraw-Hill International. Pàg 443 ISBN: 0-07-042807-7

Webs:

DAN FOSTER (07/19/2007) GPX [en línia] The GPS Exchange Format [Consultat: 5 Setembre 2009]. Disponible a internet: http://www.topografix.com/gpx.asp

JORDI L. RAMOT (01/12/2009) Wikiloc [en línia] Wikiloc [Consultat: 15 Juliol 2009]. Disponible a internet: http://www.wikiloc.com

GOOGLE INC. (01/01/2010) Google [en línia] API de Google Maps [Consultat: 30 Setembre 2009]. Disponible a internet: http://code.google.com/intl/es-ES/apis/maps/

OLE LAURSEN (23/10/2009) Google Code [en línia] Flot [Consultat: 15 Octubre 2009]. Disponible a internet: http://code.google.com/p/flot/

GOOGLE INC. (01/04/2009) Google Code [en línia] Using PHP/MySQL with Google Maps [Consultat: 30 Setembre 2009]. Disponible a internet: http://code.google.com/intl/es-ES/apis/maps/articles/phpsqlajax.html

ANDER GUAZA (25/12/2009) Altimetrias.com [en línia] Calculo de la pendiente de una carretera [Consultat: 30 Octubre 2009]. Disponible a internet: http://www.altimetrias.net/articulos/4ComoPendiente.asp

ANTONIO RODRÍGUEZ (17/02/2009) El GPS [en línia] Como funciona el sistema GPS, en cinco pasos lógicos [Consultat: 1 Desembre 2009]. Disponible a internet: http://www.elgps.com/documentos/comofuncionagps/comofuncionagps.html


98

Tesis i Projectes:

FORNELLS, A. (2007). Marc integrador de les capacitats de Soft-Computing i de Knowledge Discovery dels Mapes Autoorganitzatius en el Raonament Basat en Casos (Elisabet Golobardes i Ribé). Tesi doctoral. Arquitectura i Enginyeria La Salle, Barcelona.

Sancho, A. (2008). Estudi i disseny de mecanismes de ponderacio d'atributs aplicats en el Raonament Basat en Casos (David Vernet Bellet). Treball final de carrera. Arquitectura i Enginyeria La Salle, Barcelona.


99

Annex

1. Enquesta sobre la qualitat de l’Índex


09 Marxassa

37ª Viladrau

La Garriga

Trav. Montseny

09

Marxa dels

castells 09

Marxa del

Garraf 08

Distància 78,15 62,63 29,06 47,26 50,81 45,86

Des pos. 2.876 1.792 1.050 3.447 1.233 1.608

Des neg. 3.265 2.318 1.411 3.715 1.198 1.647

Índex Dificultat 185 145 72 139 123 109

D'acord? (Si/No) Per què no?

Carros de foc NQ 09 UTSM 09 CCC 09 TDS 09 UTMB 09

Distància 61,91 99,71 101,55 99,24 106,03 166,77

Des pos. 3.998 7.311 4.493 6.869 6.906 11.321

Des neg. 4.026 8.325 4.477 7.056 6.752 11.324

Dif Senderators 199 309 248 310 342 514

D'acord? (Si/No) Per què no?

Taula 15. Enquesta qualitat de l’índex proposat

memo pfc defusers.salleurl.edu/~xavier.canaleta/memories/albertvelasco_pfc.pdf · figura 10....

Documents