Desarrollo de una aplicación web basada en el módulo ZI_GTC

En este post se trata el proceso de creación de una aplicación web que está basada en el módulo “Càlcul de Zona d’Influència (Graf de Trams de Carrer)” (ZI_GTC) para QGIS. El trabajo realizado por Ignasi Argemí Puig y Josep López Xarbau en la adaptación web del módulo CTE ha servido como base teórico-práctica para el desarrollo de la nueva aplicación. Para obtener más información sobre esta otra aplicación se puede consultar el post “Desenvolupament d’un mòdul en un entorn web”.

Debido a que con el módulo CTE se había conseguido un resultado satisfactorio, el equipo del CCU decidió utilizarlo como punto de partida para poder desarrollar nuevos plugins cuya funcionalidad fuese relativamente fácil de portear al entorno web.

El objetivo del ZI_GTC es calcular la zona de influencia (en distancia o en tiempo) de las entidades que el usuario desee con una dispersión que se adapta a la forma del grafo que conforman todas las calles Mataró.

Estructura interna

La estructura del programa y el diagrama de flujo de la transmisión de información es exactamente igual a la del CTE (Fig 1).

Fig 1. Diagrama de flujo de la transmisión de información (Fuente: Ignasi Argemí Puig)

En el front-end estarán el HTML y CSS, los cuales se encargan de la estructura y el estilo de la página web; mientras que el funcionamiento interno de la página en el cliente estará gestionado por Javascript y AJAX que, además, serán los encargados de realizar las peticiones al servidor web cuando sea necesario.

En el back-end está el servidor web en el cual se almacena la página web y que se comunica con un PHP que se conecta con el servidor de datos de Postgres en el cual está la base de datos del CCU. Finalmente, para poder devolver el resultado al front-end se utiliza un formato de intercambio de datos que deriva JSON: GeoJSON.

Desarrollo

Se comenzó a trabajar sobre una copia de la aplicación del CTE y lo primero que se hizo fue modificar el HTML para dotarlo de los campos necesarios que necesitaba el ZI_GTC (Fig 2) e ir empezando a hacer pruebas conceptuales. Se tuvo en cuenta el diseño de la interface del CTE para que hubiera una coherencia estética entre ellos.

Fig 2. Apariencia del formulario de la aplicación

Se optó por hacer una versión reducida del plugin de QGIS (Fig 3). Una de las funcionalidades importantes que se ha decidido omitir es la que implica el método de trabajo con la población. Esta decisión tiene que ver con la complicación que supondría tener que pedirle al usuario una “Taula Resum”, las cuales a día de hoy sólo se generan en QGIS.

Fig 3. Módulo ZI_GTC de QGIS

El siguiente paso fue adaptar el Javascript a la nueva funcionalidad, es decir, se introdujo la gestión de la información (enviada y recibida) y la lógica interna de la selección de un coste u otro para después poder lanzarle la información a PHP. En un primer momento quedó pendiente resolver la recepción del GeoJSON ya que no se tenía muy claro cómo se llevaría a cabo en el caso de este plugin.

Finalmente se tradujo la funcionalidad básica del módulo de QGIS a PHP, el cual estaba escrito en Python. La mayor parte del trabajo estaba hecho ya que el módulo ZI_GTC trabaja realizando operaciones sobre el servidor. Sin embargo, puesto que no se tenían conocimientos previos de PHP, esta parte supuso un reto debido a determinados cambios de sintaxis, del planteamineto y la dificultad añadida que supone debugar en PHP. Fue necesario modificar varias consultas SQL y hacer un procedimiento específico para poder enviarle el GeoJSON de vuelta al Javascript. El siguiente paso fue volver a editar el Javascript para interpretar el GeoJSON y representarlo el resultado en pantalla.

Fig 4. Ejemplo de resultado del ZI_GTC web tras calcular el área de influencia de 150m de los IES de Mataró

Llegados a este punto la aplicación estaba prácticamente terminada. En un primer momento el resultado mostrado en pantalla no tenía la forma deseada a pesar de mostrar las zonas correctas. Este error (fundamentalmente visual) se debía a una consulta SQL que fue necesario localizar y modificar.

Para terminar, se añadieron marcadores a cada una de las zonas para que el usuario pudiera consultar su nombre con un simple click (Fig 5).

Fig 5. Ejemplo de resultado del ZI_GTC web, mostrando el nombre de una entidad.

Publicación

La aplicación ya se encuentra disponible en Internet. Se puede probar en http://geoportalccu.tecnocampus.cat/ZI_GTC/ZI_GTC.html, preferiblemente utilizando Google Chrome o Mozilla Firefox.

Implementación de las funcionalidades QGIS3 para realizar el cálculo local en el módulo CTE

En este post se mostrará el proceso de implementación de las nuevas funcionalidades que trae consigo la versión 3 de QGIS, las cuales permiten realizar operaciones complejas ejecutando simplemente un algoritmo. En este caso, se tomará como ejemplo el módulo CTE. Este módulo permite obtener los trayectos o caminos entre una dirección de Mataró y las N entidades más próximas.

Utilización manual de los algoritmos

En primer lugar, se debe habilitar el paquete de “Processing” en el caso de que no esté activado. Para ello se deberá ir a “Complementos” -> “Administrar e instalar complementos…” (Fig. 1).

Fig 1. Habilitar paquete “Processing”.

Tras haberlo habilitado aparecerá una nueva pestaña llamada “Procesos”, en la cual se deberá seleccionar “Caja de herramientas” para que se muestren en pantalla todos los algoritmos disponibles. Dicho elemento aparecerá en una barra lateral dentro de QGIS.

A continuación se debe probar si el algoritmo que se utilizará genera el resultado deseado. En el caso del CTE, el algoritmo que potencialmente puede interesarnos es el denominado “Ruta más corta (punto a capa)”, el cual se encuentra en la sección de análisis de redes (Fig. 2).

Fig 2. Caja de herramientas de procesos.

