Entrades classificades amb: entitats

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

 

Mòdul generador de polígons de Voronoi (1/2)

En aquesta entrada es comentarà de forma extensa el nou mòdul del CCU “generador de polígons de Voronoi” des de el punt de vista del programador.

La funció d’aquesta nova aplicació serà la de poder generar zones d’influència per els diversos centres proveïdors de servei en Mataró, així com Escoles, CAPS, parades de bus etc. Aquest sistema s’implementarà amb un mètode geomètric anomenat Voronoi

Els diagrames de Voronoi són un dels mètodes d’interpolació més simples, basats en la distància euclidiana, sent especialment apropiada quan les dades són qualitatives. Es creen en unir els punts entre si, traçant les mediatrius dels segments d’unió. Les interseccions d’aquestes mediatrius determinen una sèrie de polígons en un espai bidimensional al voltant d’un conjunt de punts de control, de manera que dintre de cada polígon o regió la distància a un punt de control associat és sempre menor que a qualsevol altre punt de les altres regions.

Fig. 1. Exemple de diagrama de Voronoi

Algoritme utilitzat

Primer de tot és comentarà l’algoritme utilitzat per du a terme la nova aplicació, trobats a la pagina web de l’informàtic japonès Takashi Ohyam.

http://www.nirarebakun.com/voro/evoro.html

El programa final ha constat  d’una sèrie de mòduls i un formulari.

Fig. 2. Llistat de mòduls i formulari del projecte.

 

Formulari

Primer de tot s’ha creat el formulari, que serà la finestra que apareixerà una vegada pitgem per accedir al mòdul creat. El formulari el podem veure a continuació.

Fig. 3. Formulari de la aplicació creada.

Ara comentaré part per part els diferents desplegables i botons utilitzats en el formulari.

  • En el primer desplegable hem de seleccionar la classe d’entitat puntual sobre el qual volem crear els polígons de Voronoi.

Fig. 4. Desplegable per seleccionar l'entitat puntual.

Fig. 5. Codi relacionat amb el desplegable de selecció d'entitat puntual.

  • En el segon desplegable, haurem de seleccionar la classe d’entitat d’àrea que volem que limiti els polígons de Voronoi. En el nostre cas el terme municipal de Mataró.

Fig. 6. Desplegable per seleccionar l'àrea delimitant.

Fig. 7. Codi relacionat amb el desplegable de selecció d'àrea delimitant.

  • Per últim, seleccionarem la classe d’entitat de línia de sortida. És a dir, on volem que vagin a parar les línies o segments que formaran els polígons de Voronoi finals.

Fig. 8. Desplegable per seleccionar la sortida de les línies dels polígons.

Fig. 9. Codi relacionat amb el desplegable del desplegable de selecció de sortida.

  • Botó “calcular Voronoi”.

Aquest botó el que ens farà serà primerament carregar les dades seleccionades als                 quadres de diàleg del formulari, utilitzant la subrutina “Carregar_dades”.

Fig. 10. Botó calcular Voronoi.

Fig. 11. Codi que va darrere del botó "Calcular Voronoi".

I finalment executarà la subrutina Voronoi_mapa ( que conté l’algoritme ) i d’aquesta manera formarà els polígons desitjats. Aquesta subrutina serà comentada més endavant en l’explicació del mòdul voronoi_code.

  • Botó Sortir

El botó sortir, simplement seria per poder sortir de la aplicació en qualsevol moment.

Fig. 12. Botó sortir.

Fig. 13. Codi que va darrere del botó sortir.

Mòduls

Pel que fa als mòduls, comentaré els dos mòduls principals ( “Obtencio de coordenades”i “voronoi_code”) ja que la resta són creats de forma automàtica quan creem el Geomedia Comand Wizard, que seria el plug-in per tal de poder utilitzar l’aplicatiu VB en el geomedia (Explicat en l’annex II). Tot i que com es veurà més endavant també s’afegeixen algunes funcions necessàries en el mòdul “OperacionsGM”.

Mòdul Obtenció de coordenades

Aquest mòdul és essencial per poder passar al algoritme les coordenades de les diferents classes d’entitats puntuals o serveis sobre les quals haurà de crear les zones d’influència (polígons Voronoi).

