Entrades classificades amb: Anàlisi Urbà

ZI-Graf de Trams de Carrer: Anem en la bona direcció

 

Un dels elements diferencials en els aplicatius del CCU, que anomenem ‘mòduls’, és la importància que hi donem al Graf de Trams de Carrer (GTC). Ja abans quan estàvem treballant en l’entorn del GeomediaPro i amb la llibreria del Geomedia Transportation Manager, com avui dia en que treballem amb l’entorn del QGIS.

Fig 1. Desplegament en arbre seguint el GTC. GeomediaPro.

Aquest fet, el treball amb el GTC, s’ha traduït amb la definició de zones d’influència a par-tir del GTC desplegat en arbre a partir d’un punt determinat (vegeu la figura 1) , també anomenat ‘cobertura’ en altres entrades en aquest Bloc, i en la cerca de camins (més curts o més ràpids) a un nombre determinat d’entitats seguint el GTC.

Aquest tipus de zones d’influència graf (ZI-GTC) en les versions del QGIS anteriors a la versió 3 es feia en el servidor PostgreSQL a través de la llibreria ‘pgrouting’, i per definir la ‘cobertura’ a partir d’un punt es va haver de desenvolupar un procediment específic ja que directament en la llibreria no estava implementat. Això està explicat en detall en l’entrada a aquest bloc anomenada: ‘Cobertura mitjançant graf de trams de carrers (GTC)’ publicat per en Josep Lòpez Xarbau el dia 1/06/2017. Vegeu a la figura 2 una mostra del resultat final de la cobertura a partir d’un punt.

Fig 2. Cobertura a partir d’un punt implementat sobre ‘pgrouting’ per en Josep L. Xarbau

Tan en la figura 1 com en la figura 2 es important destacar que un cop assolida la distancia màxima o la funció de cost màxima ens podem trobar en un punt intermig d’un dels seg-ments del GTC, el càlcul d’aquests darrers fragments perifèrics de tram comporta un càlcul especial, com s’explica en el ‘post’ d’en Josep L.Xarbau.

A partir de la versió 3 del QGIS ens trobem que moltes d’aquestes funcions relacionades amb el GTC, com pot ser l’’encaminament’ o cerca d’un trajecte entre punts del mapa i la ‘cobertura’ o desplegament en arbre a partir d’un punt seguint el GTC, estan ja imple-mentades. Desplegant el menú ‘Procesos’->’Caja de herramientas de Procesos’ tal com es pot veure en la figura 3

Fig 3. Eines d’Anàlisi de Xarxes del QGIS v3

En aquest cas la ‘cobertura’ l’anomenen ‘Àrea de Servei’. La implementació de aquestes funcions en els mòduls del CCU, concretament en el mòdul CTE està descrita en l’entrada: ‘Implementación de las funcionalidades QGIS3 para realizar el cálculo local en el módulo CTE’ d’en Manuel Duro.

Val a dir que un cop obtingut el desplegament en arbre a partir d’un punt s’ha de definir un ‘buffer’ a l’entorn d’aquesta entitat lineal i això constituirà la nova zona d’influència d’aquest punt seguint el GTC.

Plantejat tot això diem que anem en la bona direcció per que l’evolució de les eines del QGIS sembla indicar-ho així, dotant al seu aplicatiu d’uns recursos analítics que en versions anteriors no hi eren i que entre altres àmbits impliquen a tot el que te a veure amb el GTC, és a dir l’encaminament i la ZI-GTC. El projecte CCU sempre ha apostat per aquests plantejaments i ha treballat en la generació de mòduls relacionats amb el GTC, ara l’evolució de la tecnologia encara reforça mes aquest enfocament.

De totes maneres l’avantatge o inconvenient de realitzar els càlculs dels camins o les ZI seguint el GTC en el propi equip o fer-ho en el servidor PostgreSQL requereix un estudi de mes profunditat. El que sí està clar és que la flexibilitat en poder escollir un procediment o un altre reverteix en benefici de l’usuari, que podrà aprofitar ambdós mètodes per treure’n més rendiment al seu equip.

Desenvolupament d’un mòdul en un entorn web

En aquest post s’exposen les diferents etapes de construcció d’una aplicació web que permet fer les mateixes funcions que el mòdul ‘Cerca de Trajectes a Entitats’ per a QGIS. Tot i aquest fet, el canvi de plataforma ha suposat un gran repte ja que fins al moment no s’ha realitzat cap tasca semblant, i per tant s’ha hagut de començar tot de zero.

Aquesta idea es va aportar des del Servei d’Estratègia i Avaluació de l’Ajuntament de Mataró, més concretament pel cap del servei, el senyor Jordi Arderiu. Donades les característiques client-servidor de l’enfocament del projecte de mòduls del CCU per a QGIS, on una part important del codi dels càlculs del procediments s’executa en el servidor de Postgres, semblava a priori factible passar de l’entorn QGIS a un entorn web, mantenint el nucli de càlcul igualment en el servei. El que s’havia de resoldre era quin tipus de servei calia crear per poder establir la comunicació entre l’entorn web i el servidor.

Aconseguir un prototip funcional obre la porta a una nova migració dels mòduls en entorn QGIS a mòduls en entorn web, com el Visor GIS 3.0 del propi Ajuntament de Mataró. Això facilita molt la divulgació del projecte cap a un usuari no tècnic, a través del web, i com a conseqüència la propagació cap altres ens públics o privats que utilitzen la mateixa tecnologia de base de dades. Això va generar molt d’interès per part del Servei d’Estratègia i Avaluació.

Actualment, el CCU proporciona serveis WMS (Web Map Service) i WFS (Web Feature Service) a l’Ajuntament de Mataró mitjançant el QGIS server. Aquesta aplicació pròpia de l’entorn QGIS permet la publicació de capes fàcilment. En aquest cas, les capes publicades són una taula amb tots els camins dels portals a les tres Escoles Bressol i Llars d’Infants més properes (WMS), i les Zones d’Influència i Població Exclosa de diferents activitats econòmiques (WFS).

L’equip del CCU va decidir apostar pel mòdul CTE, ja que els càlculs que es realitzen són suficientment complexes per realitzar un bon prototip i avaluar metodologies i procediments però és prou simple com per poder tirar-lo endavant dins de l’àmbit del present projecte. A més, s’obriria al camí a la substitució de la publicació dels camins més propers (WMS) per un mòdul capaç de fer el càlcul directe i mostrar els camins a diferents entitats i en un rang de un a deu camins.

1.1 Planificació de l’aplicació

La planificació d’aquesta aplicació web es va decidir per l’equip del CCU. Es va acordar que es farien diferents proves de concepte per tal de comprovar que els diferents objectius eren factibles, ja que com s’ha mencionat prèviament, no hi havia precedent.

L’equip del CCU es va reunir amb els membres del Servei de Sistemes d’Informació i Telecomunicacions de l’Ajuntament de Mataró per parlar entre d’altres temes de l’aplicació web i amb vistes d’una futura integració dels procediments utilitzats dins del seu Visor GIS 3.0, i facilitar-ne la posterior integració.

Allà es va proposar la construcció d’un servei REST que fos capaç de processar les peticions necessàries i oferir els resultats en el menor temps possible. Juntament amb això, es va parlar de la llibreria ‘Leaflet’, per Javascript que permet interactuar amb mapes i permet operar amb un gran ventall de possibilitats. Des del SIT es va facilitar una plantilla d’una pàgina web que incorpora funcionalitats d’aquesta per poder testejar-la.

Un servei REST (Representational State Transfer en són les sigles en anglès) és un estil d’arquitectura de programari que defineix un conjunt de restriccions i propietats, i que està basat en un entorn web. Aquest servei web ofereix la possibilitat d’interactuar tant entre client i servidor com entre servidors, i pot treballar amb diferents formats de peticions i resposta com ara XML, JSON o HTML.

També pot utilitzar els principals mètodes HTTP (GET, POST, PUT i DELETE) explícitament. Un dels principals avantatges és que no requereix un estat previ per poder respondre a les peticions i/o rebre-les. A més, permet transmetre grans quantitats de dades i paràmetres sense afectar el rendiment del servei.

Es van sondejar diferents alternatives menys complexes, com ara un servei web PHP. Aquest servei permet fer peticions i rebre respostes en diferents formats, i presenta facilitats a l’hora de crear el servei ja que només cal disposar d’un fitxer on hi hagi les diferents instruccions. A més, a l’utilitzar un llenguatge interpretat, només cal disposar de l’interpretador del llenguatge en el servidor. No són necessàries configuracions extres. Per últim, les capacitats del llenguatge són molt àmplies i fàcilment es poden ampliar el nombre de funcionalitats que aquest ofereix.

L’equip del CCU va concloure que l’opció més adequada per a realitzar la tasca és la utilització d’un servei PHP. Es va decidir fer-ho d’aquesta manera degut a les facilitats que aporta a l’hora de fer les proves de concepte i versatilitat del llenguatge davant la introducció de nous canvis en el servei. A més, aquests tenen efecte immediat en el resultat.

Una vegada es va reunir prou informació, valorades totes les possibilitats i preses totes les decisions es va començar a treballar a partir de la plantilla enviada per en Jordi Beltran i es va a començar a preparar l’estructura de l’aplicació per realitzar la primera prova de concepte. Aquesta va consistir en fer aparèixer per pantalla una capa de dades. Aquesta pot estar formada tant per punts, línies com polígons.