Dicho algoritmo necesita la capa vectorial que representa la red (en nuestro caso SegmentsXarxaCarrers), un punto de inicio y una capa vectorial con los puntos finales. Para realizar las pruebas se utilizarán (de forma totalmente arbitraria) un punto cualquiera del mapa de Mataró como punto de inicio y los IES como puntos finales. Por tanto, se deberán cargar en QGIS tanto SegmentsXarxaCarrers como los IES (Fig. 3).

Fig 3. Importación de los IES y SegmentsXarxaCarrers.

Abrimos el algoritmo, seleccionamos nuestra red, punto de inicio, puntos finales y el resto de los valores los dejaremos por defecto (Fig. 4). Acto seguido, ejecutamos.

Fig 4. Algoritmo “Ruta más corta (punto a capa)”.

Una vez haya finalizado la ejecución el algoritmo, se añadirá automáticamente el resultado a la leyenda (Fig. 5). Desde el punto arbitrario que se ha escogido en este caso particular el resultado sería el siguiente, en el cual se puede apreciar que produce el resultado deseado (buscar la ruta más corta a cada entidad).

Fig 5. Resultado del algoritmo (rutas más cortas).

Inclusión de los algoritmos en el código

Para poder utilizar los algoritmos proporcionados por QGIS e incluirlos en el módulo, será necesario realizar un “import processing” en el código para poder ejecutar la función “processing.run()”, la cual se encargará de ejecutar el algoritmo deseado. Dentro de esta función se le deberá indicar el ID del algoritmo que se vaya a utilizar y los parámetros que se le pasarán.

Para saber cuál es el ID del algoritmo, simplemente con poner el cursor sobre él nos aparecerá su nombre (Fig. 6).

Fig 6. ID del algoritmo.

Por otra parte, para saber qué tipos admite cada uno de los parámetros (y más información sobre el funcionamiento general del algoritmo) podemos usar la consola de QGIS e introducir el comando “processing.algorithmHelp(“native:shortestpathpointtolayer”)”.

En este módulo se ha querido preservar el cálculo que se realiza en el servidor mediante consultas SQL. Para poder mantener ambas opciones se ha optado simplemente por añadir un checkbox el cual propiciará que el módulo se ejecute en local si se ha marcado y, contrariamente, se ejecutará en el servidor cuando esté desmarcado (Fig. 7).

Fig 7. Checkbox de cálculo local en el módulo CTE.

Por tanto, en el código del módulo se ha escrito la siguiente función, la cual se encarga de ejecutar el algoritmo.

def calculo_Local(self,network_lyr,start_point,end_lyr):
    parameters={'INPUT':network_lyr,
                'STRATEGY':0,
                'DIRECTION_FIELD:'',
                'VALUE_FORWARD:'',
                'VALUE_BACKWARD:'',
                'VALUE_BOTH:'',
                'DEFAULT_DIRECTION':2,
                'SPEED_FIELD':'',
                'DEFAULT_SPEED':1,
                'TOLERANCE':0,
                'START_POINT':start_point,
                'END_POINTS':end_layer,
                'OUTPUT':'memory:'}
    return.processing.run('native:shortestpathpointtolayer',parameters)

A esta función se le pasan los siguientes parámetros:

  • network_lyr: es la capa vectorial que representa la red.
  • start_point: es el punto de inicio elegido por el usuario, es decir, la dirección que haya introducido.
  • end_lyr: es la capa vectorial que representa los puntos finales, es decir, las entidades que haya elegido el usuario.

El resto de parámetros son los que anteriormente se usaban por defecto y, teniendo en cuenta el uso que tiene este algoritmo en el módulo, nos interesa que sean esos valores fijos.

En el módulo CTE lo que se busca es mostrarle al usuario los N caminos más cortos, siendo N un número definido por el propio usuario. El algoritmo genera las rutas más cortas de todas las entidades por lo que, tras haber utilizado el algoritmo, se deberá realizar un filtrado de los caminos que tengan un menor coste según el número de entidades establecido por el usuario.

A partir de este punto, se representará el resultado utilizando el mismo código empleado cuando se realiza el cálculo en el servidor.

Cálculo por distancia/tiempo

El algoritmo utilizado, “Ruta más corta (punto a capa)”, puede funcionar definiendo el coste por distancia o por tiempo. Para realizar el cálculo utilizando la distancia lo que hará es comparar la longitud de los segmentos, mientras que por tiempo tomará el valor que le indiquemos de un campo en concreto o bien asignará una velocidad predeterminada.

En el caso del módulo CTE no representa ningún problema realizar el cálculo por distancia. Sin embargo, si se quisiera hacer el cálculo por tiempo, en la base de datos está definido un coste distinto dependiendo del sentido debido a que no se tarda el mismo tiempo en subir una pendiente que en bajarla. Desafortunadamente, este algoritmo está pensado para asignar una única velocidad para cada segmento sin tener en cuenta el sentido. Por tanto, todo lo que se ha descrito previamente sólo sirve para el caso de la distancia ya que en la actualidad este algoritmo no soporta esta dualidad de velocidades.

Diferencias rendimiento (ventajas/inconvenientes)

Las diferencias de rendimiento entre el cálculo en el servidor y la nueva opción de cálculo local varían en función de lo concurrido que esté el servidor en ese momento y del ordenador del cliente.

A continuación se muestra el tiempo que ha tardado el módulo en calcular cada uno de los destinos en servidor y local en unas pruebas de testeo.

Fig 8. Resultados del testeo. Eje X: puntos finales. Eje Y: tiempo de ejecución.

Tal y como se puede apreciar en el gráfico (Fig. 8), en el caso del cálculo en el servidor el tiempo de proceso aumenta de forma proporcional a la cantidad de entidades de destino que tiene que calcular. Por otra parte, el tiempo que tarda el cálculo local es sumamente sólido, siendo prácticamente una constante. Se tarda el mismo tiempo en calcular 4 destinos (CasalsAvisOficial) que 144 (ParadesBus).