El mòdul consta de la subrutina “proximitat”, que li entren els paràmetres rs, entitats.SelectedItem i entitats.ConnectionName procedents de la subrutina “carregar_dades” esmentada al formulari.

  • El primer pas per obtenir les coordenades és afegir a la taula de l’entitat puntual escollida per l’usuari les coordenades X Y d’aquesta. Això és codifica de la següent manera:

  • Generem un recordset afegint a la taula de l’entitat puntual escollida els atributs funcionals que s’han definit anteriorment (Xep, Yep). Un recordset és una estructura utilitzada en programació que permet emmagatzemar informació des d’una taula d’una base de dades.

 

  • Passem el resultat de la consulta (recordset) a una array per les X i per les Y.

  • Obtenim les coordenades en les variables X i Y, que seran utilitzades més endavant en el mòdul Voronoi_code, de cara al algoritme.

Modul Voronoi_code

Aquest mòdul consta bàsicament del algoritme i de subrutines i funcions d’ajuda per que es puguin crear els polígons de Voronoi sobre les coordenades de les classes d’entitats puntuals obtingudes gràcies al mòdul anterior.

La subrutina principal del mòdul és “voronoi_mapa”que podem veure comentada per part seguidament.

  • Primerament, definim les variables i recordsets necessaris per la utilització del programa.

  • Calculem els paràmetres ample i altura que seran utilitzats més endavant en l’algoritme.

  • Establim alguns recordsets necessaris i definim les noves variables utilitzades en l’algoritme. També cridem la funció “borrar_entitat”, que ens permetrà cada vegada que obrim el mòdul buidar la classe d’entitat de línia que he utilitzat per crear el Voronoi anterior.

  • Definim la variable NNN que determina el nombre d’entitats que te la classe d’entitat seleccionada. També  a última hora es van haver d’augmentar el número de posicions dels vectors utilitzats en l’algoritme, ja que en alguns casos on hi havien moltes entitats no acabava de completar l’algoritme per totes elles.

  • Comença l’algoritme amb el següent bucle, ens carrega en memòria totes les entitats en les coordenades corresponents, de cara a crear els polígons.

  • ad(i-1), rep el valor del mòdul de les coordenades X i Y de cada punt i l’utilitza alguns cops en l’algoritme


  • Cridem la subrutina “hSort” passant-li els paràmetres NN, ad, ax, ay calculats anteriorment.


  • Es va executant el gruix de l’algoritme (explicat en l’apartat algoritme i codi inicial) .

  • Finalment amb la funció  Inserta_linia es formen els segments dels polígons a partir d’un punt inicial i un punt final, on les coordenades dels punts serien respectivament x0= kx(k-1) y0= Ky(k-1) i les finals x=kx(k2-1) i y= Ky(k2-1).

Els segments resultants es guarden en un recorset anomenat “Recordset_linia”.

  • Per últim, haurem de mostrar el resultat aconseguit en el mapa i la llegenda

– Seleccionem l’estil de la línia i el nom que li volem posar al resultat.

– Introduïm la entrada de la llegenda en la primera posició

  • Per compilar l’arxiu el programa creat, haurem d’anar a Archivo> generar nomprojecte.dll com podem veure en la següent captura d’imatge. En cas, que no doni cap error de compilació se’ns haurà creat un arxiu ddl i estarà llest per carregar-ho al Geomedia.

Fig. 14. Generar.dll.

Cada vegada que s’hagin fet canvis en el programa, s’haurà de crear una nova dll, de cara a que els canvis sorgeixin efecte en el Geomedia. Com també haurà d’estar tancat el Geomedia Professional m’entres és realitza aquest procés, ja que en cas contrari donarà error.


 


 

 

 

 

 


 

 

Aplicatiu per mostrar trajectes a entitats per ordre de proximitat

En anteriors entrades s’ha comentat la possibilitat de visualitzar la proximitat de la població com també d’obtenir els trajectes existents respecte a una entitat destí. En el nostre cas, s’ha vist aplicat precisament a les Escoles de Bressol Municipals.