1.2 Primera prova de concepte: presentació de dades

Aquesta prova de concepte va presentar la seva dificultat no en el què s’ha de fer sinó en el com. A nivell conceptual, només s’ha de  representar les dades en el mapa. Però això es va dur a terme mitjançant un suport del qual no es disposava d’experiència prèvia i al principi, sobretot a la part del front-end es presentaven els problemes. El principal entrebanc va ser el tractament de les dades i la utilització de diferents sistemes de referència: la llibreria ‘leaflet’ treballa amb la longitud i latitud terrestres per situar elements en el mapa. En canvi, el sistema de referència de les capes emmagatzemades a la base de dades PostgreSQL és SRID 25831. Això requereix una transformació de les dades de posició cada vegada que es vol presentar quelcom per pantalla.

També s’han de tractar i transformar dades en una codificació determinada per a poder ser enviades i rebudes. En el diagrama de la figura 1.1 es pot veure el flux d’interacció d’informació entre màquines:

Fig. 1.1: Diagrama de flux de la transmissió d’informació (Font: l’autor)

En primer lloc, es processa l’esdeveniment, és a dir el clic a pantalla de l’usuari fent la petició. Seguidament es processa la informació que l’usuari ha introduït mitjançant el Javascript en el format correcte per tal que aquestes puguin ser interpretades correctament pel servei. En aquest cas, el nom de la capa que es volia mostrar i el número màxim d’entitats que es volien mostrar.

Una vegada la informació ha estat processada i afegida a la petició, aquesta és realitzada al servidor web a través del motor de peticions AJAX, aportat per la llibreria de JS anomenada jQuery. El format de la petició seria el de la figura 1.2:

$.ajax({    url: ‘fitxer.php’, //nom del fitxer d’on volem obtenir resposta    type: “GET”, //tipus de petició    data: {       CAPA: capa       //paràmetres que es passen     },     dataType: ‘json’ //format del resultat que volem }).done(function(msg) {       //msg és el resultat obtingut i en aquesta part es preparen les       //per ser presentades    } })

Fig. 1.2: Petició d’AJAX al servidor

En segon lloc, el servidor web rep la petició i la processa mitjançant l’interpretador de PHP i el fitxer amb les instruccions en aquest llenguatge. Aquest crea una connexió amb la base de dades on es fan les peticions necessàries. En aquest cas és una simple consulta de les dades d’una capa. En el fitxer PHP es crea la consulta SQL i s’envia a la base de dades. Aquesta retorna el resultat, i posteriorment es codifica en format GeoJSON, que és un derivat del JSON. Després es transmet mitjançant la sentència “echo $resultat;” al front-end.

Per últim, només es mostren les dades per pantalla mitjançant la llibreria ‘Leaflet’, que se li passa per paràmetres.

Es va preparar una pàgina simple i bastant rudimentària per a presentar les dades: a la part superior hi figurava un petit formulari on s’hi intruïa les dades necessàries (nom de la taula, límit d’elements a mostrar i nom del camp de geometria) i just a sota hi havia un botó per realitzar la petició. La resta d’espai era ocupat pel mapa, tal i com es pot veure en la figura 1.3.

Fig. 1.3: Captura de pantalla de la pàgina web (Font: l’autor)

Per últim, es va afegir una funcionalitat extra. Aquesta consistia en què quan l’usuari feia una petició, s’esborrés la capa de dades que s’estigués mostrant en el moment i només hi aparegués la capa sol·licitada.

Aquesta prova va resultar tot un èxit ja que es van complir plenament els objectius marcats en l’inici, a pesar de les dificultats passades degut a l’adaptació a un nou entorn de treball. Es va poder comprovar que les eines emprades tenien molt de potencial i era possible arribar a bon port en la realització d’aquesta tasca.

1.3 Segona prova de concepte: consulta d’un ruta

La segona prova de concepte va consistir en realitzar una consulta ja més complexa: afegir més paràmetres a passar i obtenir el camí entre dos punts en el GTC. En aquest cas, va augmentar el nombre de paràmetres a passar respecte la prova anterior. Abans només es passava el nom de la capa de dades, i en canvi ara necessitem el nom de la cap del GTC i el seu nom del camp de geometria, i els punt d’inici i final, que corresponia a dos nombres enters. Els punts d’inici i final corresponent a dos vèrtex del GTC. També hi figuren dos camps de text on s’hi mostra la longitud i latitud del punt marcat en el mapa, tal i com es pot veure en la figura 1.4.

Fig. 1.4: Captura de pantalla de la pàgina web (Font: l’autor)

En la part de servidor, la novetat venia per la cerca del camí més curt entre dos punts. Per tal d’aconseguir-ho es va utilitzar la funció “pgr_dijkstra”. En aquest cas, només són necessaris tres paràmetres: capa de segments, punt d’inici i punt de destí. Cal dir que els punts pertanyen a la capa de segments.

En aquest cas, la resposta és una seqüència de segments consecutius que uneixen els dos punts i el cost agregat de tot el trajecte. Cal remarcar que la solució no aporta geometria i posteriorment aquesta s’ha de relacionar amb el GTC per obtenir una resposta completa. A la figura 1.5 hi ha un exemple de consulta i els camps que retorna aquesta.

Consulta: pgr_dijkstra(edges_sql, start_vid,  end_vid) Resposta: (seq, path_seq, node, edge, cost, agg_cost)

Fig. 1.5: Consulta i resposta de la funció ‘pgr_dijkstra’ (Font: [38])

Una vegada s’ha realitzat aquesta relació, s’ha de transformar el resultat a GeoJSON per tal que el front-end ho pugui interpretar de manera correcta mostrar-ho a l’usuari. En aquest cas, la sentència que s’utilitza per tal de trobar el resultat és el que es mostra a la figura 1.6:

select st_asgeojson(st_asewkt(st_transform(the_geom,4326))) AS geojson from “SegmentsXarxaCarrers” where id in(SELECT edge FROM pgr_dijkstra(‘SELECT id, source, target, cost, reverse_cost FROM “SegmentsXarxaCarrers”‘,ARRAY[45],ARRAY[52],FALSE))

Fig. 1.6: Sentència SQL per cercar el camí més curt (Font: l’autor)

En aquesta ocasió s’utilitza una consulta amb una consulta niuada. La consulta niuada és a on s’usa la funció de cerca de camí més òptim, completada amb les dades necessàries. El resultat d’aquesta consulta, més concretament l’identificador dels trams per on passa la ruta més ràpida, s’empra per relacionar-ho amb la capa dels segments, ja que aquesta disposa de la geometria de cada un d’ells, i per tant només cal transformar les coordenades per tal que puguin ser representades correctament per pantalla, amb l’ajuda de la funció ‘st_asgeojson’.

El temps de resposta és realment ràpid. El rang de temps de resposta és de l’ordre de 0,4 segons a un segon, depenent de si els punts estan més o menys a prop un de l’altre. En comparació amb altres mòduls en entorn QGIS que s’han anat desenvolupant al llarg del temps la principal diferencia és mostra a l’hora de representar el resultat per pantalla. A l’aplicació web, la representació és pràcticament instantània. En canvi, tot i que la resposta també és molt ràpida, en el QGIS aquesta pot durar un o dos segons més que en l’entorn web, en funció del nombre de capes a representar.

Una altra funcionalitat que es a va afegir en aquesta prova va ser la addició del punter, tal i com es mostra a la figura 1.4. El punter és una eina gràfica que quan l’usuari prem un punt del mapa amb el ratolí, hi aparegui una marca. Una vegada s’ha afegit, calia capturar-ne les coordenades geogràfiques (latitud i longitud) per a poder comprovar que una vegada obtingudes es pot generar un punt d’origen.

Com l’anterior, aquesta prova va ser un èxit ja que es van aconseguir els objectius fixats: millora del coneixement a l’hora de tractar amb paràmetres i transmetre’ls correctament al servidor, realització d’una consulta més complexa: cerca d’un camí entre dos punts i finalment la captura de les coordenades de pantalla.

1.4 Construcció de l’aplicació web

Una vegada fetes aquestes dues proves de concepte i haver comprovat que la tasca era viable, es va  procedir a la construcció del mòdul. Aquest projecte tenia dues parts diferenciades: front-end i back-end.

Tot i que ambdues parts s’anaven desenvolupant al mateix temps, es va optar per donar més èmfasi a la part del servidor en primer lloc, ja que era la més ràpida d’implementar. Això es va deure a que es podien reaprofitar moltes de les sentències SQL que es van utilitzar en el mòdul per a QGIS. No obstant a això, va ser necessari reescriure el codi en un altre llenguatge, en PHP concretament, i del qual es tenien coneixements bàsics de la sintaxis. Per aquest motiu en alguns moments es va fer feixuc el canvi, ja que en ocasions la sintaxis era força diferent a la vista fins al moment en altres llenguatges.

En paral·lel també es treballa sobre la part de Javascript, que es dedica a gestionar la informació enviada i rebuda. En aquest cas, les principals dificultats es van presentar a l’hora de rebre i transformar correctament les dades a GeoJSON. També a l’hora de tractar múltiples respostes a una crida, ja que estaven emmagatzemades en una cadena de caràcters i resultava confús en un principi com calia separar-les. Per resoldre-ho va ser necessari des del servidor aportar les dades en un vector on a cada posició hi figura cada una de les diferents capes a mostrar. Cada capa té una estructura GeoJSON i és processada per la llibreria ‘Leaflet’ que la mostra en el navegador.

La primera fase de construcció de l’aplicació va consistir en la preparació d’una plana web bàsica i sense estils amb un formulari capaç d’enviar peticions a la banda del servidor, on el punt d’origen s’estableix a través d’un punt marcat en el mapa per l’usuari. Una vegada es passen totes les dades correctament, el servidor ha de poder retornar els N-camins més òptims i, posteriorment, aquest han de presentar per pantalla.

Una vegada es va passar aquest punt crucial i es va comprovar que el resultat era l’esperat, la resta de tasques van consistir sobretot en afegir més funcionalitats i optimitzar el codi, i fer un aplicació estable, és a dir, sense errors.

En la part de front-end i a nivell estètic, es va afegir un formulari que fos intuïtiu i amigable de cara a l’usuari final, que els diferents camps es mostressin o no en funció de quina opció escull l’usuari. També es va escollir una gamma de colors, fonts i estils que fessin més fàcil la visualització de les dades a entrar i de la taula de resultats. A més, es va afegir la possibilitat de desplegar lateralment el menú on hi figura el formulari per tal de facilitar la visualització del mapa quan l’usuari ho requereixi. A la figura 1.7 es mostra l’aparença del formulari.

Fig. 1.7: Captura de pantalla de l’aparença del formulari (Font: l’autor)

A nivell funcional, es van completar totes les opcions de cerca de les que disposa el mòdul CTE per a QGIS, incloent la funcionalitat més significativa, que és la possibilitat de cercar el punt d’origen a partir de l’adreça d’un portal. Això facilita substancialment aquesta tasca i l’aplicació s’acosta a la funcionalitat original del mòdul CTE per a QGIS. Per últim, cal destacar que la interfície es va construir de manera que fos ‘responsive’, és a dir que s’adapti a les diferents mides i resolucions de pantalla per tal que des de qualsevol dispositiu es pugui utilitzar l’aplicació.

A part del formulari, l’aparença dels diferents resultats també es va cuidar per tal que fos el més semblant possible a la que es mostra en el mòdul CTE per a QGIS i sigui fàcil d’interpretar per a l’usuari.

En primer lloc, els N-camins òptims segueixen el mateix patró d’estil que en el mòdul original, és a dir, l’escala de colors va del verd al vermell, on el verd és el camí més proper i el vermell és el més allunyat. També el gruix varia en funció de la proximitat al destí: el primer camí és el de major gruix, en canvi, el de menor gruix és el més allunyat. A la figura 1.8 es pot veure un exemple del cas:

Fig. 1.8: Captura de pantalla dels estils dels camins (Font: l’autor)

En segon lloc, l’etiqueta de destí està formada per un punter de color vermell amb un cercle central on hi figura el número de posició en el que es troba el destí en la taula final, com es pot veure en la figura 1.9 o en els extrems dels camins de la figura 1.8:

Fig. 1.9: Captura de pantalla de l’estil del punts de destí. (Font: l’autor)

Per últim, l’etiqueta que indica l’origen està formada per un punter de color blau amb un petit cercle en el centre, tal i com es pot apreciar a la figura 1.10.

Fig. 1.10: Captura de pantalla de l’estil del  punt d’origen (Font: l’autor)

Degut a les millores que s’han afegit a la interfície, va ser necessari donar suport des del servidor a les diferents funcionalitats afegides. Va ser necessari crear una funció que retornés una llista amb tots els noms dels carrers i els seus respectius codis per tal de llistar-los i que l’usuari pugui escollir el que més li interessi. Una vegada ha escollit el que li interessa, s’activa una funció que comprova que l’adreça afegida per l’usuari existeix, o en cas que no, quina és l’adreça més propera. Una vegada ha estat validada, es crea un codi de portal i s’afegeix un punter automàticament en el mapa.

L’última millora afegida va ser la possibilitat de poder escollir la base del mapa sobre el qual es vol treballar. Hi ha dues opcions: mapa de carrers o imatge de satèl·lit. Per poder canviar de opció, cal dirigir-se a l’escaire superior dret on s’hi pot trobar una icona com la de la figura 1.11 i si es pitja, es poden veure les dues opcions, com a la figura 1.12.

Fig. 1.11: Captura de pantalla de l’aparença de la icona (Font: l’autor)

Fig. 1.12: Captura de pantalla de la icona de capes desplegada (Font: l’autor)

1.5 Publicació

Actualment l’aplicació és visible a Internet. Per poder accedir-hi només cal adreçar-se a http://geoportalccu.tecnocampus.cat/cte.html en el navegador d’Internet, preferiblement, el Google Chrome.

Manual d’ús de l’usuari: Mapes descriptius de població

Aquest document explica el funcionament del plugin de ‘Mapes descriptius de població’ per a QGIS.  Per a poder utilitzar-lo, el primer que s’ha de fer és executar el programa QGIS i un cop inicialitzat aquest, cal pitjar la icona següent 101o anar a Complementos -> CCU -> Mapes descriptius de població i s’obrirà una finestra com la que podem veure a continuació a la figura 1, que és molt semblant a la interfície del plugin de la Taula Resum amb algunes diferències descrites en els apartats 1 i 4.
1054 quines capes volem treballar: illes, parcel·les, seccions, barris o districtes postals.

103

Fig 2. Mètode de treball

  1. A la part superior central, hi ha una pestanya desplegable amb les connexions disponibles (ja configurades prèviament) per a realitzar les operacions. Allà n’escollim una i seguidament la barra que hi ha just a sota n’indicarà l’estat.

104

Fig 3. Connexió i progrés

  1. A la zona lateral dreta hi podem trobar el selector de filtres que volem utilitzar per crear la consulta. Només cal pitjar el filtre que vulguem aplicar per poder-lo emprar. Just a sota hi trobem dos botons més: INICI i SORTIR. ‘Inici’ arrenca el procés de representació del mapa i en el cas que hi hagi algun error en la configuració dels paràmetres per a la construcció d’aquestes, el procés s’interromp i ens apareix un missatge amb l’error. I el botó sortir, tanca el plugin.

105

Fig 4. Opcions i ordres principals

  1. Finalment, a la part central, tenim requadre amb dos pestanyes amb les opcions: configuració de la capa de sortida i els filtres.

106
Fig 5. Pestanyes

Per una banda, a la pestanya de ‘Filtres’ podem trobar-hi un requadre amb cinc pestanyes per poder configurar els paràmetres de cada  filtre. Recordem que el filtre es defineix en aquesta pestanya però s’activa pel botó lateral de la figura 4. , s’han de fer les dues coses.

Seguidament els detallarem:

  • El primer que apareix és l’edat. En aquesta pestanya s’ha d’introduir en primer lloc una data segons la qual es vulgui fer l’estudi, per exemple 1 de maig de 2016. Després hem de posar el marge d’edat que volem definir en els camps edat mínima i edat màxima. Si volem fer una taula per les escoles bressol, cal posar 0 i 2 anys en els dos camps respectivament. Seleccionant la opció criteri restrictiu cercarem els nens que encara no hagin fet els 2 anys. En canvi seleccionant el criteri no restrictiu cercarem tots els nens que encara no han fet els tres anys.

107
Fig 6. Filtre per edat

  • El segon criteri que apareix és el gènere. Podem decidir que la nostra cerca sigui en funció d’homes o de dones.

108
Fig 7. Génere

  • A continuació tenim els estudis: podem fer un filtratge segons els estudis que la persona hagi declarat tenir en el padró.

109
Fig 8. Estudis

  • Un altre punt molt important seria l’origen no confondre amb nacionalitat.

Una cosa és el país d’origen, és a dir, on ha nascut la persona en qüestió i l’altre la nacionalitat. La segona és quelcom més complex d’explicar, ja que està subjecte als conceptes de “ius sanguini” i “ius soli”. En el primer cas, quelcom comú als països europeus, africans i la Xina, els nen/a tenen automàtica la nacionalitat d’origen dels pares. Això comporta, per exemple, que un nen/a nascuda de pares marroquins a Mataró tingui nacionalitat marroquina. En el segon cas, si neixes en un país de dret de “ius soli”, obtens la automàticament la nacionalitat del país on neixes. Aquesta és la situació de la majoria de països llatinoamericans.

Llavors, en aquesta finestra podem filtrar la nostre cerca segons diferents criteris:

  1. Pel país d’origen
  2. Per la zona del país d’origen
  3. Per que el seu país d’origen pertanyi a la unió europea.

110

Fig 9. Origen

  • Per últim la nacionalitat, que té els mateixos criteris de filtratge que en l’apartat anterior.

111

Fig 10 . Nacionalitat

Per altra banda, a la pestanya de ‘Configuració de la sortida’ hi trobem diferents opcions per a la visualització dels resultats obtinguts.

112

Fig 11. Configuració de la sortida

Seguidament s’explicaran detalladament de què consta cada element:

  1. En primer lloc escollim la opció amb la qual volem que es faci el càlcul. Podem escollir entre tres opcions:
    • Habitants absoluts: retorna el número absolut dels habitants afectats pel filtre que hem escollit.
    • Habitants relatius: retorna el percentatge d’habitants afectats pel filtre entre el número total de persones que viuen en l’entitat que hem escollit per fer la cerca.
    • Densitat: retorna la densitat de població que està afectada pel filtre en Habitants/km2.
  1. En segon lloc escollim entre dues opcions pel color de la capa de sortida: un color únic per a tota la capa on en podem en podem regular la transparència, o bé un degradat de colors per indicar el major o menor nombre de persones afectades, on podem escollir-ne el número de intervals i el mode del temàtic que vol dir la forma en que es defineix cada rang, igual nombre de incidències , igual amplada de l’interval etc.
  1. En tercer i últim lloc tenim la possibilitat d’afegir etiquetes i modificar-ne algunes de les seves propietats com ara la mida i el color de la lletra i també la visualització en escala. Els valors de l’escala de visualització tenen un valor per defecte per a cada tipus d’entitat, però es poden modificar sense cap mena de problema.

Una vegada aplicats els filtres a la cerca per qualsevol dels criteris explicats anteriorment i configurats els paràmetres de sortida, només cal pitjar el botó “INICI”.

 

Manual d’ús del mòdul ‘Zones d’influència adaptatives’

Aquest document explica el funcionament del plugin de ‘Zones d’influència adaptatives’ per a QGIS.  Per a poder utilitzar-lo, el primer que s’ha de fer és executar el programa QGIS i un cop inicialitzat aquest, cal pitjar la icona següent1

o anar a Complements -> CCU -> Zones d’influència adaptatives i s’obrirà una finestra com la que podem veure a continuació a la imatge.

2

Aquest mòdul el que fa és ajustar la zona d’influència de cada entitat proveïdora d’un servei a la població a la capacitat de cada centre (que s’ha de fixar en la BD prèviament), tenint en compte la densitat de la problació ‘target’ del seu entorn. Aquesta zona d’influència pot ser circular o seguint el Graf de Trams de Carrer.

A continuació es detallaran els diferents components del plugin i quina és la seva funció:

  1. A la part superior, hi ha un barra on s’hi indica l’estat de la connexió i una pestanya desplegable amb les connexions disponibles (ja configurades prèviament) per a realitzar les operacions. Allà n’escollim una.3
  2. En aquesta part escollirem la capa de punts a partir de la qual volem fer la zona d’influència i el color que tindrà.4
  3. Just a sota trobarem tres botons que ens permetran escollir la capa sobre la que volem treballar: Illes, parcel·les o portals.5
  4. En aquesta secció cal introduir un número de iteracions que volem que es realitzin.6
    Hem de tenir present que el programa fa el recalcul del següent radi (o distància) a partir del nombre de persones trobades prèviament dins de la zona i això ho pot fer una vegada (cas de una iteració) o unes quantes, poguent anar refinant l’ajust, però amb augment del temps de càlcul.
  1. En l’apartat de cobertura caldrà dir el percentatge de població sobre el qual volem fer l’estudi. També marcarem el checkBox en el cas que vulguem que es mostri la població no afectada per la zona d’influència. Una vegada realitzada la operació, ens apareixerà el nombre d’habitants no coberts en el requadre blanc, a la part inferior.7
  2. Aquí cal introduir el radi inicial a partir del qual treballarem amb les entitats puntuals. Es una radi inicial mitjà a partir del qual i segons la capacitat de cada centre s’assigna el radi inicial particular de cada un.8
  3. En aquest apartat es pot escollir zones d’influència de graf si se selecciona l’opció ‘fer servir trams’. En cas contrari, les zones d’influència són circulars. En cas de fer servir trams, podem fer que es vegi el dibuix del graf marcan el checkBox corresponent. També es pot modificar el radi de la zona d’influència canviant el valor en el textBox.9
  4. En el cas que la opció de ‘fer servir trams’ estigui habilitada, cal escollir un graf sobre la qual treballar, mitjançant la pestanya desplegable. També podem escollir el color de l’àrea d’influència i modificar el traç amb la pestanya desplegable inferior.10
  5. En últim lloc, a la part inferior de la finestra podem trobar la versió de la plugin amb la que estem treballant i dos botons: ‘INICI’ per començar el processament de les dades i ‘SORTIR’ per tancar el plugin.11

 

Manual d’ús del mòdul ‘TaulaResum’

Aquest document explica el funcionament del plugin de ‘Taula Resum’ per a QGIS.  Per a poder utilitzar-lo, el primer que s’ha de fer és executar el programa QGIS i un cop inicialitzat aquest, cal pitjar la icona de la figura 1 o anar a Complementos -> CCU -> Taula Resum i s’obrirà una finestra com la que podem veure a la figura 2.

icona figura 1

inici figura 2

A continuació es detallaran els diferents components del plugin i quina és la seva funció:

  1. A la part superior esquerra, hi ha un rectangle on hi indicarem sobre quines capes volem treballar: illes, parcel·les, portals o totes tres alhora.met-treb
  2. A la part superior central, hi ha una pestanya desplegable amb les connexions disponibles (ja configurades prèviament) per a realitzar les operacions. Allà n’escollim una i seguidament la barra que hi ha just a sota n’indicarà l’estat.connexio
  3. A la zona lateral dreta hi podem trobar el selector de filtres que volem utilitzar per crear les taules. Només cal pitjar el filtre que vulguem aplicar per poder-lo emprar. Just a sota hi trobem dos botons més: crear taula i sortir. Crear taula inicia el procés de creació de taules i en el cas que hi hagi algun error en la configuració dels paràmetres per a la construcció d’aquestes, el procés s’interromp i ens apareix un missatge amb l’error. I el botó sortir, tanca el plugin.filtres
  4. Finalment, a la part central, tenim requadre amb cinc pestanyes amb les opcions per poder configurar els paràmetres de cada filtre. Seguidament els detallarem:
    • El primer que apareix és l’edat. En aquesta pestanya s’ha d’introduir en primer lloc una data segons la qual es vulgui fer l’estudi, per exemple 1 de maig de 2016. Després hem de posar el marge d’edat que volem definir en els camps edat mínima i edat màxima. Si volem fer una taula per les escoles bressol, cal posar 0 i 2 anys en els dos camps respectivament. Seleccionant la opció criteri restrictiu cercarem els nens que encara no hagin fet els 2 anys. En canvi seleccionant el criteri no restrictiu cercarem tots els nens que encara no han fet els tres anys.

pest

    • El segon criteri que apareix és el gènere. Podem decidir que la nostra cerca sigui en funció d’homes o de dones.

pest2

    • A continuació tenim els estudis: podem fer un filtratge segons els estudis que la persona hagi declarat tenir en el padró.

pest3

  • Un altre punt molt important seria l’origen no confondre amb nacionalitat. Una cosa és el país d’origen, és a dir, on ha nascut la persona en qüestió i l’altre la nacionalitat. La segona és quelcom més complex d’explicar, ja que està subjecte als conceptes de “ius sanguini” i “ius soli”. En el primer cas, quelcom comú als països europeus, africans i la Xina, els nen/a tenen automàtica la nacionalitat d’origen dels pares. Això comporta, per exemple, que un nen/a nascuda de pares marroquins a Mataró tingui nacionalitat marroquina. En el segon cas, si neixes en un país de dret de “ius soli”, obtens la automàticament la nacionalitat del país on neixes. Aquesta és la situació de la majoria de països llatinoamericans. Llavors, en aquesta finestra podem filtrar la nostre cerca segons diferents criteris:
    1. Pel país d’origen
    2. Per la zona del país d’origen
    3. Per que el seu país d’origen pertanyi a la unió europea.

pest4

    • Per últim la nacionalitat, que té els mateixos criteris de filtratge que en l’apartat anterior.

pest5

Una vegada aplicats els filtres a la cerca per qualsevol dels criteris explicats anteriorment, ja podem crear la teva taula resum, seleccionant tots els botons dels filtres sobre els quals volem fer la cerca i posteriorment pitjant al botó “crear taula”.

Creació del plugin ‘Taula Resum’

Introducció

En aquest post es podrà llegir els passos que cal seguir per a construir el plugin ‘Taula Resum’ per a QGIS.

En el plugin ‘TaulaResum’ cal destacar el canvi de filosofia que s’ha produït amb el canvi de GeoMedia, el qual treballa amb bases de dades locals, al QGIS. En canvi amb aquest últim hem passat a treballar amb un topologia client-servidor, que permet que tots els usuaris que disposin de les credencials podran accedir a les bases de dades sempre que vulguin i des de qualsevol lloc. I només el cal tenir el mòdul QGIS amb el mòdul instal·lat i podran treballar.

Sempre que fem referència a qualsevol element de l’entorn de programació o QGIS, aquest és explicat en el post sobre ‘com preparar l’entorn’.

Procés de creació

Disseny de la interfície

El primer que vam fer va ser la creació de la interfície del plugin. Un cop hem creada l’estructura del plugin amb el ‘Plugin Builder’, vam obrir l’arxiu amb format *.ui amb el Qt Designer i començarem amb la creació. Primer va caldre posar les pestanyes més exteriors (QTab Widget) i dimensionar-lo de manera adequada. Al voltant, vam afegir els elements que ajudaran a escollir els filtres, els mètodes de treball, l’elecció de la connexió i els botons per crear la taula i sortir. Un costum que tenim és el de posar una etiqueta amb la versió de la plugin, ja que ajuda a la identificació de quines són les funcions que pot tenir un plugin. Els plugins poden patir diferents actualitzacions i les funcions poden variar. En el cas de que hi hagi un error en una versió que no és la més recent, l’etiqueta facilita la detecció de l’error i es pot corregir ràpidament. El resultat de tot això es pot veure a la figura 1.

p1
Figura 1

Un vegada fet, vam afegir els elements de dintre les cinc pestanyes dels filtres. Finalment, el que vàrem fer és donar-li un nom que ajudi a la identificació de cada element interactiu de la interfície. Aquest serà el nom que utilitzarem per poder-hi interactuar dins el codi principal que controlarà el plugin. A la figura 2 es pot veure com quedaria la finestra amb la pestanya principal omplerta.

p2
Figura 2

Recomanem que siguin el més explícits possible ja que es podran evitar errades i també ajudaran a facilitar la comprensió del codi, com per exemple ‘ComboConnexio’ en referencia a la pestanya desplegable on s’hi indicarà la connexió que volem escollir.

Interacció amb les Bases de Dades

Per a poder realitzar qualsevol acció sobre la base de dades cal primer saber el nom d’usuari, nom de la base de dades, servidor i contrasenya. És recomanable guardar aquestes dades en variables globals i aconseguirem accedir-hi des de qualsevol funció en qualsevol moment. També cal fer l’import de la llibreria psycopg2 (import psycopg2) al principi del codi.

Per establir la connexió hem utilitzat el codi següent:

#Connexio
nomBD = nomBD1.encode('ascii','ignore')
usuari = usuari1.encode('ascii','ignore')
servidor = host1.encode('ascii','ignore')
contrasenya = contra1.encode('ascii','ignore')
try:
  estructura="dbname='"+nomBD+"' user='"+usuari
  +"' host='"+servidor+"' password='" + contrasenya + "'"
  conn = psycopg2.connect(estructura)
  cur = conn.cursor()
  cur.execute(Sentencia_sql)
  resultat = cur.fetchall()
  conn.close()

Utilitzarem la comanda execute(<sentencia SQL>) per realitzar la consulta. Per poder passar els resultats i per poder-los tractar utilitzarem la comanda fetchall() que retorna una matriu amb tots ells. És important tancar la connexió un cop haguem fet les consultes necessàries.

En el cas que ens ocupa, hi ha tres pestanyes del grup de pestanyes principals que necessiten llegir dades de la BD i exposar-les en els seus respectius camps. Com per exemple en la pestanya ‘Estudis’ hi ha un requadre amb una llista (QListWidget) on cal llistar-hi tots els estudis que hi pot haver i que tenim emmagatzemats a la taula del Padró. El que busquem nosaltres és una consulta que ens retorni els diferents tipus d’estudi que hi ha i ho hem resolt amb la sentencia SQL següent:

select distinct("HABNIVINS"),"NINDESCRI" from "public"."Padro" order by 2;

El camp “HABNIVINS” és l’identificador de l’estudi i el “NINDESCRI” és el nom de l’estudi que apareixerà al requadre de la llista. L’identificador de l’estudi el vincularem a l’estudi per mitjà del ToolTip(), que posteriorment ens facilitarà la construcció de la consulta que l’usuari desitja.

Connexió dels botons

Per poder vincular i recollir els estats dels elements de la interfície cal fer els següents passos. Primer de tot cal fer from TaulaResum_dialog import TaulaResumDialog per tal de poder vincular el fitxer de la interfície amb el codi.

Aleshores, a la funció init(), que ja ve creada pel Plugin Builder, hi posem les següents comandes:

self.dlg = TaulaResumDialog()
self.dlg.btoNACIONALITAT.toggled.connect(self.on_click_MarcarBotoNACIONALITAT)
self.dlg.comboConnexions.currentIndexChanged.connect(self.on_Change_ComboConn)

El primer inicialitza el diàleg amb el què hem d’interaccionar. Les altres dos activen les seves funcions respectives cada vegada que el valor que tinguin variï. Segons el tipus d’element que sigui, es pot canviar l’aparença o carregar elements per pantalla.

Cada element de la interfície ha de tenir una funció vinculada a ell per tal de que el codi sigui capaç de veure en quin estat està.

Programació dels efectes dels botons

Cada vegada que l’usuari interaccioni amb un dels elements de la interfície es produirà un efecte. En aquest apartat s’introduirà un exemple d’aquest tipus de comportament. Per l’exemple utilitzarem el codi següent:

def on_click_MarcarBotoEDAT(self, clicked):
if clicked:
  self.dlg.btoEDAT.setStyleSheet('background-color: #7fff7f')
  self.dlg.GrupPestanyes.setCurrentIndex(0)
else:
  self.dlg.btoEDAT.setStyleSheet('background-color:rgb(227,227,227)')

Aquesta funció es dedica a controlar l’aspecte del botó del filtre d’Edat. Si és clicat, canvia de color de fons i mostra la pestanya del filtre d’edat per tal que l’usuari esculli els paràmetres que vol analitzar. Altrament, li torna a posar el color de desactivat.

A més a més, cal tenir en compte que els elements de la interfície tenen memòria i que un cop els hi canviem l’estat, creem la taula i tanquem el plugin, una vegada el tornem a obrir, conserven el seu estat anterior. Això fa necessària una funció que posi aquests elements en el seu estat inicial cada vegada el que el plugin s’obri i s’utilitzi.

En el nostre cas, la majoria d’elements de la interfície tenen efectes molt senzills com el que hem explicat fa un moment però hi ha un botó que realitza una funció més complexa: crear la taula resum. Aquesta funció recull totes les dades que l’usuari ha introduït sobre els filtres que desitja analitzar, comprova que no hi hagi cap error o que falti alguna dada, es connecta amb la base de dades i escriu el resultat en fitxers de text .csv per a que l’usuari els pugui utilitzar sempre que vulgui.

Un altre punt important és el control d’errors. Cada cop que es produeixi un resultat no esperat s’ha controlar i avisar a l’usuari del que ha passat i indicar-li els passos per corregir l’errada. En el nostre cas, els errors més comuns es produeixen a l’hora de crear les consultes: l’usuari no introdueix correctament les dades de la consulta. Però també pot ser que la connexió no estigui disponible o que l’usuari no tingui els permisos adequats de lectura.

Quan es tracta d’un error relacionat amb la connexió s’adverteix a l’usuari per mitjà d’una etiqueta que n’indica l’estat. En el cas de tenir problemes amb la consulta, apareixen finestres amb el missatge d’error.

Prova del plugin

Una vegada hem programat totes les funcions, cal comprovar que els resultats són els esperats. Per fer-ho, cal que utilitzem el GeoMedia amb el plugin que s’utilitzava anteriorment i comprovar que si posem les mateixes variables d’entrada obtenim el mateix resultat.

Cal que el procés sigui exhaustiu perquè cal revisar cadascuna de les funcions que s’han implementat. S’han de fer totes les combinacions possibles i comprovar que el número de resultats ha sigut igual. En el cas que no ho sigui, s’han de comparar els codis i veure el punt on difereixen.

Primers passos en el ‘rutatge’ al QGIS

En aquest post mostraré els passos que he hagut de seguir per tal de crear el primer dels mòduls que utilitza funcions de rutatge en el QGIS. En aquest cas, volem traslladar el mòdul que calcula els 3 camins a les escoles bressol i llars d’infants més pròximes a cada portal de la ciutat de Mataró. En primer lloc presento les capes amb les quals es treballa. Llavors segueixo amb la creació del mòdul i la seva utilització.

Capes de treball

Actualment amb el GeoMedia treballem amb bases de dades de Microsoft Access majoritàriament. Aquestes incorporen tot tipus de dades, ja sigui taules amb informació sobre el padró o el cadastre, que no estan georeferenciades, o capes de punts, línies o polígons com poden ser els mapes de carrers, illes, cruïlles i serveis públics de la ciutat. Les dades en aquest format ens permeten una gran versatilitat d’ús i facilitat tan en l’ús com en la creació, modificació i eliminació. També són fàcilment exportables a qualsevol altre tipus de format per seguir treballant. Ocasionalment també treballem amb arxius SHAPE.

El QGIS permet gestionar formats raster i vectorials a través de les biblioteques GDAL i OGR, així com altres bases de dades. Una biblioteca GDAL i OGR és un conjunt de programes que estan formats per comandes, cada un amb moltes possibilitats d’ús.

Les capes més comunes amb les quals hem treballat són el Vector Layer, on utilitzem arxius SHAPE (.shp), i Delimited Text Layer on utilitzem arxius CSV (.csv).

Ambdos tipus de dades poden ser modificats fàcilment: tan crear, inserir, modificar o eliminar objectes i/o camps, la qual cosa els fa idonis treballar amb aquests tipus d’arxius ja que si volem fer proves per poder desenvolupar les consultes o els mòduls, ens són de gran utilitat.

Procés de creació

Per crear la interfície gràfica s’utilitza un creador de models que porta incorporats una sèrie de funcionalitats. Haurem d’anar a la caixa d’eines de processat i allà “crear model nou”.
fuc
I seguidament se’ns obra la següent finestra:
nou
Les dues imatges següents corresponen a la columna de l’esquerra de l’anterior imatge hi tenim tots els tipus de paràmetres amb els quals podem treballar, i si canviem a la pestanya de algoritmes, trobem totes les funcions amb les quals podrem treballar sobre les dades. Cal veure el funcionament d’aquestes per tal de poder-les utilitzar correctament.

fuc

dades

 

 

 

 

 

Seguidament, vam afegir el tipus de dades i buscar les funcionalitats adequades per construir la interfície gràfica.

dades2
Una vegada introduïdes les capes, va ser necessari buscar una funcionalitat que convertís el tipus de geometria dels objectes de les capes de punts ja que van sorgir problemes per què obteníem una capa buida. En el nostre cas vam utilitzar el mòdul “Convert Geometry type”.
convert
Seguidament vam començar la recerca d’entre les funcionalitats alguna que calculi una ruta entre dos punts. No existeix una funcionalitat que faci tal funció, així que vam seguir la cerca. Vam seguir buscant entre els plugins que permet instal·lar el QGIS. Vam trobar-ne un que si que fa aquesta funció però no ens era d’utilitat ja que no hi ha cap manera d’automatitzar el procés de càlcul de les distàncies. Això doncs, vam recórrer a l’últim recurs: crear un script en Python que realitzi la funció.

Vam trobar un script que calculava la ruta entre dos punts sobre un graf de carrers. Aquest script utilitza una funció interna de la API de QGIS anomenada “dijkstra” que et retorna un camí. El següent script és el que vam trobar a Internet:

##ruta=name
##ruta=name
##points=vector
##network=vector
##output=output vector

#Algorithm body
#==================================
from PyQt4.QtCore import *
from PyQt4.QtGui import *

from qgis.core import *
from qgis.gui import *
from qgis.networkanalysis import *
from processing.tools.vector import VectorWriter

point_layer = processing.getObject(points)
network_layer = processing.getObject(network)
writer = VectorWriter(output, None, [QgsField("order", QVariant.Int)],
network_layer.dataProvider().geometryType(), network_layer.crs())

# prepare graph
vl = network_layer
director = QgsLineVectorLayerDirector(vl,-1,'','','',3)
properter = QgsDistanceArcProperter()
director.addProperter( properter )
crs = vl.crs()
builder = QgsGraphBuilder( crs )

# prepare points
features = processing.features(point_layer)
point_count = point_layer.featureCount()
points = []
for f in features:
  points.append(f.geometry().asPoint())
tiedPoints = director.makeGraph( builder, points )
graph = builder.graph()
route_vertices = []

for i in range(0,point_count-1):
    progress.setPercentage(int(100 * i/ point_count))
    
    from_point = tiedPoints[i]
    to_point = tiedPoints[i+1]
    from_id = graph.findVertex(from_point)
    to_id = graph.findVertex(to_point)

    (tree,cost) = QgsGraphAnalyzer.dijkstra(graph,from_id,0)
    if tree[to_id] == -1:
        continue # ignore this point pair
    else:
        #collect all the vertices between the points
        route_points = []
        curPos = to_id 
        while (curPos != from_id):
            route_points.append(graph.vertex(
graph.arc(tree[curPos]).inVertex()).point())
           curPos = graph.arc( tree[ curPos ] ).outVertex()
        route_points.append(from_point)
    # add a feature
    fet = QgsFeature()
    fet.setGeometry(QgsGeometry.fromPolyline(route_points))
    fet.setAttributes([i])
    writer.addFeature(fet)
del writer

Un cop testejat i debuguejat, vam començar amb la modificació de l’script per tal d’obtenir el resultat desitjat. Aquest va ser un procés complex ja que s’havia de canviar el programa per dins. Després de forces entrebancs en el procés vam aconseguir un resultat força aproximat al que volíem. Van caldre forces hores per acabar de depurar el codi ja que teníem petits errors que costaven de detectar.

##dintreilla=vector
##EscolesBressol=vector
##network=vector
##output=output vector
#Algorithm body
#==================================
from PyQt4.QtCore import *
from PyQt4.QtGui import *
import time
from qgis.core import *
from qgis.gui import *
from qgis.networkanalysis import *
from processing.tools.vector import VectorWriter

start_time = time.time()
network_layer = processing.getObject(network)

inputPoint = processing.getObject(dintreilla)
features = processing.features(inputPoint)

inputPoint2 = processing.getObject(EscolesBressol)
features2 = processing.features(inputPoint2)

di= 0
eb= 0
id = -1
fields = []
fields.append (QgsField("ID", QVariant.Int))
fields.append (QgsField("Length", QVariant.Int))
fields.append(QgsField("From_Node",QVariant.String))
fields.append(QgsField("To_Node",QVariant.String))

writer = VectorWriter(output, None, 
fields, network_layer.dataProvider().geometryType(), network_layer.crs())

#Per buscar els 3 millors de cada punt

for fea1 in features:
    di=di+1
    #xx = fea1.geometry().asPoint().x()
    #yy = fea1.geometry().asPoint().y()
    #pStart = QgsPoint(xx, yy)
    from_node = fea1.attributes()
    inici = from_node[0]
    print inici
    fea2=None
    features2 = processing.features(inputPoint2)
    eb = -1
    vec = []
    for fea2 in features2:
        eb=eb+1
        id  = id + 1
        nom = fea2.attributes()
        desti = nom[2]
       #---------------------------------------------------------------
        vl = network_layer
        director = QgsLineVectorLayerDirector(vl,-1,'Cost','Cost_inver','',3)
        properter = QgsDistanceArcProperter()
        director.addProperter(properter)
        crs = vl.crs()
        builder = QgsGraphBuilder(crs ,True,0.001)

        # prepare points
        points = []
        points.append(fea1.geometry().asPoint())
        points.append(fea2.geometry().asPoint())

        tiedPoints = director.makeGraph( builder, points )
        graph = builder.graph()

        route_vertices = []
        for i in range(0,2-1):
            from_point = tiedPoints[i]
            to_point = tiedPoints[i+1]

            from_id = graph.findVertex(from_point)
            to_id = graph.findVertex(to_point)

            (tree,cost) = QgsGraphAnalyzer.dijkstra(graph,from_id,0)
            if tree[to_id] == -1:
                continue # ignore this point pair
            else:
                # collect all the vertices between the points
                route_points = []
                curPos = to_id 
                while (curPos != from_id):
                    route_points.append(graph.vertex(
graph.arc(tree[curPos]).inVertex()).point())
                    curPos = graph.arc(tree[curPos]).outVertex()

                route_points.append(from_point)

            # add a feature
            geom=QgsGeometry.fromPolyline(route_points)
            fet = QgsFeature()
            fet.setGeometry(QgsGeometry.fromPolyline(route_points))
            fet.setAttributes([id, geom.length(), inici, desti])
            vec.append(fet)
           
    if (len(vec) > 0):
        vec.sort(key=lambda vec: vec[1])
        for i in range (0,3):
            writer.addFeature(vec[i])
del writer
print("--- %s seconds ---" % (time.time() - start_time))

Finalment vam aconseguir un resultat que s’ajustava a les nostres necessitats, i així completar el procés de creació d’un mòdul amb el QGIS. Vam posar l’script en un mòdul per a python, vam posar-li totes les connexions necessàries.
python
I aquest en va ser el resultat final de tot el procés:
final

Procés d’utilització

Aquí es descriu el procés d’utilització del mòdul per trobar els 3 Camins més pròxims a una Escola Bressol i una d’infants. Aquest comença amb la preparació de les dades a la llegenda o panell de capes del QGIS. En el cas que ens ocupa necessitarem 4 capes SHAPE, 3 de punts i una de segments. Les 3 capes de punts són les Escoles Bressol, les Llars d’Infants  i els dintreilles, que són tots els portals de la ciutat.  I la capa de segments són el conjunts de carrers de la ciutat, és a dir, per on hem de trobar el camí.

Primer de tot, hem de tenir les capes en el tipus desitjat: SHAPE. En el cas que no estiguin ja en aquest format, cal transformar-les per tal de poder-hi treballar. Un cop les tinguem, les guardem per tal de poder-les agafar i emprar.

Tal com s’indica a la fotografia, s’afegeix cada capa via Capa -> Añadir capa -> Añadir capa vectorial:
afe3

afe

Seleccionem explorar i amb l’ajuda de la finestra, busquem els arxius SHAPE que volem posar.

afe2

Repetim l’acció 3 vegades més fins a aconseguir les 4 capes desitjades, tal i com es veu a la foto.

Un cop fet, anem al panell de la dreta de la pantalla on hi ha la “caja de herramientas de procesado” i busquem a l’apartat de Modelos -> CCU, un model anomenat “3EB més pròximes”.
afe4

Una vegada trobat, cal executar-lo. S’obrirà una pestanya amb el següent diàleg:

afe5

Posem a cada pestanya la capa que ens demani: a la primera hi posem la xarxa de carrers sobre la qual volem treballar, a la segona hi posem els Dintreilles o portals de la ciutat(assegurar-se de que sigui la versió “dintreilla_trajectes”) i finalment les escoles bressol o les llars d’infants. Haurem de repetir el procés per cada una de les capes: una per les EB i una altre per les LI.

Un cop tot estigui a punt, només cal executar el procés i esperar a obtenir el resultat. El temps d’espera pot variar segons l’ordinador on s’estigui executant aquest.

Quan finalitzi el procés cal guardar el resultat en un fitxer SHAPE, ja que està en un fitxer temporal i per tant, es perdria en el moment en què tanquem el programa.

Prova del mòdul

En aquest apartat es mostra un exemple de mostra del mòdul. No utilitzaré la capa del ‘dintreilla’ ja que es massa gran i per veure el funcionament, amb una simple capa en tenim prou.

En aquest cas utilitzaré una capa amb un punt (de color vermell) que serà el punt d’origen i una altre capa (de color verd) amb els possibles destins més propers. D’aquesta manera es pot veure ben clar el funcionament.
ex1

Posem en marxa el mòdul i el resultat que obtenim és el següent:

ex2

A la imatge es pot veure el graf de carrers de la ciutat de Mataró. S’hi pot veure 3 camins ressaltats de color verd clar. Tots tres tenen com a origen el punt vermell.

Generador de polígons de Voronoi (2/2)

En l’anterior entrada del bloc s’ha explicat l’aplicació “generador de polígons de Voronoi” des del punt de vista d’un programador, en aquest capítol s’explicarà com funciona des del punt de vista de l’usuari.

Es comentarà tot el procés que ha de fer l’usuari per poder utilitzar el mòdul de forma correcte i treure-l’hi el millor partit possible. Per això també es realitzaran una sèrie d’exemples per que l’usuari tingui la màxima facilitat a l’hora d’entendre el funcionament.

Carregar l’aplicació al Geomedia

Primerament explicaré com carregar el mòdul VB al Geomedia, de tal forma que pugui ser utilitzat per l’usuari.

  • Quan utilitzem el geomedia command wizard , plug-in que serveix per implementar el mòdul visual basic per que pugi ser utilitzar en l’entorn del geomedia profesional, se’ns creen dues carpetes.

Fig. 1. Contingut del nou projecte.

  • La carpeta “src” conté tots els arxius del projecte (mòduls, formularis etc..)

Fig. 2. Contingut carpeta "scr".

  • En la carpeta “bin” trobem l’arxiu .dll que es el que s’haurà d’instal·lar dintre del Geomedia.

Fig. 3. Contingut de la carpeta "bin".

  • Per instal·lar-ho utilitzem l’icona “install” d’intergraph, com podem veure a la següent imatge. Seleccionem la ruta de la carpeta “bin” del nostre projecte i pitgem “OK”.

Aquest procés tan sols s’haurà de fet un primer cop, ja que una vegada instal.lat el mòdul una vegada, per qualsevol canvi en el mòdul tan sols s’haurà de generar una nova dll, amb el procés explicat anteriorment al final del capítol anterior.

Fig. 4. Instal•lació nou mòdul creat.

  • Finalment, s’hi la instal·lació ha estat un èxit, ens hauria de sortir un missatge com el següent.

Fig. 5. Instal•lació satisfactòria del mòdul.

  • Una vegada estem dintre del interface del Geomedia Professional abans de poder provar el nostre mòdul, haurem de fer una mínim una connexió amb una base de dades que contingui classes d’entitat puntual de línia i d’àrea. ja que les tres son necessàries de cara al funcionament del aplicatiu. Per fer la connexió seguim el mateix procés explicat en el capítol 2, apartat Geomedia Professional.

Fig. 6. Addició de les connexions necessàries.

  • Una vegada fetes les connexions necessàries haurem de pitjar sobre un icona que ens apareixerà per defecte com el de la següent imatge. (Si volem tenir el mòdul a un dels menús, s’ha de seguir el procés explicat a L’annex 1).

Fig. 7. Icona per defecte del nostre mòdul.

  • Que ens portarà a la finestra del nostre mòdul, preparat per ser utilitzat.

Fig. 8. Finestra mòdul.

Exemples de la aplicació

En aquest capítol s’explicarà amb exemples el funcionament de la aplicació creada en l’entorn del Geomedia Profesional.

És realitzaran 4 exemples  amb centres proveïdors de serveis (escoles bressol, CAPS, centres de formació primària, Parades de bus) i un especial amb una consulta. Aquests exemples estaran documentats pas per pas i aportant diferents captures per mostrar els diferents punts de vista.

Escoles bressol

Per poder visualitzar el resultat dels polígons de Voronoi de la millor manera posible, haurem de tenir activades a la llegenda un mínim de dos classes d’entitat. Per una banda, l’area que limitarà el Voronoi, en aquest cas, el terme municipal de Mataró i per l’altra la classe d’entitat puntual sobre la que volem crear les nostres zones d’influència, en aquest exemple, seran les escoles bressol. Per això anem a Leyenda>Agregar entradas de leyenda i seleccionem aquestes en els desplegables de les connexions i pitgem el botó “aceptar”.

Fig. 9. Agregació de entrades de llegenda necessàries.

Com podem veure en les imatges, ens apareixeran les escoles bressol situades en el terme municipal.

Fig. 10. Escoles bressol i el terme municipal mostrats a la pantalla.

Si volem saber més detalls sobre les escoles, simplement pitgem a sobre d’una i ens apareixerà un quadre de diàleg com el següents on ens donarà propietats com el nom de l’escola o el numero de places entre d’altres.

Fig. 11. Propietats de les escoles bressol.

Una vegada tenim les classes d’entitat seleccionades a la llegenda, anem al mòdul  i seleccionem en els desplegables “EscolaBressol” com a entitat puntual, “Terme_municipal” com àrea delimitada i “Linies” com a sortida lineal per guardar el resultat del diagrama de Voronoi. Finalment pitgem el botó Calcular Voronoi.

Fig. 12. Omplir desplegables del mòdul per escoles bressol.

Com podem veure obtenim el diagrama Voronoi perfecte sobre les escoles bressol. El diagrama per aquest cas constarà de 17 línies guardades a la classe d’entitat “linies”.

Fig. 13. Polígons de Voronoi sobre les escoles bressol.

Com es pot comprovar, les línies no acaben en el límit del terme municipal, això es deu, ja que l’algoritme de Voronoi sempre es base en un quadrat o rectangle per arribar al punt final de les línies. Per tant en aquest cas calcula un quadrat imaginari amb els punts més alts de l’amplada i l’alçada. Per poder arreglar aquest problema, tenim dos formes de fer-ho des de el Geomedia:

  1. Fent una intersecció espacial:

Anem a Analisis> Intersección espacial .Una vegada dintre haurem de seleccionar  les classes d’entitat de línia i terme municipal i deixar per defecte la opció ” es toquen”. Escrivim el nom final de la consulta resultant i pitgem “aceptar”.

Fig. 14. Intersecció espacial entre línies i terme municipal.

Amb aquesta intersecció aconseguirem el resultat desitjat, com podem veure a la següent captura. El resultat de la consulta com podem veure a la llegenda es una barreja entre línies i àrees.

Fig. 15. Voronoi final sobre les escoles bressol mitjançant intersecció.

2.  Amb la opció dividir entidades.

Pitgem el boto “dividir entidades”.

Fig. 16. Procés dividir entitats (1/3).

Marquem el cursor i seleccionem el mapa amb les línies amb un quadrat.

Fig. 17. Procés dividir entitats (2/3).

Pitgem amb el botó dret a la pantalla i seleccionem la opció “realizar division”. Llavors, et va dividint el terme municipal en seccions de una en una.

Fig. 18. Procés dividir entitats (3/3).

Fins arribar al resultat final on tenim el Terme municipal dividit en regions de Voronoi.

Fig. 19. Voronoi resultant sobre escoles bressol mitjançant divisió d'entitats.

Llavors amb aquest mètode obtenim com a resultat final àrees. Seleccionant a la llegenda la classe d’entitat  “illes” podríem veure les regions d’una forma més visual.

Fig. 20. Voronoi resultant sobre escoles amb la capa d'illes.

Per últim activant la capa de la “ortofoto2013” a la llegenda podem visualitzar els polígons des de una vista Aérea similar a la de Google Maps.

Fig. 21. Voronoi resultant sobre escoles amb la capa "ortofoto".

CAPS

En aquest exemple crearem les regions de Voronoi al voltant dels CAPS de Mataró.

Primer de tot, com hem fet en l’exemple anterior agreguem a la llegenda la classe d’entitat puntual (CAPS)i  l’àrea  delimitant (terme_municipal). Com podem comprovar tenim 8 CAPS tal i com ens mostra la llegenda.

Fig. 22. Caps i terme municipal mostrats en pantalla.

Obrim el mòdul i  com hem fet en l’exemple anterior, seleccionem l’entitat puntual,(CAPS en aquest cas), el terme municipal com a area delimitada i per últim “linies” com a classe d’entitat de sortida per guardar el resultat. Pitgem Calcular Voronoi.

Fig. 23. Omplir desplegables del mòdul per escoles bressol.

Obtenim el  digrama de Voronoi resultant pels CAPS, que conté en aquest cas 14 línies.

Fig. 24. Diagrama de Voronoi sobre CAPS.

Llavors, utilitzant el segon sistema explicat anteriorment (Escoles bressol) per separar el Terme municipal en les regions de Voronoi obtindríem la següent imatge.

Fig. 25. Voronoi final sobre els CAPS mitjançant intersecció espacial .

Agregant la classe d’entitat illes a la llegenda tindríem la següent vista.

Fig. 26. Voronoi final sobre els CAPS amb la capa d'illes .

Finalment amb activant la Ortofoto com en l’exemple anterior, tindríem la vista des de dalt.

Fig. 27. Voronoi final amb la vista Aérea.

Parades de bus

Com als altres dos exemples, agreguem a la llegenda les parades de bus en aquest cas i el terme municipal. Com es pot comprovar a la següent imatge hi ha un total de 144 parades de bus a Mataró.

Fig. 28. Parades de bus i terme municipal mostrats en pantalla.

Seleccionem ParadesBus, Terme_municipal i Linies en els desplegables del nostre mòdul.

Fig. 29. Omplir desplegables del mòdul per Parades de bus.

Una vegada pitgem al botó Calcular Voronoi, obtindrem un resultat com el següent, abans però haurem d’esperar uns segons ja que al haver-hi 144 parades de bus, el programa necessita més temps per executar l’algoritme. Per tant no serà de forma immediata com en els altres dos exemples. Com podem veure  a la imatge s’han necessitat 408 línies per completar el diagrama de Voronoi.

Fig. 30. Diagrama de Voronoi per Parades de bus.

En aquest exemple utilitzem el primer mètode de intersecció espacial per arribar al resultat final desitjat. Anem a Analisis> Interseccion espacial i omplim els camps de la mateixa manera que en l’exemple de les escoles bressol.

Fig. 31. Intersecció espacial entre línies i terme municipal.

Al prémer el botó Acceptar obtindrem el Voronoi final de les parades de bus.

Fig. 32. Polígons Voronoi resultants sobre parades de bus mitjançant intersecció espacial.

Si afegim les illes a la llegenda, l’aspecte ens quedaria de la següent forma.

Fig. 33. Polígons Voronoi resultants amb la capa d'illes.

Apliquem la ortofoto per visualitzar el resultat de la millor forma possible.

Fig. 34. Polígons Voronoi resultants amb la vista Aérea.

Consultes

Aquest mòdul no només es pot utilitzar per classe d’entitats que estiguin a la base de dades connectada. Aquesta aplicació com la majoria de les creades en el CCU també pot utilitzar consultes que estiguin en memòria. La particularitat de la consulta es que pots seleccionar d’una mateixa classe d’entitat les entitats que tu vols, i després executar el mòdul sobre aquella selecció feta.

Si per exemple volem fer el Voronoi dels CEIPcon en el centre Urbà de Mataró com és mostra en la fotografia, hi ha un CEIPcon que quedaria fora d’aquest centre urbà. El problema vindria, ja que al executar el mòdul ho faria per totes les entitats, inclús la que queda fora del territori, per tant una consulta ens pot permetre eliminar aquesta entitat en memoria sense modificar la base de dades i poder realitzar el diagrama de Voronoi de forma satisfactòria.

Fig. 35. CEIPcon i centre urbà en pantalla.

Per crear la consulta desitjada, anem a Analisis>consulta espacial. Seleccionem CEIPcon en el desplegable seleccionar entidades en: . Després haurem de seleccionar la opció “estan contenides en” en el segon desplegable. I Per últim seleccionarem Centre Urba en el tercer desplegable. Finalment introdüirem un nom per la consulta de sortida i pitjarem “Aceptar”.

Fig. 36. Consulta espacial.

Per tant aquesta consulta el que ens farà serà seleccionar totes les entitats de CEIPcon que estiguin dintre del centre urbà.

Fig. 37. Nova consulta espacial representada a la llegenda.

Ara ja podrem utilitzar el mòdul per la consulta desitjada.  Simplement accedim al mòdul i en el desplegable de selecció d’entitat puntual, seleccionem la consulta creada en el sub-desplegable de consultes.

Fig. 38. selecció de la consulta creada al desplegable.

Com en exemples anteriors, seleccionem l’àrea delimitada en aquest cas seria el centre urbà i la classe d’entitat de tipus línia de sortida.

Fig. 39. Omplir desplegables del mòdul per escoles bressol.

Obtenim el Voronoi de forma perfecte sense tenir en compte la entitat exclosa.

Fig. 40. Polígons de Voronoi per la consulta creada.

Utilitzem la opció “dividir entidades” per obtenir el digrama final.

Fig. 41. Polígons de voronoi finals per la consulta creada mitjançant dividir entitats.

 

Segmentació de la Població

 

Tal com vam veure en un ‘post’ anterior sobre les agregacions de la població de la ciutat, utilitzant la base de dades del Padró Municipal d’Habitants es pot localitzar la població segons la Illa de cases on es viu, segons la parcel·la o segons el portal on hi ha el seu domicili.

Aquesta manera de geolocalitzar pot ser molt útil per mesures o consultes en les quals interessi veure on hi ha més gent o on n’hi ha menys. Però, anant més enllà, pot caldre també discernir sobre quin tipus de població hi ha, segons característiques que estiguin reflectides en el Padró, aquestes característiques són: la data de naixement, el gènere, els estudis, el lloc de procedència , la nacionalitat, i totes les  declarades per cada ciutadà a   l’empadronar-se a la ciutat.

Aquestes propietats, juntes, combinades o separades poden determinar segmentacions de la població en cada una de les agregacions per lloc de què parlàvem abans.

En un anterior exemple sobre les Escoles Bressol Municipal, el segment de població que interessava geolocalitzar era el de nens entre 0 i 2 anys. Anem a veure una interfície del plug-in construït en VB per treballar sobre el SIG  GeoMedia que permet fer aquestes segmentacions.

 

Fig 1. Interfície per fer la Segmentació i l’Agregació dels habitants

A la figura 1 podem veure a la pestanya de l’ edat uns camps on indicar el marge inferior i el marge superior de l’edat que estem cercant, i amb dues possibilitats de comptabilitzar-ho,  estrictament si compleix anys a la data indicada, o en sentit ampli, la persona té X anys fins que no en compleixi  X+1. A la part superior del formulari es pot veure el mètode d’agregació que s’utilitzarà que en aquest cas és el de les Illes.

Aquestes dades de franges d’edat es podrien combinar amb el gènere i el nivell d’estudis o qualsevol altre propietat. Per exemple si el segment que cerquem és el d’homes entre 50 i 60 anys que tinguin estudis universitaris a nivell de llicenciatura, s’haurien de posar els paràmetres a les pestanyes corresponents com es pot veure a les figures 2, 3 i 4.

Fig 2: Marge d’edat
Fig 3: Gènere
Fig 4: Estudis

També s’observa a la figura 4, que en el formulari cal marcar tots els criteris pels quals es farà la cerca, abans de generar la taula,  a més a més cal posar els paràmetres corresponents a cada una de les pestanyes que siguin necessaris per a cada cas.

En resum, com a eina necessària en els estudis de població basats en les dades del Padró Municipal d’Habitants, presentem aquest recurs que permet de generar taules per entitats agregades,  escollides segons els segments de població que ens interessin i que permetin les dades, presentant sempre dades agregades i mai personalitzades.

 

WFS: Interactuació amb mapes.

Descripció.

La necessitat de transferir cartografia per Internet ha sigut, i encara és, un problema difícil. La cartografia digital conté un gran volum de dades d’informació, i enviar aquestes quantitats de megabytes per Internet és una tasca pesada, i lenta.

És per això que es va començar a treballar amb WFS, sigles de “Web Feature Service”, que és un servei estàndard que ofereix una interfície que permet sol·licituds de comunicació, permetent interactuar amb mapes WMS (Web Map Service).

A través d’una URL, es pot accedir a les dades cartogràfiques que s’hagin publicat a la taula WFS, i fer consultes específiques, més endavant es mostra un exemple.

Per realitzar aquestes operacions s’utilitza el llenguatge GML, que deriva de XML,  és l’estàndard a través del qual es transmeten les comandes WFS.

Un cop s’ha fet la publicació de la taula WFS i es té la URL que apunta a ella, es poden veure les dades en alguns SIG (Sistemes d’Informació Geogràfica) que permetin el tractament d’aquest tipus de dades, en aquest cas al Geomedia.

En aquest cas, s’ha decidit a utilitzar la taula de trajectes i proximitat a les tres escoles bressol més properes.

Com fer la publicació?

Primerament, des del servidor on està instal·lat el GeoMediaWebMap Professional, s’obre el Server Configuration Utility i es crea un nou servei amb el botó “Add”.

Creació del servei.

El següent pas és seleccionar l’opció Manipulate Feature Web Service.

Es deixen els valors per defecte i es va prement “Next”, s’haurà d’introduir un nom pel WFS.

Nom del servei.

Quan es demani el tipus de base de dades, introduir Microsoft Access. La resta es deixa per defecte, i es finalitza, el servei s’ha creat.

En aquest punt, s’obre el Geomedia i es carrega el mapa que es vol publicar, s’obre el “GeomediaWebMap Publisher Administrator”.

Configurant el Geomedia.

Es selecciona el servei que s’acaba de crear i apareixerà una barra amb botons. Polsar sobre el cinqué botó “PublishandPopulatetheGeoWorkspace”, i seleccionar la primera opció “PublishtheGeoWorkspace contents to theMetaData”. Es selecciona “Sí”.

Botó “settings”.

Es selecciona el segon botó, “settings”. Aquí s’ha de seleccionar l’arxiu .csf que conté el sistema de coordenades. Després es prem l’últim botó per tancar el menú.

En aquest punt només queda inicialitzar el servei, per fer-ho, es torna al Publisher Server Configuration Utility, es selecciona el servei que s’ha creat i es prem “Initialize”.

Servei inicialitzat.

Provar el servei des del navegador introduint l següent línia de comanda:

http://geoportalccu.tecnocampus.cat/ProvaWFS/request.aspx?version=1.1.0&service=wfs&request=getcapabilities

Codi GML creat.

Interpretació gràfica del codi GML.

Veure així el codi no és interessant, el més interessant és veure-ho transformat en un mapa, al Geomedia per exemple, a continuació es veu com es pot configurar el geomedia per tal de veure la informació del servei WFS.

Primerament s’ha de crear una nova connexió, de tipus WFS, en aquest cas s’ha creat de WFS només lectura, per tal de que les dades no es puguin modificar.

Nova connexió.

S’ha d’introduir la URL abans esmentada, i s’accepta.

Un cop creada la connexió, ja es poden mostrar les seves entrades des de la llegenda.

Ventana de mapa del Geomedia amb les dades.