Debido a que el cálculo local presenta una duración más estable, que de media tarda 5 segundos (mientras que el cálculo en el servidor tarda de media 7,9 segundos) y que libera carga en el servidor, esta nueva forma de realizar los cálculos representa una mejora en el módulo CTE y, por norma general, al usuario le interesará ejecutar este módulo marcando el cálculo local.

 

Cálculo en el servidor de los caminos más cortos en el módulo CTE

En este post se explicará cómo se realiza el cálculo en el servidor en el módulo CTE, el cual permite obtener los trayectos o caminos entre una dirección de Mataró y las N entidades más próximas.

Este cálculo se divide en 2 fases: cálculo de los caminos más cortos y la selección de los segmentos finales. Esto es debido a que la función pgr_withPointsKSP  (la cual se utiliza para calcular los caminos más cortos) tiene asociado el problema de que devuelve los caminos del grafo de nodo a nodo, no teniendo en cuenta que en la mayor parte de los casos tanto el punto de inicio como los finales estarán situados en un punto intermedio de un segmento (una arista). Para obtener más información sobre este tema se puede consultar el post “Cobertura mitjançant el graf de trams de carrers (GTC)” de Josep López Xarbau.

Cálculo de los caminos más cortos

En esta primera fase se utiliza la función de PGRouting, pgr_withPointsKSP. Esta función busca los N caminos más cortos utilizando el algoritmo de Yen.

Todo el código que se presentará a continuación pertenece al módulo CTE, el cual está programado en Python y se comunica con la base de datos de Postgres.

En primer lugar lo que nos interesa realizar es unir todos los puntos involucrados (tanto los de destino como el de origen) en una misma tabla para poder prepararlos para la función pgr_withPointsKSP.

De este modo, primero se borra y se crea una nueva tabla para guardar dichos puntos.

drop = 'DROP TABLE IF EXISTS NecessaryPoints_'+Fitxer+';'
try:
    cur.execute(drop)
    conn.commit()
except:
    print ("DROP TABLE ERROR 1")
create = 'CREATE TABLE NecessaryPoints_'+Fitxer+' (\n'
create += "\tpid serial primary key,\n"
create += "\tthe_geom geometry,\n"
create += "\tentitatID int8,\n"
create += "\tedge_id BIGINT,\n"
create += "\tfraction FLOAT,\n"
create += "\tnewPoint geometry);"
try:
    cur.execute(create)
    conn.commit()
except:
    print ("CREATE TABLE NecessaryPoints ERROR")

Acto seguido, se añaden los puntos a la tabla.

insert = 'INSERT INTO NecessaryPoints_'+Fitxer
insert += ' (entitatID,the_geom) (SELECT 0, ST_Centroid("geom") the_geom from "dintreilla"'
insert += ' WHERE "Carrer_Num_Bis" = \''+CNB+'\');\n'

insert += 'INSERT INTO NecessaryPoints_'+Fitxer
insert += ' (entitatID, the_geom) (SELECT "id", ST_Centroid("geom") the_geom FROM"'
insert += self.dlg.comboCapaDesti.currentText() + '" ORDER BY "id");'
try:
    cur.execute(insert)
    conn.commit()
except:
    print ("Insert Points NecessaryPoints ERROR")

Después se añade el id del tramo más próximo a cada punto, los puntos proyectados sobre el grafo y la fracción de segmento en la que se encuentran.

update = 'UPDATE NecessaryPoints_'+Fitxer
update += ' SET "edge_id"=tram_proper."tram_id"'
update += ' FROM (SELECT distinct on(Poi."pid") Poi."pid" AS Punt_id,Sg."id" AS Tram_id,'
update += ' ST_Distance(Sg."the_geom",Poi."the_geom") AS dist '
update += 'FROM "Xarxa_Prova" as Sg,NecessaryPoints_'+Fitxer+' AS Poi '
update += 'ORDER BY Poi."pid",ST_Distance(Sg."the_geom",Poi."the_geom"),Sg."id") tram_proper'
update += ' WHERE NecessaryPoints_'+Fitxer+'."pid"=tram_proper."punt_id";\n'

update += 'UPDATE NecessaryPoints_'+Fitxer
update += ' SET fraction = ST_LineLocatePoint(e.the_geom, NecessaryPoints_'+Fitxer+'.the_geom),'
update += 'newPoint = ST_LineInterpolatePoint(e."the_geom",'
update += ' ST_LineLocatePoint(e."the_geom", NecessaryPoints_'+Fitxer+'."the_geom"))'
update += ' FROM "Xarxa_Prova" AS e WHERE NecessaryPoints_'+Fitxer+'."edge_id" = e."id";\n'
try:
    cur.execute(update)
    conn.commit()
except:
    print ("Update Points NecessaryPoints ERROR")

Ahora ya está todo preparado para poder realizar el cálculo. Se hace una consulta para poder generar una sentencia SQL que haga la búsqueda de todos los caminos más cortos a todos los puntos necesarios y después se añaden a una tabla llamada “Resultat”.

select = 'select * from NecessaryPoints_'+Fitxer+' order by pid'
cur.execute(select)
vec = cur.fetchall() 
create = 'create local temp table "Resultat" as SELECT * FROM (\n'
for x in range (0,len(vec)):
    if x < len(vec) and x >= 2:
        create += 'UNION\n'
    if x != 0:
        if vec[x][4] == 1.0 or vec[x][4] == 0.0:
            create +='select '+ str(x) +' AS routeID,'+ str(vec[x][2])
            create +=' AS entitatID, * FROM pgr_withPointsKSP'
            create +='(\'SELECT id, source, target, cost, reverse_cost '
            create +='FROM "Xarxa_Prova" ORDER BY id\','
            create +='\'SELECT pid, edge_id, fraction FROM NecessaryPoints_'
            create +=Fitxer+'\',-1,' + str(vec[x][2])+',1)\n'
        else:
            create += 'select '+ str(x) +' AS routeID,'+ str(vec[x][2])
            create +=' AS entitatID, * FROM pgr_withPointsKSP'
            create +='(\'SELECT id, source, target, cost, reverse_cost '
            create +='FROM "Xarxa_Prova" ORDER BY id\','
            create +='\'SELECT pid, edge_id, fraction FROM NecessaryPoints_'
            create +=Fitxer+'\',-1,-' + str(vec[x][0]) +',1)\n'