Per això, i per la importància que suposa disposar de la informació necessària per tal de determinar si un servei es troba a prop del nostre domicili o bé lluny segons les diverses trajectòries obtingudes al destí desitjat i tenint present, en tot moment, les diverses zones d’influència possibles, s’ha desenvolupat l’aplicatiu de “cerca entitat propera”.

Aquest aplicatiu té la mateixa finalitat que l’utilitzat per cercar els camins a les tres Escoles Bressol més properes, però en canvi, ens permet fer la cerca de qualsevol entitat que es desitgi com també mostrar les dades entre un rang de 1-5 noms d’entitat diferents. Per tant, es pot triar el mode de cerca dels valors d’entre 1 i 5 entitats destí.

Figura 1: Aparença de l’aplicatiu de cerca camins a entitats properes.

Tal i com s’observa, l’aparença de l’aplicatiu és el mateix que l’utilitzat en la cerca de camins a les 3 Escoles més properes, amb la diferència d’haver modificat la grandària de la graella (Datagrid) per tal de poder arribar a visualitzar, en condicions, fins a 5 nom d’entitat diversa.

Per tant, com ja s’ha comentat, aquest nou aplicatiu serveix per indicar els trajectes des de qualsevol adreça de la ciutat a una sèrie d’entitats per ordre de proximitat, i no només limitat a les tres entitats més properes. Igualment el propòsit d’aquest mòdul és verificar les taules de proximitat generades pel mòdul generador de taules de proximitat, sense limitació en el tipus d’entitat ni en el nombre d’entitats properes. Tenint present que la verificació de les taules de proximitat ens és de molta utilitat pensant en la seva publicació via WFS tal com ja s’ha comentat a l’entrada al bloc anomenada: WFS Interacció amb mapes.

Aquesta taula de trajectes de proximitat s’haurà de crear amb anterioritat utilitzant el mòdul “càlcul de distàncies mitjançant el graf” en el qual tal i com s’observa a la Figura 2, es tria el camp d’origen (de quina direcció es parteix) i el camp destí (qualsevol entitat). També és possible triar la unitat de mesura que serà precisament l’observada com a resultat de distància o bé cost de l’aplicatiu. Apareixent els diversos filtres a triar, entre els quals pren importància el número d’entitats que seran amb les quals es farà l’estudi a l’aplicatiu en qüestió i les que es mostraran a la graella i mapa de resultats finals.

Figura 2: Aplicatiu de càlcul de distàncies mitjançant el graf.

Un altre aspecte important és el fet d’emmagatzemar la taula resultant de l’execució del mòdul, doncs s’haurà de triar quin serà el destí de la connexió creant tant la taula de trajectes com de proximitat.

I precisament, un cop es disposi d’aquesta taula, en el següent desplegable dins el mòdul creat s’ha de buscar la connexió on es troba emmagatzemada la BBDD que la conté.

Figura 3: Selecció de la BBDD de trajectes

En el present exemple s’ha creat una taula de trajectòries expressament del Veïnat de Mata tenint com a destí tant Escoles Bressol com Llars d’Infants. I triant 5 entitats destí que es visualitzaran a sobre el mapa com en la graella present a la part inferior de l’aplicatiu.

Figura 4: Incorporació de les dades a fer la recerca dins l’aplicatiu.

Un cop ja s’ha introduït el carrer, el número i la BBDD on es troba la taula de trajectes creada prèviament, s’executa l’aplicatiu: “INICI”.

En la següent imatge s’observa com apareixen les 5 entitats més properes, acompanyades de la distància existent entre el número de carrer (Número de portal) fins les 5 entitats de destí més properes. Aquestes es troben ordenades de més proximitat a menys.

Figura 5: Resultats obtinguts en l’execució.

Tal i com s’observa, apareix la columna del nom de l’entitat com també de la Distància/cost. Aquesta última columna indica la distància existent des del número de policia en la qual ens trobem (Veïnat de Mata, 5) fins a cadascuna de les entitats i que es poden trobar mesurades tant en distància, calculada en metres, com també en cost calculat en temps (segons).