create += ')QW ORDER BY routeID, seq;'

drop = 'DROP TABLE IF EXISTS "Resultat";'
try:
    cur.execute(drop)
    conn.commit()
except:
    print ("DROP TABLE ERROR 2")

try:
    cur.execute(create)
    conn.commit()
except:
    print ("CREATE TABLE Resultat global ERROR")

A continuación se deberá solucionar el problema que se ha comentado en la introducción del post, es decir, se seleccionarán los segmentos que son inicio y final para añadirlos al resultado final.

Selección de los segmentos finales

Lo primero que se debe hacer es borrar y crear la tabla “Segments finals”, en la cual figurarán todos los caminos posibles que son principio y/o final.

drop = "DROP TABLE IF EXISTS \"SegmentsFinals\";"
try:
    cur.execute(drop)
    conn.commit()
except:
    print ("DROP TABLE ERROR 1")

create = "CREATE local temp TABLE \"SegmentsFinals\" (\n"
create += "\trouteid int8,\n"
create += "\tedge int8,\n"
create += "\t\"edgeAnt\" int8,\n"
create += "\tfraction FLOAT,\n"
create += "\t\"ordreTram\" int8,\n"
create += "\t\"cutEdge\" geometry);"
try:
    cur.execute(create)
    conn.commit()
except:
    print ("CREATE TABLE SegmentsFinals ERROR")

Después se realiza una consulta que determinará qué segmentos son inicio y final.

select = 'SELECT routeid, node, edge FROM "Resultat" ORDER BY routeid, path_seq;'
try:
    cur.execute(select)
    vec = cur.fetchall()
    conn.commit()
except:
    print ("SELECT Resultat ERROR")