En el present cas, el més pròxim a la situació definida (Núm. Portal 05490005x) és la Llar d’infant Snoopy II (3318 m) i en canvi la que es troba més lluny és el Grup d’Escoles Mataró GEM-Primària (3848m).

En la Figura 6 s’observa sobre el mapa quins són els 5 trajectes a les entitats destí. Cadascun marcat amb un color i gruixut diferent depenent de la seva proximitat fent que sigui més fàcil la visualització i entesa.

Figura 6: Visualització sobre el Mapa els camins a les Entitats obtingudes.

La validesa d’aquests trajectes obtinguts farà que es pugui realitzar posteriorment una publicació via WFS de forma satisfactòria i que per tant sigui possible observar la visualització via Internet (interacció amb mapes).

En resum, el fet de disposar d’aquest aplicatiu permetrà realitzar uns estudis més precisos respecte els diversos trajectes obtinguts disposant de més flexibilitat a l’hora de poder triar el número d’entitats destí, com també es podrà afinar en la cerca del recorregut òptim. Aquesta flexibilitat,  s’observa també en el fet de poder mostrar els resultats tant en distància (metres) com en cost (segons) tal i com succeïa en el mòdul de tria de les Escoles Bressol més properes. El fet de fer servir una variable temporal fa que la mesura obtinguda sigui molt més real respecte a la proximitat a cadascuna de les entitats, però en canvi requereix un model de velocitats més detallat i adequat.

Consultes predefinides sobre l’Activitat Econòmica via WMS

Els serveis de mapes en web (Web Map Service o segons les seves sigles WMS) responen a un sistema de consulta de capes d’informació de forma dinàmica des de la web. Aquests WMS permeten la visualització, combinar o bé consultar una sèrie de dades, de imatges generades a partir d’una o varies fonts (en el nostre cas a través del SIG-Geomedia).

Per poder realitzar la publicació es disposa d’un servidor extern amb el IIS i el GeoMediaWebMap com també es disposa d’una versió del Geomedia  que serà amb el qual es treballarà i el qual permetrà dur a terme les publicacions tant en els serveis WMS com WFS del servidor.

En aquest cas per poder definir les diverses activitats econòmiques que s’han volgut estudiar s’utilitzarà l’aplicatiu anomenat “Mostra les parcel·les que tenen activitat empresarial seleccionada”. Que ens permetrà situar sobre el mapa de Mataró quina és la ubicació de cadascuna de les activitats econòmiques (tal i com s’ha comentat en altres entrades al Bloc).

A la Figura 1 s’observa la llista de les diverses activitats que es poden seleccionar en l’aplicatiu. En aquest estudi s’han realitzat consultes per a: Farmàcies, Forns de pa, Carnisseries, Peixateries i Supermercats o autoserveis. Per tant s’haurà de decidir quin tipus d’activitats es poden incloure per cadascuna de les entitats.

Figura 1: Llista d’Activitats Econòmiques disponibles a l’aplicatiu

En aquest mòdul per realitzar les diverses consultes es treballarà amb els números de policia. I es duran a terme diverses modificacions a les opcions que permetran una visualització al mapa més clara.

Tal i com s’observa la Figura 2 es troben les diverses modificacions realitzades per tal de dur a terme la consulta pel cas de les Farmàcies a 5 minuts. A l’hora de calcular en temps (zona d’influència), a diferència del càlcul de distància, és necessari activar les opcions cost de nusos i cost invers.

Figura 2: Modificacions a les opcions presents a l’aplicatiu

S’obtindran tres resultats per cadascuna de les consultes que es realitzin. Per un costat quedarà definida el nombre d’entitats i la seva ubicació al mapa, també apareixerà la zona d’influència de cadascuna de les entitats (Figura 3). I per últim la població exclosa en cada cas.

Figura 3: Representació zona d’influència (ZI) sobre mapa Mataró

Per cadascuna de les 5 activitats econòmiques s’ha dut a terme una consulta amb una zona d’influència diferent: 150 metres, 300 metres, 2 minuts, 3 minuts i 5 minuts.