insert = ''
for x in range (len(vec)):
    if vec[x][1] < 0:
        if vec[x][1] != -1:
            insert +='INSERT INTO "SegmentsFinals" (routeid, edge, "edgeAnt", "ordreTram") '
            insert +='VALUES (' + str(vec[x][0]) + ', ' + str(vec[x-1][2]) + ', '
            insert +=str(vec[x-2][2]) + ', ' + str(2) +');\n'
        else:
            insert +='INSERT INTO "SegmentsFinals" (routeid, edge, "edgeAnt", "ordreTram") '
            insert +=VALUES (' + str(vec[x][0]) + ', ' + str(vec[x][2]) + ', '
            insert +=str(vec[x+1][2]) + ', ' + str(1) + ');\n'
try:
    cur.execute(insert)
    conn.commit()
except:
    print ("INSERT TABLE SegmentsFinals ERROR")

Se realiza un UPDATE para poder añadir la fracción de segmento en la cual se encuentra el punto.

select = 'SELECT routeid, edge, "ordreTram" FROM "SegmentsFinals" ORDER BY routeid, "ordreTram";'
try:
    cur.execute(select)
    vec = cur.fetchall()
    conn.commit()
except:
    print ("SELECT SegmentsFinals ERROR")

update = ''
for x in range(len(vec)):
    ruta = vec[x][0]
    edge = vec[x][1]
    ordre = vec[x][2]
    if ordre == 1:
        update +='UPDATE "SegmentsFinals" s SET fraction = n.fraction FROM NecessaryPoints_'
        update +=Fitxer+' n where n.edge_id = '+str(edge)+' AND s.edge ='+str(edge)
        update +=' AND s."ordreTram" = 1 AND s.routeid = '+str(ruta)+' AND n.entitatid = 0;\n'
    else:
        update +='UPDATE "SegmentsFinals" s SET fraction = n.fraction FROM NecessaryPoints_'
        update +=Fitxer+' n where n.edge_id = '+str(edge)+' AND s.edge ='+str(edge)
        update +=' AND s."ordreTram" = 2 and s.routeid = '+str(ruta)
        update +=' AND n.pid = '+str(ruta+1)+';\n'

try:
    cur.execute(update)
    conn.commit()
except:
    print ("UPDATE TABLE SegmentsFinals ERROR")

A continuación se realiza una consulta para escoger y añadir el trozo de tramo que corresponde a cada inicio y final. Posteriormente se hace un UPDATE del campo de geometría de la tabla “SegmentsFinals” con los tramos ya recortados.

select = 'SELECT * FROM "SegmentsFinals" ORDER BY routeid;'
try:
    cur.execute(select)
    vec = cur.fetchall()
    conn.commit()
except:
    print ("SELECT SegmentsFinals ERROR")
updateSegment = ''
for x in range(len(vec)):
    ordre = vec[x][4]
    fraction = vec[x][3]
    edgeAnt = vec[x][2]
    edge = vec[x][1]
    selectTouch ='SELECT ST_Touches((SELECT ST_Line_Substring("Xarxa_Prova"."the_geom",0,'
    selectTouch +=str(fraction)+') AS geom FROM "Xarxa_Prova" WHERE"id"='+str(edge)+'),'
    selectTouch +='(SELECT the_geom as geom FROM "Xarxa_Prova" WHERE "id"='+str(edgeAnt)+'));'
    try:
        cur.execute(selectTouch)
        resposta = cur.fetchall()
        conn.commit()
    except:
        print ("SELECT TOUCH ERROR")
    if edgeAnt != -1: 
        if resposta[0][0]:
            updateSegment +='UPDATE"SegmentsFinals" sf SET "cutEdge" = '
            updateSegment +='ST_Line_Substring(s."the_geom",0,'+str(fraction)+') '
            updateSegment +='FROM "Xarxa_Prova" s '
            updateSegmnet +='WHERE sf."edge"='+str(edge)+' AND s."id"='+str(edge)
            updateSegment +=' AND sf."routeid" = '+str(vec[x][0])+';\n'
        else:
            updateSegment +='UPDATE "SegmentsFinals" sf SET "cutEdge" = '
            updateSegment +='ST_Line_Substring(s."the_geom",'+str(fraction)+',1) '
            updateSegment +='FROM "Xarxa_Prova" s '
            updateSegment +='WHERE sf."edge"='+str(edge)+' and s."id"='+str(edge)
            updateSegment +=' and sf."routeid" = '+str(vec[x][0])+';\n'
    else:
        if ordre == 1:
            fractForward = vec[x+1][3]
        else:
            fractForward = vec[x-1][3]
        if fraction >= fractForward:
            updateSegment +='UPDATE "SegmentsFinals" sf SET "cutEdge" = '
            updateSegment +='ST_Line_Substring(s."the_geom",'+str(fractForward)+','
            updateSegment +=str(fraction)+') FROM "Xarxa_Prova" s '
            updateSegment +='WHERE sf."ordreTram" = '+ str(ordre)+' and sf."edge"='
            updateSegment +=str(edge)+' and s."id"='+str(edge)+' and sf."routeid" = '
            updateSegment +=str(vec[x][0])+';\n'
        else:
            updateSegment +='UPDATE "SegmentsFinals" sf SET "cutEdge" = '
            updateSegment +='ST_Line_Substring(s."the_geom",'+str(fraction)+','
            updateSegment +=str(fractForward)+') FROM "Xarxa_Prova" s '
            updateSegment +='WHERE sf."ordreTram" = '+ str(ordre)+' and sf."edge"='
            updateSegment +=str(edge)+' and s."id"='+str(edge)+' and sf."routeid" = '
            updateSegment +=str(vec[x][0])+';\n'

try:
    cur.execute(updateSegment)
    conn.commit()
except:
    print ("UPDATE TABLE SegmentsFinals Geometries ERROR")

Se añade y se actualiza el campo de geometría en la tabla “Resultat”.

alter = 'ALTER TABLE "Resultat" ADD COLUMN newEdge geometry;\n'
alter += 'UPDATE"Resultat" r SET newedge = s.the_geom FROM "Xarxa_Prova" s WHERE s.id = r.edge;'

try:
    cur.execute(alter)
    conn.commit()
except:
    print ("ALTER and UPDATE TABLE Resultat Geometries ERROR")

Acto seguido se actualizan los tramos recortados en la tabla “Resultat”.

update = 'UPDATE "Resultat" r SET newedge = s."cutEdge" FROM "SegmentsFinals" s '
update += 'WHERE s."routeid" = r.routeid AND s.edge = r.edge;'
try:
    cur.execute(update)
    conn.commit()
except:
    print ("ALTER and UPDATE TABLE Resultat Geometries ERROR")

Se seleccionan los N caminos más próximos a la dirección indicada en función del límite introducido por el usuario.

limit = self.getLimit()
select ='SELECT e."'+ nomCamp[0][0] +'" AS NomEntitat, r.agg_cost AS Cost, r.entitatID '
select +='FROM "Resultat" r JOIN "' + self.dlg.comboCapaDesti.currentText()
select += '" e ON r.entitatID = e.id WHERE r.edge = -1 ORDER BY 2 ASC limit ' + str(limit) + ';'
try:
    cur.execute(select)
    vec = cur.fetchall()
    conn.commit()
except:
    print ("SELECT resultats ERROR")

Finalmente se borrará y se creará una tabla para obtener todos los tramos para cada camino óptimo escogido y, al mismo tiempo, se añade la información obtenida en el SELECT anterior.

createTrams = 'DROP TABLE IF EXISTS "TramsNous_'+Fitxer+'";\n'
createTrams += 'CREATE TABLE "TramsNous_'+Fitxer+'" AS SELECT * FROM (\n' 
rowCount = self.dlg.taulaResultat.rowCount()
self.dlg.taulaResultat.setColumnCount(2)
self.dlg.taulaResultat.setHorizontalHeaderLabels(['Entitat', lbl_Cost])
if self.dlg.comboCost.currentText() == 'Distancia':
    rnd = 0
else:
    rnd = 1
for x in range (rowCount,len(vec)):
    self.dlg.taulaResultat.insertRow(x)
    self.dlg.taulaResultat.setItem(x, 0, QTableWidgetItem(str(vec[x][0])))
    self.dlg.taulaResultat.setItem(x, 1, QTableWidgetItem(str(round(vec[x][1],rnd))))
    if x < len(vec) and x >= 1:
        createTrams += 'UNION\n'

    createTrams +='SELECT entitatid, \'' + str(vec[x][0].replace("'","''"))
    createTrams +='\' AS "NomEntitatDesti" ,'+str(round(vec[x][1]))
    createTrams +=' AS agg_cost, ST_Union(newedge) AS the_geom from "Resultat" '
    createTrams +='WHERE entitatid = '+str(vec[x][2])+' GROUP BY entitatid\n'
createTrams += ")total ORDER BY agg_cost ASC;"
QApplication.processEvents()
try:
    cur.execute(createTrams)
    conn.commit()
except:
    print ("create trams ERROR")

A partir de este punto, lo único que quedará por hacer es presentar en pantalla el resultado.

Conclusión

Como conclusión final del post, cabe destacar que este método permite mejorar y refinar el resultado que se obtiene de una de las funciones de la librería pgrouting. De este modo, se ha podido conseguir que al calcular la distancia más corta de uno a varios puntos se obtenga el punto de segmento concreto en el cual se encuentra el inicio o el final, en vez de quedarse simplemente con el nodo más cercano a dichos puntos.

Exemple d’aplicació del mòdul ‘ActualitzaGTC’

Anteriorment l’Ignasi Argemí ja va fer una entrada explicant el funcionament del mòdul ‘Actualitza GTC’ que serveix per facilitar la modificació del GTC, fent una generació, revisió i validació automàtica del graf. Un cop validat la segona part del procés és un ‘batch’ que s’executa diariament en el servidor on es donen valors als atributs necessaris per els ‘encaminaments’ per distància i per temps. Un cop fet això es produeix a l’actualització automàtica del dos fitxers del graf, segments i nodes en el servidor de Postgres.

Ara es veurà un exemple d’aplicació d’aquest mòdul. Suposem que hi ha un GTC, que es vol modificar, s’inicia ‘ActualitzaGTC’, surt el formulari de la figura 1, escollim una connexió i premem el botó ‘CARREGAR GTC’, es demana fixar una contrasenya si és la primera vegada que el volem modificar, o posar la contrasenya ja escollida si ja l’havíem començat a modificar abans.

ActGTC2

Fig. 1. Formulari del mòdul: ActualitzaGTC

Es presenten els segments del graf actual (en realitat una còpia del mateix) i es pot procedir a fer les modificacions que calguin. Ens centrarem en una petita zona del graf. Vegeu la figura 2.

 


 


 


Fig. 2. GTC carregat per modificar. Fem zoom al requadre

Per veure les característiques s’han incorporat també els nodes i les etiquetes identificatives de cada node, també en els segments hi ha indicat a més a més de l’Id del segment el node origen i el node final, representats d’aquesta manera ‘origen/final’. Aquesta informació topològica es pot veure en la figura 3. (Per veure-ho millor cliqueu sobre la figura)

Fig. 3. Zona ampliada del GTC amb informacions de cada capa nodes i segments

Si es mostra la informació del segment 583 tenim el que es veu a la figura 4

Fig. 4. Taula d’atributs inicials del segment 583

Si es fan el canvis desitjats, suposem que la nova topologia queda així, tal com es veu a la figura 5, amb dos segments nous i dos nodes nous

Fig. 5. Nous segments dibuixats amb les eines del QGIS

Un cop fetes les modificacions s’ha de prémer el botó ‘VALIDAR GTC’ i al final si no hi ha errades es veurà el text indicat en la figura 6. Aleshores ja s’han incorporat els segments nous i s’han generat els nusos corresponents.

ActGTC10

Fig. 6. Missatge de GRAF VALIDADAT

Vegeu ara la figura 7 amb les noves etiquetes, allà es pot veure que els segments nous són els que tenen identificadors 3266 i 3264, també hi ha un node nou, el node 5, conseqüència d’haver dividit el segment que inicialment es deia 2266, en dos nous segments anomenats ara 3265 i 2266

Fig. 7. Graf modificat amb les etiquetes de nodes i segments

Ara el nou graf ja està construït nomes falta actualitzar els atributs segons el model de desplaçaments de vianants o de vehicles que s’utilitzi. Això es fa en un procés ‘batch’ un cop cada dia si s’han generats GTC geomètricament diferents. Es mostren ara els atributs dels segments 583 i 3266 en les figures 8 i 9

Fig. 8. Atributs finals del tram 583

 

Fig. 9. Atributs finals del tram 3266

Com es pot  veure els atributs pel segment ja existent són els mateixos, només canvien el nodes inicial i final, fruit de la renumeració, i pel segment nou s’han generat els atributs nous que li corresponen.

D’aquesta manera s’ha pogut veure la facilitat de modificació del GTC que aporta aquest mòdul. La part directa del dibuix depen de les possibilitat d’edició del QGIS, però tota la resta, que consisteix en convertir el nou dibuix en un graf útil des de tots els punts de vista, validació, generació de les dependències entre nodes i segments i actualització dels atributs d’ambdós elements es pot fer de forma senzilla.

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: Actualitza GTC

Aquest document explica el funcionament del mòdul de ‘Actualitza GTC’ per a QGIS. Aquest mòdul permet actualitzar fàcil i automàticament (excepte la part gràfica) la capa del GTC de vianants de la ciutat de Mataró.

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 ActGTC1o anar a Complementos -> CCU -> Actualitza GTC i s’obrirà una finestra com la que podem veure a continuació a la figura 1.

ActGTC2

Fig. 1: Interfície de mòdul

1. Connexió

A la secció superior hi figuren els dos elements de connexió: un desplegable per escollir la que es vol utilitzar i una barra d’estat, com es pot veure a la figura 2.

ActGTC3

Fig. 2: Connexió

2. Carregar

Aquest botó té la funció de carregar a pantalla el GTC que es vol modificar, com es pot veure a la figura 3.

ActGTC4

Fig. 3: Botó de càrrega

Per evitar que dues persones editin el GTC al mateix temps, apareix un diàleg demanant un paraula clau: quan no s’està modificant el GTC, demana una paraula clau per protegir la edició, tal i com es veu a la figura 4.

ActGTC5

Fig. 4: Diàleg d’introducció de la paraula clau

En el cas que ja s’estigui modificant, apareix el següent diàleg per poder accedir a la edició. En ell es demana la paraula clau, tal i com es pot veure a la figura 5.

ActGTC6

Fig. 5: Diàleg de comprovació de la paraula clau

En cas que es compleixin les condicions, el GTC es carrega en el QGIS.

En aquest moment es tracta d’editar els segments del GTC utilitzant les eines d’edició gràfica del QGIS, afegir segments, eliminar segments, canviar interseccions etc. Només hem de treballar amb la capa de segments, i no la de nodes.

ActGTC7

Les eines pròpies del QGIS són les de la figura 6:

Fig. 6: Barra d’eines d’edició gràfica

D’esquerra a dreta les icones fan les següents funcions: el llapis groc serveix per començar o acabar l’edició de la capa. El disquet serveix per guardar els canvis que s’han efectuat. Seguidament, dos icones que serveixen per crear nous trams: el primer permet fer trams rectes i el segons trams corbats. El següent permet moure de lloc les entitats gràfiques, i en aquest cas, segments.

La següent eina permet modificar els nusos dels segments i ajustar-los en les interseccions. La icona del cubell d’escombraries elimina les entitats gràfiques seleccionades. Per últim hi ha les eines que permeten retallar (que no tallar o escurçar), copiar i enganxar entitats gràfiques.

S’ha de tenir present que els segments només es podran tocar entre ells en els punts d’origen o final que serà on es constituiran els nodes del graf, llevat de que siguin trams a diferents nivells, com passos subterranis, passos elevats o similars.

3. Validar

El botó validar s’encarrega de comprovar que els canvis gràfics estiguin fets de manera correcta, com es pot veure a la figura 7. En cas que tot estigui correcta, l’usuari no cal que faci res més. Altrament, en el camp de text s’informa dels possibles problemes. Es mostraran els nusos que presenten problemes, en cas que aquests existeixin i es mostraran els segments aïllats en cas que n’hi hagi.

ActGTC8

Fig. 7: Botó de validació

4. Camp de text

En aquest camp de text es mostra la informació que es deriva de les accions principals del mòdul. Quan es carrega el GTC, es mostra la data i l’hora de creació de la còpia, com es mostra a la figura 8.

ActGTC9

Fig. 8: Informació de càrrega

Quan es prem el botó de validar, mostren les diferents etapes que es passen durant el procés i si hi ha alguna incidència. A la figura 9 es veu un exemple del què es mostra.

ActGTC10

Fig. 9: Informació de validació

5. Versió i botó ‘Sortir’

Per últim en aquesta part, hi ha una etiqueta amb la versió del mòdul i el ‘botó’ sortir per tancar-lo, com es pot veure a la figura 10.

ActGTC11

Fig. 10: Versió i botó ‘Sortir’

Dimoni

A partir d’aquí es procedirà a regenerar el GTC amb els identificadors de segments i nodes i a actualitzar els atributs necessaris per modelitzar els desplaçaments.

Tot això es farà en un procés batch automàtic al final del dia de la correcció, i per tant el dia següent es podrà disposar d’un nou GTC completament operatiu a la base de dades, disponible per ser utilitzat amb el mòduls del CCU per a QGIS.

Filosofia per l’Anàlisi Urbà. Una evolució de les eines del CCU.

Durant tots els anys de la trajectòria del CCU s’ha anat passant per diferents fases, un element inicial clau és la utilització dels Sistemes d’Informació Geogràfica (SIG) per representar entitats urbanes georeferenciables. Aquestes entitats són capaces d’aportar informació rellevant inclús per la comprensió i interpretació de determinats fenòmens socials. Podem concloure que tot element significatiu ubicat en l’entorn urbà és suscep­tible de ser representat en un SIG, des de les canonades de transport d’aigua fins als arbres o les papereres, i en el mateix moment en que representem aquests objectes sobre d’un plànol adquireixen automàticament l’atribut de georeferenciable.

Un inconvenient que té això seria que aquestes entitats han d’estar més o menys ‘fixa­des’ sobre el territori, si volem ampliar encara més aquest concepte de georeferenciable a entitats mòbils o que siguin susceptibles de desplaçar-se d’un punt a un altre  haurem d’introduir el nou concepte de ‘posicionament global  mitjançat satèl·lits’ o sigui GPS, en aquesta fase hi hauria els desplaçament de vehicles, persones o posicionament de ‘contenidors’ o altres objectes susceptibles de ser canviats d’ubicació a la via pública, per exemple. El CCU va ser l’evolució d’un grup de treball en SIG, GPS i terminals portàtils, i  va realitzar en el seu moment un treball de camp sobre les barreres arqui­tectòniques a la la ciutat de Mataró. Avui dia el posicionament d’entitats mòbils forma ja part intrínseca de l’anàlisi urbà de manera que ambdós conceptes SIG i GPS estan absolutament lligats.

Un altre aspecte a tenir en compte serien les eines per a l’anàlisi que s’han anat cons­truint, precisament en aquest punt és on el CCU té el seu sentit, l’anàlisi de les dades ha de permetre convertir informació útil sobre la ciutat en coneixement envers temes com­plexos, com ara distribució de serveis a la població, distribució de l’activitat econòmica de la ciutat, zonificació a partir de temps de desplaçament des de o envers un determinat servei, trajectes a entitats properes, etc.

El CCU s’ha basat en un SIG per a completar-lo amb eines específiques d’anàlisi a de­manda dels tècnics corresponents, aquestes eines eren els anomenats ‘mòduls’ d’anàlisi del CCU. L’entorn inicial escollit fou el SIG  Geomedia Professional un recurs de fàcil aprenentatge i maneig, sobre l’entorn Windows. L’inconvenient era que aquest pro­grama interactuava, en la nostra concepció, amb bases de dades  de tipus local, i l’avantatge  que les BD eren estàndard i d’us majoritari com és el cas de Microsoft Ac­cess. De totes maneres el concepte principal consistia en que s’havia de tenir l’element de càlcul i les dades en el propi ordinador i això portava  dificultats en els aspectes de manteniment de la informació i del propi programari.

Per superar aquests obstacles es va pensar en utilitzar un producte més modern i no as­sociat a un fabricant determinat, més aviat lligat al concepte de Programari Lliure, i que disposés d’una comunitat important d’usuaris que garantissin el seu desenvolupament i continuïtat independentment dels aspectes comercials. Aquesta seria una nova fase en l’evolució de les eines del CCU.

El programari escollit fou el QGIS com a SIG per equips de sobretaula, aquest progra­mari també és l’escollit pel SSIT de l’Ajuntament de Mataró per a molts dels seus des­envolu­paments com ara el ‘Mataró SIG Visor 3.0’ que és un visor a través d’Internet de mapes i d’entitats georeferenciades de la ciutat, en el qual també participa el CCU. A més a més del QGIS,  en aquest projecte també s’utilitza la base de dades PostgreSQL (Postgres), que també és  de lliure distribució.

Durant anys es van fer avenços en la implementació dels Mòduls del CCU (desenvolu­pats en l’entorn Geomedia Professional) mitjançant el QGIS, encara que es tractava més que res d’una translació de funcionalitats, és a dir aconseguir les matei­xes funcionalitats del Geomedia en el nou entorn, però que encara no representava un canvi conceptual important.

El canvi va arribar a l’implementar la filosofia ‘client-servidor’ en la base de dades i en l’actualització automàtica dels mòduls, utilitzant els propis procediments ja previstos en el QGIS.

En aquesta filosofia ‘client-servidor’ cada client des de QGIS es con­necta amb la BD PostgreSQL. I el material es pot consolidar en la mateixa BD si l’usuari té els permisos corresponents.

Tampoc s’executa el codi dels procediments d’anàlisi només en l’equip local. El codi s’executa en part en l’equip local, en el llenguatge Python com és propi del QGIS però també en el servidor utilitzant la potència del llenguatge SQL amb PostGIS per les fun­cions espaci­als del PostgreSQL, per tant el SIG podria quedar reduït a un ‘front-end’ per entrar les dades de la consulta i representar-ne els resultats.

En resum s’hauria passat d’un entorn local a un entorn distribuït, però mantenint la ne­cessitat de disposar d’un programari instal·lat localment, sense costos de llicències, multi plataforma, i amb actualitzacions automàtiques

Una darrera fase en aquesta evolució, en la qual s’hi està treballant en l’actualitat, seria que l’entorn d’entrada i sortida de dades no fora pròpiament un programa SIG amb uns mòduls d’anàlisi, si no un entorn web del tipus del ‘Mataró SIG Visor 3.0’ en aquest cas sí que tot el càlcul es realitzaria en el servidor, i no es requereix cap potència en l’ordinador de l’usuari simplement els recursos estàndard dels navegadors web.

Resumint una mica tot el que ja s’ha exposat, en aquest moment es disposa d’una po­tència de càlcul i d’anàlisi en un entorn QGIS-PostgreSQL amb facilitats de manteni­ment de l’entorn i de les dades, capaç d’arribar a tot el personal tècnic i polític de l’Ajuntament sense costos de llicències i amb un equip de desenvolupament consolidat entre el CCU i el propi SSIT municipal.

L’aplicatiu web seria una altra forma de desenvolupar aquesta mateixa filosofia del QGIS-PostgreSQL, però sense QGIS, les consultes haurien de ser una mica més acota­des però les possibilitat d’anàlisi que té lloc en el servidor serien les mateixes. Això permetria una obertura del sistema al públic en general i tanmateix també es podria en­trar en el mon de les apps per a mòbils

Manual d’ús de l’usuari: Cerca de trajectes a entitats

Aquest document explica el funcionament del mòdul de ‘Cerca de Trajectes a Entitats’ per a QGIS. Aquest mòdul permet obtenir els trajectes o camins entre una adreça qualsevol de Mataró entrada per l’usuari i les N entitats més properes (també escollides per l’usuari). El cost pot estar en funció de la distància o el temps. Els desplaçaments obtinguts es mostren de forma ordenada de menys a més cost en forma de taula i de capa. 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 CTE2o anar a Complementos -> CCU -> Cerca de Trajectes a Entitats i s’obrirà una finestra com la que podem veure a continuació a la figura 1.

CTE1

Figura 1: Imatge de l’estat inicial del mòdul CTE

Aquest mòdul es pot dividir bàsicament en tres parts diferenciades: origen (1) , destí (2), connexió i botons (3).

1. Connexió i altres botons

La primera part a mostrar inclou els botons de funcionament del mòdul (d’esquerra a dreta):

  • Connexió: pestanya desplegable on es mostren totes les connexions.
  • Botó ‘Inici’: aquest botó inicia el procés de consulta del mòdul.
  • Botó ‘Sortir’: aquest botó tanca el mòdul.

CTE5

Figura 2: Connexió i botons

2. Origen

En aquesta part del mòdul l’usuari troba les eines per escollir el punt d’inici, més concretament l’adreça. Seguidament es descriuran les seves parts, començant per la part superior:

CTE3

Figura 3: Origen

El primer element que trobem és una camp de text per cerca el nom del carrer a on es troba l’origen. Inicialment, en el gran requadre inferior, s’hi llisten tots els noms de carrers i a mesura que es va introduint un nom, la llista es va actualitzant automàticament amb els noms que s’assemblen al nom que introdueix l’usuari fins a trobar el desitjat. Una vegada, s’ha trobat el carrer, cal fer doble clic en el nom perquè quedi ben especificat en el camp de text.

Posteriorment, s’ha d’escriure el número del portal que desitgem, juntament amb la lletra. En el cas de la lletra no és necessari escollir-ne una.

Per acabar, a la dreta del camp de text per introduir el nom hi ha un botó amb una creu (X) que permet esborrar el contingut del camp de text.

3. Destí

En aquesta part del mòdul, l’usuari pot escollir la capa de destí i les diferents característiques dels camins: cost, número de camins i aproximació en cas de no existir l’adreça desitjada.

Començant per la part superior, el primer que trobem és una pestanya desplegable on es mostren les diferents capes de punts que poden ser destí. Just a sota hi trobem els modes de cerca. El primer que trobem són dos botons, de color verd i vermell respectivament.

El botó “Més proper” escull l’adreça amb el número de portal més proper a la adreça que s’ha seleccionat, independentment de si és parell o senar, i sempre que l’adreça escollida per l’usuari no existeixi.

En canvi, el botó “Més proper Parell/Senar” escull el portal amb el número senar o parell en funció de quin dels dos tipus sigui el número que s’hagi escollit prèviament, i sobretot que no existeixi.

A la dreta d’aquests dos botons, hi ha una spin box que permet escollir el nombre de camins desitjats, en un rang de 1 a 10 camins. En el cas que el nombre de camins sigui superior al nombre d’entitats d’una capa, el número de camins serà tants com entitats tingui la capa escollida.

Després trobem una pestanya desplegable on es pot triar el cost dels camins: distància o temps. En el cas d’escollir la opció de temps, hi ha un check box que permet incloure en el cost el cost de nusos.

A sota hi ha un gran requadre que s’utilitza per mostrar els resultats de la cerca que s’ha realitzat. La taula que es mostra té dos columnes: la primera mostra el nom de l’entitat de destí i la segona mostra el cost: si és distància en metres i si és en temps en minuts.

Entre la opció del cost i el requadre de resultats hi ha un espai buit que un cop s’ha fet la consulta hi apareix l’adreça de l’origen.

CTE4

Figura 4: Secció de destí

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”.