Serà necessari exportar aquests resultats a una nova BBDD creada. D’aquesta forma es tindran totes les taules creades per cadascuna de les consultes juntes. Aquesta BBDD un cop creada s’haurà de copiar dins el servidor en el qual es treballa i que permetrà fer la publicació.

Un cop dins el servidor (incorporat la nova BBDD) s’obre el Geomedia i es carreguen els diversos resultats obtinguts amb les consultes. Per fer-ho s’afegeix una nova llegenda i es carrega l’opció que es desitgi (tant pel nombre d’entitats, per la Zona d’Influència i de la Població Exclosa).

Figura 4: Llegenda carregada exemple Supers (Entitat-Zona influència-Població Exclosa).

Per poder realitzar correctament la publicació hauran d’estar totes les consultes carregades i visibles al mapa, ja que el que apareix/es mostra en pantalla és el que s’arribarà a publicar posteriorment. Per tant, ha d’estar visible totalment tal i com s’observa a la Figura 5.

Figura 5: Càrrega de la llegenda i visualització total de les diverses consultes al mapa

A continuació s’inicia el procés de publicació.
En primer lloc s’obre el “Server ConfigurationUtility” del GeoMediaWebMap Professional. I es crea un nou servei seleccionant l’opció “Generate Map Web Service” per crear un servei WMS. Al qual, posteriorment, s’haura d’aplicar el nom que un desitgi.

Figura 6: Generació del Servei WMS dins el Server Configuration Utility

S’ha de tenir present que les metadades que es crearan es guardaran en una base de dades, s’escull Access i s’introdueix quina és la connexió (a on guardar aquesta base de dades creada).

Figura 7: Tria del tipus de base da dades que es desitja

Finalment, i si el procediment s’ha desenvolupat correctament, si es torna a entrar al “Server configuration Utility” es veu com s’ha creat el nostre nou servei dins el Web Service.

A continuació es torna al Geomedia i s’obre el “GeomediaWebMap Publisher Administrator” que es pot trobar a la barra d’eines.

Figura 8: Opció del GeomediaWebMap Publisher Administrator

Es selecciona el Servei WMS que s’ha creat.

Figura 9: Selecció del Servei WMS creat

I apareixerà una barra lateral amb diversos botons.

Figura 10: Les diverses opcions a triar dins el GeomediaWebMap

En primer lloc polsar sobre el 5é botó “PublishandPopulatetheGeoWorkspace”, i seleccionar la primera opció “PublishtheGeoWorkspace contents to theMetaData”. Que ens servirà per tal d’actualitzar les metadades.

Tot seguit s’inicia un procés que dura uns segons apareixent una advertència. Es selecciona “Si” per passar la informació del GeoWorkspace a la base de dades de les Metadades.

A continuació es selecciona el primer botó “Map Content”. On s’observa tot el que es publicarà al servei WMS.

Figura 11: Selecció del botó Map Content

Observar amb precisió que la informació que apareixerà a la Llegenda es correspon amb el que realment es vol i que per tant aquesta informació és visible (prestant atenció als temàtics- Població Exclosa).

En aquest cas, els temàtics tal i com s’observa apareixen correctament (forns de pa amb cadascuna de les divisions segons la població exclosa).

Figura 12: Verificació de la correcte creació dels temàtics

A continuació es selecciona el 2on botó “Settings”. Aquí es realitzarà la comprovació que realment hi ha un sistema de coordenades assignat.

Figura 13: Tria de l’opció Settings dins el GeomediaWebMap

En el cas que no hi sigui serà necessari escollir un sistema de coordenades per a publicar les dades. Es selecciona un arxiu de sistema de coordenades que sigui el mateix que el del GeoWorkspace. Finalment, i un cop triat, apareixerà el sistema de coordenades que s’ha triat a l’apartat SRS.

Figura 14: tria del sistema de coordenades

Per últim, polsar l’últim botó per tancar el “GeomediaWebMap Publisher Administrator”.

Finalment, es torna a obrir el “Server ConfigurationUtility” del GeoMediaWebMap Professional, es selecciona el servei creat i es polsa sobre el botó “Initialize”. Així s’inicialitzarà el servei.

Figura 15: Publisher Server Configuration Utility

Si el procediment s’ha realitzar correctament apareixerà un missatge de “Servei inicialitzat amb èxit”. I per tant s’haurà dut a terme correctament el procediment de publicació.

Figura 16: Procediment final de publicació

A continuació es prova el servei des del navegador introduint la següent línia de comanda:

http://geoportalccu.tecnocampus.cat/wmsAE3/request.aspxservice=wms&request=
getcapabilities

On es comprova el correcte funcionament en el cas de WMS, i on es veu en el codi cadascuna de les consultes realitzades com també les diverses dades publicades (aquesta línia de comanda és diferent pel tipus de publicació que es vulgui realitzar, si és WFS o WMS)

Finalment, per acabar el procés de publicació s’accedeix al Global Mapper i es van introduint cadascuna de les consultes creades per observar com totes les entitats es poden visualitzar correctament al mapa.

Un cop iniciat el Global Mapper seleccionem l’opció “Download Online Data”.

Figura 17: Download Online Data del Global Mapper v14

Tot seguit seleccionem “Add New Source”. Per tal d’introduir el nou servei que s’ha creat anteriorment. I es tria l’opció de dades que en aquest cas és WMS (Web Map Service).

Figura 18: Tria del servei creat al Global Mapper

Es selecciona el següent URL, extret de la verificació de la comanda anterior per internet. I s’acciona el botó “Get List of Available Data Layers”, on apareixeran les diverses entitats.

http://geoportalccu.tecnocampus.cat/wmsAE2/request.aspx

Figura 19: Tria i càrrega de les entitats a visualitzar al mapa

Es tria una d’elles per tal d’observar-la al mapa i s’acciona “connect” per realitzar la visualització.

Finalment i després d’anar realitzant totes les connexions amb les diverses entitats, aquestes haurien de ser visibles alhora al mapa. A continuació-Figura 20 es mostren diverses d’aquestes consultes visualitzades conjuntament (tant el nombre d’entitats, la zona d’influència  i la població exclosa per cadascuna de les consultes) observant d’aquesta forma com la publicació de tots casos ha estat un èxit i ha finalitzat satisfactòriament.

Figura 20: Visualització completa de les entitats al Global Mapper v14

En resum, aquest és el procediment que s’ha dut a terme per tal de realitzar la publicació via WMS  mostrant les eines utilitzades en cada etapa.  Es comença per la creació de les consultes sobre les Activitats Econòmiques seguint l’aplicatiu amb diverses zones d’influència tant per distància com per temps. Es segueix amb el procés de creació del servei i publicació en si mitjançant el GeomediaWebMap Professional. I per últim, la validació de les diverses entitats publicades mitjançant el GlobalMapper.

 

 

 

 

 

 

 

 

 

 

 

Nou concepte de Zones d’Influència lligat als desplaçaments de la població

 

Tots els Sistemes d’Informació Geogràfica (SIG) tenen el concepte de Zona d’Influència, normalment anomenat ‘buffer’, que consisteix en agafar una classe d’entitat (taula d’entitats) i generar en el seu entorn una àrea que amplia la frontera de les entitats una certa distància i respon a la idea de zona d’influència o zona de proximitat o de veïnatge.

Per tant si la classe d’entitat de la que volem definir el ‘buffer’ és una àrea, tal com hem dit, el seu ‘buffer’ és una altra àrea que comprèn l’entitat i té més o menys la mateixa forma, però si la classe d’entitat és lineal el seu ‘buffer’ és una àrea de tipus rectangular que pot estar arrodonida en els extrems  i si la classe d’entitat és puntual el seu ‘buffer’ és una àrea de tipus circular.

Un paràmetre característic de les zones d’influència és el ‘radi’ o distància, en realitat el concepte més adequat és el de distància ja que ens indica a quina distància de l’entitat base es troba el límit de la seva zona d’influència, però que en el cas d’entitats  puntuals, com que la zona d’influència és circular, sí que coincideix amb el radi d’aquest cercle.

Fig 1: Zones d’Influència sobre les Zones Verdes a una distància de 50 m.

A la figura 1 podem veure un exemple de les zones d’influència sobre entitats tipus àrea, com és el cas de les zones verdes accessibles de la ciutat de Mataró, en aquest cas s’ha considerat una distància fixa de 50 metres. Això podria tenir un sentit de comptar , per exemple, quants ciutadans viuen a menys de 50 metres d’una zona verda.

Un altre cas molt comú d’utilització de les zones d’influència seria veure quants ciutadans estan a més d’una determinada distància d’un centre proveïdor de serveis, com un Centre d’Assistència Primària (CAP) o un centre docent o un centre cívic, en aquest cas són molt útils els ‘buffers’ a l’entorn d’aquestes entitats, que normalment són representades com a entitats puntuals i per tant les seves zones d’influència seran circulars. Això ho podem veure a la figura 2 pel cas d’Escoles Bressol Municipals de la ciutat de Mataró.

Fig 2: Zones d’Influència a l’entorn de Escoles Bressol Municipals a 250 m

En aquesta figura es veuen els típics cercles que corresponen a les zones d’influència de les entitats puntuals i que podrien servir, tal com hem dit, per veure quanta població està a menys de 250 metres d’una Escola Bressol Municipal i quanta a més, per exemple.

Aquesta característica de dibuixar ‘buffers’ a l’entorn d’entitats és molt utilitzada en SIG quan es volen fer operacions espacials, com ara unió, intersecció, combinacions analítiques, agregacions etc. En el cas de les Escoles Bressol, es pot fer una agregació de tota la població (o dels infants entre 0 i 2 anys) que hi ha  dins de cada zona d’influència a partir de les dades que tenim prèviament agrupades per Illes de cases, parcel·les o portals, tal com s’ha descrit en un altre ‘post’ en aquest mateix bloc, indicant que es sumen tots els habitants que pertanyen a les entitats (siguin aquestes Illes, parcel·les o portals) que estan contingudes dins de la zona d’influència corresponent.

De totes maneres, en totes les operacions que tenen a veure amb la població i amb els seus desplaçaments per la ciutat, aquesta mesura de la proximitat directe que ens proporciona el ‘buffer’ dels SIG no sempre ens és útil, ja que si volem dir ‘nens que hi ha a menys de 250 m de l’Escola Bressol’ aquest concepte de ‘buffer’ ens mostra els nens que viuen  a menys de 250 m, però en línia recta, ja que és el radi de la zona d’influència. El que seria més real seria indicar els nens que hi ha a 250 m seguint la xarxa de carrers, comptant que els nens aniran a l’escola circulant pel carrer. També seria útil considerar en comptes de distància, el seu equivalent en temps, nens que hi ha a menys de 5 minuts del centre, i en aquest cas tenint en compte les facilitats o inconvenients que presenten els carrers, pendents, obstacles ,escales etc.

Això ens ha de portar a definir una nova zona d’influència lligada a la xarxa de trams de carrer (anomenem tram el segment de carrer entre cruïlla i cruïlla). En primer lloc considerarem la xarxa com a una entitat lineal arborescent que creix a partir de l’entitat puntual origen (en aquest cas serien les Escoles Bressol). Vegeu la figura 3

Fig 3. Graf de Trams de Carrer a partir de les Escoles Bressol fins a 250 m de distància

Efectivament  a la figura es poden veure els recorreguts a partir de l’entitat origen que faria un vianant anant en qualsevol direcció (sense passar dues vegades pel mateix lloc) i recorrent un màxim de 250 metres. Com es pot veure els possibles recorreguts depenen de la morfologia de la xarxa de carrers en cada lloc de la ciutat, a part de la pròpia distància a recòrrer. En aquest cas el sentit de distància és molt més real que considerant les zones d’influència clàssiques amb distància a vista d’ocell.

Com que volem tenir una zona d’influència amb les mateixes característiques que la definida de forma clàssica, hem de convertir aquest conjunt de trams en un àrea, agafant precisament un ‘buffer’ sobre aquesta entitat lineal (abans hem hagut de convertir el conjunt de trams en una entitat lineal única)

Fig 4. Zones d’Influència sobre el Graf de Trams de Carrer, distància 250 m

A la figura 4 es pot veure l’efecte d’agafar un ‘buffer’ sobre cada conjunt de trams desplegats a 250 m de la seva entitat origen. Aquest ‘buffer’ s’agafa a 20 m de les línies del graf de trams.

D’aquesta manera es poden continuar aplicant les operacions espacials que ens calguin pels nostres càlculs com si fossin àrees circulars, però amb l’avantatge d’uns resultats molt més realistes quan treballem amb població i distàncies.

 

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.

Polígons de Voronoi

En aquest article es descriurà el funcionament dels polígons de Voronoi, una eina molt important a l’hora d’estudiar àrees d’influència.

Els polígons de Voronoi es basen en la distància euclidiana, i són molt apropiats quan les dades són qualitatives. Es tracta de fer una partició del pla, a partir d’uns punts que anomenarem punts generadors.

Aquesta partició del pla en regions té la peculiaritat de que des de qualsevol punt de dins d’una regió determinada, la distància al punt generador corresponent és sempre menor que la distància a qualsevol altre punt generador extern. Per tant, les fronteres de les regions són equidistants de dos o mes punts generadors.

Inicialment, aquest polígons van ser creats per l’anàlisi de dades meteorològiques, però avui en dia s’utilitzen també per determinar zones d’influència, que és el que s’explicarà en aquest article.

Els polígons de Voronoi serveixen per dividir un espai en un número determinat de regions. S’especifiquen un conjunt de punts (punts generadors) i quan es fa el diagrama, aquests queden dividits pels polígons, un punt en cada regió. Les regions s’anomenen cel·les o polígons de Voronoi.

Cada polígon correspon a l’àrea d’influència, per dir-ho d’alguna manera, del punt  que conté.

Primerament, crec que és interessant posar un exemple per entendre millor per a què serveixen els polígons:

Suposem el cas de que s s’està estudiant els centres d’atenció primària (CAP) del terme municipal de Mataró, i es vol construir un altre i no se sap on. Gràcies a les zones d’influència creades mitjançant els polígons de Voronoi, es podrà situar més o menys el nou CAP.

El programa que s’ha utilitzat, a més del Geomedia, ha sigut el Global Mapper.

Global Mapper és una potent aplicació que combina eines de tractament de dades espacials amb un accés a gran varietat de formats d’arxius. És molt útil com a complement del Geomedia.

Amb el Geomedia s’han exportat els caps com una única entitat, i el contorn de Mataró s’ha aconseguit agafant el perfil de la unió de totes les illes que formen Mataró.

Terme municipal amb els CAPS

Tots els arxius exportats són de tipus ShapeFile, per tal de que Global Mapper els reconegui i es pugui treballar amb ells.

Un cop es té el terme municipal de Mataró amb els CAPS, és hora de passar a l’acció, el procés és simple, i el resultat és molt satisfactori.

Primerament es selecciona tot i es crea el diagrama de Voronoi des del menú d’anàlisi.

Apareixerà una finestra en la que s’haurà d’indicar que es volen allargar els límits uns 4000 metres, això permetrà que, en cas de que el diagrama no arribi a tocar el perímetre de Mataró, aquest s’allargui fins a tocar-lo.

Allargar límits

Un cop allargats, només cal dir que el límit fins on s’allarguen els polígons és l’àrea contenidora, és a dir, el terme municipal de Mataró. Això es configura a partir del botó “Bounds” i seleccionant l’última opció. Per últim s’accepta per crear els polígons.

Limitar polígons

La imatge de Mataró amb els seus CAPS quedaria dividida pels polígons de Voronoi, hi hauria una cel·la per cada CAP.

Aquests polígons resultants, permeten veure l’àrea d’influència de cada CAP.

Polígons creats

Observant la imatge, es pot veure les divisions que corresponen a cada CAP, hi ha una concentració més elevada al centre urbà, degut a que la població és notablement més elevada.

El CAP de dalt a la dreta, el de Rocafonda-Palau, té molta zona d’influència, això és perquè la zona Nord de Mataró no està tant urbanitzada com la resta.

Segons la població, i el número de places de cada CAP, fent ús dels diagrames de Voronoi, es podria situar un futur CAP.