Coverage using network of streets

Tracing a path through a streets’ network from a starting point to calculate the coverage along the network, it’s likely that this distance does not coincide with a network’s node. It will end at an intermediate point of the final section.

This article presents a way to get coverage from a starting point until it reaches a maximum distance along the streets’ network. The main contribution is the calculation of the last partial segment of every path.

Specifically, this article focuses on how to resolve the problem in obtaining full and partial sections that conform the traveled distance along the network, using the ‘pgr_withPointsDD’ function from the ‘pgrouting’ library. Starting from a node that is outside the graph and is not any of the network nodes.

In order to use the code in this article, you should install the extension ‘pgrouting’ of PostgresSQL, that allows you to analyze networks. More information on (http: //docs.pgrouting. org) and (http://pgrouting.org).

ATTENTION: Next steps will modify the PostgresSQL database. Be careful, otherwise you may harm existing databases.

  • Download database here.
  • Create new database and name it ‘db_temp’.
  • Restore downloaded database.

Once done, you must have 3 entities:

  • “orig_network” (Streets’ network)
  • “origin” (Starting point)
  • “orig_network_vertices_pgr” (network nodes)

In order to understand this process, below is an example based on an orthogonal and symmetrical streets’ network. But can be used in any network you have.

Below is network ‘pep’, every section measures 100 meters, from node to node and the starting point ‘origin’ is painted in red, as you can see in Figure 1.

fig1

Fig 1. Orthogonal network, 100 meters from node to node.

Procedure of calculating coverage using ‘pgrouting’.

In order to calculate a 500 meters coverage from red dot, you must follow the instructions:

  • Duplicate the network and rename it as ‘network’..
  • Create a table named ‘poi_tmp’, which will contain the geometries of the starting points.
  • Modify ‘poi_tmp’ table, adding the fields(x,y,edge_id,side,fraction, newPoint).
DO $$
#variable_conflict use_variable
DECLARE dist_var INT;
BEGIN
dist_var:=500;DROP TABLE IF EXISTS "network";
CREATE TABLE IF NOT EXISTS "network" as (SELECT * FROM "orig_network");
drop table if exists poi_tmp;
CREATE TABLE if not exists poi_tmp as (SELECT ST_Centroid(tmp."geom") the_geom,tmp."id" as pid from (SELECT * FROM "origin") tmp);
ALTER TABLE poi_tmp ADD COLUMN     x FLOAT;
ALTER TABLE poi_tmp ADD COLUMN     y FLOAT;
ALTER TABLE poi_tmp ADD COLUMN     edge_id BIGINT;
ALTER TABLE poi_tmp ADD COLUMN     side CHAR;
ALTER TABLE poi_tmp ADD COLUMN     fraction FLOAT;
ALTER TABLE poi_tmp ADD COLUMN     newPoint geometry;
  • Update the ‘edge_id’ field with the nearest section identifier.
  • Update the ‘fraction’ field with the nearest section fraction.
UPDATE "poi_tmp" set "edge_id"=nearest_section."tram_id" from (SELECT distinct on(Poi.pid) Poi.pid As Punt_id,Sg.id as Tram_id, ST_Distance(Sg.the_geom,Poi.the_geom) as dist FROM "network" as Sg,"poi_tmp" AS Poi ORDER BY Poi.pid, ST_Distance(Sg.the_geom,Poi.the_geom), Sg.id) nearest_section where "poi_tmp"."pid"=nearest_section."punt_id";
UPDATE "poi_tmp" SET fraction = ST_LineLocatePoint(e.the_geom, "poi_tmp".the_geom),newPoint = ST_LineInterpolatePoint(e.the_geom, ST_LineLocatePoint(e.the_geom, "poi_tmp".the_geom)) FROM "network" AS e WHERE "poi_tmp"."edge_id" = e.id;
  • Create ‘tbl_final_nodes_tmp’ table that will contain the ‘id’, aggregate costs and the starting node.
  • Create ‘geo_final_nodes_tmp’ table that will contain the ‘tbl_final_nodes_tmp’ and their geometries.
DROP FUNCTION IF EXISTS coverage();
DROP TABLE IF EXISTS tbl_final_nodes_tmp;
CREATE TABLE IF NOT EXISTS tbl_final_nodes_tmp AS(SELECT node,agg_cost,start_vid FROM pgr_withPointsDD('SELECT id, source, target, cost, reverse_cost FROM "network" ORDER BY "network".id','SELECT pid, edge_id, fraction, side from "poi_tmp"',array(select "pid"*(-1) from "poi_tmp"),dist_var,driving_side := 'b',details := false));
DROP table if exists geo_final_nodes_tmp;
CREATE TABLE IF NOT EXISTS geo_final_nodes_tmp as (select "orig_network_vertices_pgr".*,"tbl_final_nodes_tmp"."agg_cost", "tbl_final_nodes_tmp"."start_vid", dist_var from "orig_network_vertices_pgr","tbl_final_nodes_tmp" where "orig_network_vertices_pgr"."id" ="tbl_final_nodes_tmp"."node" order by "tbl_final_nodes_tmp"."start_vid" desc,"tbl_final_nodes_tmp"."agg_cost");

After executing the previous code, you will obtaing the picture showed in Figure 2. The blue dot shows the projection of the starting point upon the nearest section, and this will be the starting point of every path calculated.

fig2

Fig 2. Nodes conforming the coverage.

The ‘pgr_withPointsDD’ function, returns the nodes that conform the 500m coverage, but if you want to know where exactly finishes the coverage, you can’t.

In order to resolve this problem, continue reading:

  • Create ‘final_sections_tmp’ table that will contain every section that will conform the coverage, including the final sections, but, as you may imagine, only a fraction of the every final section is valid.
DROP table IF EXISTS final_sections_tmp;
CREATE TABLE IF NOT EXISTS final_sections_tmp as (select "network"."id","network"."the_geom","geo_final_nodes_tmp"."id" as node,"geo_final_nodes_tmp"."agg_cost" as coste,(dist_var  "geo_final_nodes_tmp"."agg_cost") as falta,"geo_final_nodes_tmp"."start_vid" as id_punt,  (select case when (dist_var-"geo_final_nodes_tmp"."agg_cost") / ST_Length("network"."the_geom")<=1 then (dist_var-"geo_final_nodes_tmp"."agg_cost") / ST_Length("network"."the_geom") when (dist_var-      "geo_final_nodes_tmp"."agg_cost") / ST_Length("network"."the_geom")>1 then (1) end) as      fraccio from "network","geo_final_nodes_tmp" where ST_DWithin("geo_final_nodes_tmp"."the_geom", "network"."the_geom",1)=TRUE);

You can see the result of executing the previous code in Figure 3.

fig3

Fig 3. Section conforming part of the 500m coverage.

In order to obtain the fractions of the final sections that complete the 500m coverage, below is a function written in ‘PL/pgSQL’, that does the necessary modifications.

  • Create ‘Coverage’ function.
  • Create ‘fraction_sections_raw’ table, that will contain complete and fractioned sections that conform the 500m coverage.
CREATE OR REPLACE FUNCTION coverage() RETURNS SETOF final_sections_tmp AS
$BODY$
DECLARE
r final_sections_tmp%rowtype;
m final_sections_tmp%rowtype;
BEGIN
DROP TABLE IF EXISTS fraction_sections_raw;
CREATE TABLE fraction_sections_raw (the_geom geometry, punt_id bigint,id_tram bigint,fraccio FLOAT,node bigint,fraccio_inicial FLOAT,cost_invers FLOAT,cost_directe FLOAT,target bigint,radi_inic FLOAT);
FOR r IN SELECT "final_sections_tmp".* FROM "final_sections_tmp" WHERE "final_sections_tmp"."id" not in (select "edge_id" from "poi_tmp")
LOOP
insert into fraction_sections_raw VALUES(ST_Line_Substring((r."the_geom"),case when (select ST_Line_Locate_Point((r."the_geom"),(select "geo_final_nodes_tmp"."the_geom" from "geo_final_nodes_tmp" where "geo_final_nodes_tmp"."id"=r."node" and "geo_final_nodes_tmp"."start_vid"=r."id_punt")))<0.001 then 0 else 1-r."fraccio"
END,
case when (select ST_Line_Locate_Point((r."the_geom"),(select "geo_final_nodes_tmp"."the_geom" from "geo_final_nodes_tmp" where "geo_final_nodes_tmp"."id"=r."node" and "geo_final_nodes_tmp"."start_vid"=r."id_punt")))<0.001 then r."fraccio" else 1
END),r."id_punt"*(-1),r."id",0,r."node",0,0,0,0);
RETURN NEXT r;
END LOOP;
FOR m IN SELECT "final_sections_tmp".* FROM "final_sections_tmp" WHERE "final_sections_tmp"."id" in (select "edge_id" from "poi_tmp")
LOOP
insert into fraction_sections_raw VALUES(m."the_geom",m."id_punt"*(-1),m."id",0,m."node",0,0,0);
RETURN NEXT m;
END LOOP;
RETURN;
END
$BODY$
LANGUAGE 'plpgsql' ;
PERFORM "the_geom" FROM coverage();

After that, is necessary to modify the ‘fraction_sections_raw’ table, in order to obtain the complete 500m coverage.

  • Update ‘fraccio_inicial’ table with the calculated value.
  • Update ‘cost_directe’ and ‘cost_invers’ fields with corresponding values.
  • Update ‘fraccio’ field with the calculated values.
  • Modify the geometry using the calulated ‘fraccio’ field.
update "fraction_sections_raw" set "fraccio_inicial"="poi_tmp"."fraction" from "poi_tmp" where "id_tram"="edge_id";
update "fraction_sections_raw" set "cost_directe"="network"."cost", "target"="network"."target", "cost_invers"="network"."reverse_cost" from "network" where "id_tram"="id";
UPDATE "fraction_sections_raw" SET "fraccio"=((case when ("fraction_sections_raw"."fraccio_inicial" * ST_Length("fraction_sections_raw"."the_geom"))>dist_var then (dist_var/ST_Length("fraction_sections_raw"."the_geom")) else "fraction_sections_raw"."fraccio_inicial" end)+(case when ((1-"fraction_sections_raw"."fraccio_inicial") * ST_Length("fraction_sections_raw"."the_geom"))>dist_var then (dist_var/ST_Length("fraction_sections_raw"."the_geom")) else (1-"fraction_sections_raw"."fraccio_inicial") end));
update "fraction_sections_raw" set "the_geom"=final."the_geom"from(select distinct(ST_Line_Substring((m."the_geom"),(case when (select ST_Line_Locate_Point((m."the_geom"), (select "the_geom" from "geo_final_nodes_tmp" where "geo_final_nodes_tmp"."id"=m."node" and "geo_final_nodes_tmp"."start_vid" = m."punt_id"*-1)))<0.01 then 0 else 1-m."fraccio" END),(case when (select ST_Line_Locate_Point((m."the_geom") , (select "the_geom" from "geo_final_nodes_tmp" where "geo_final_nodes_tmp"."id"=m."node" and "geo_final_nodes_tmp"."start_vid" = m."punt_id"*-1)))<0.01 then m."fraccio" else 1 END)))  the_geom,m."id_tram"from "fraction_sections_raw" m where m."id_tram" in (select "edge_id" from "poi_tmp")) final where final."id_tram" ="fraction_sections_raw"."id_tram";
insert into "fraction_sections_raw" (select SX."the_geom",PI."pid" as punt_id,SX."id"as id_tram,999 as fraccio,SX."source" as node,PI."fraction" as fraccio_inicial , SX."cost",SX."reverse_cost" from "network" SX inner join (Select "edge_id","pid","fraction" from "poi_tmp") PI on SX."id"=PI."edge_id");
UPDATE "fraction_sections_raw" set "the_geom"=final."the_geom" from (select ST_Line_Substring((SXI."the_geom"),(case when (FT."fraccio_inicial" - (dist_var/ST_Length(SXI."the_geom")))>0 then (FT."fraccio_inicial"-(dist_var/ST_Length(SXI."the_geom"))) else 0 end),(case when (FT."fraccio_inicial" + (dist_var/ST_Length(SXI."the_geom")))<1 then (FT."fraccio_inicial"+(dist_var/ST_Length(SXI."the_geom"))) else 1 end)) as the_geom, FT."punt_id", FT."id_tram", FT."fraccio" from "fraction_sections_raw"FT inner join (select SX."the_geom" as the_geom, SX."id" as tram_xarxa from "orig_network" SX, "poi_tmp" PI where SX."id"=PI."edge_id") SXI on FT."id_tram"=SXI.tram_xarxa where FT."fraccio"=999) final where "fraction_sections_raw"."punt_id"=final."punt_id" and "fraction_sections_raw"."fraccio"=999;
  • Create ‘fractions_sections_tmp’ table that will contain every section that conform the 500m coverage.
  • Create ‘driving_distance’ table that will contain the union of every section.
DROP TABLE IF EXISTS fraction_sections_tmp;
CREATE TABLE fraction_sections_tmp AS (select distinct(the_geom),punt_id,radi_inic from fraction_sections_raw);
DROP TABLE IF EXISTS driving_distance;
CREATE TABLE IF NOT EXISTS driving_distance AS (Select ST_Union(TOT.the_geom) the_geom, TOT."punt_id" from (select the_geom,punt_id,radi_inic from fraction_sections_tmp) TOT group by TOT."punt_id");
END $$;

Once executed the previous code, you should have the same as you can see in the Figure 4.

fig4

Fig 4.  Final 500m coverage.

In Figure 4 you can see the final sections cutted where the 500m path finishes. You can compare with Figure 3 and see the differences.

Conclusions

As a final conclusion, we created a function that obtains the coverage through a network , from a given starting point and a given distance or cost function. Improving the result obtained using the functions of the ‘pgrouting’ library.

 

The designed function is applicable to any routing function in which starts from initial points, that can be outside of the network, to obtain the desired coverage.

The code can be downloaded here.

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

 

Cobertura mitjançant graf de carrers

Al traçar una trajectòria a traves d’un graf de trams de carrer de manera que a partir d’un punt inicial es calculi fins allà on arriba una distancia determinada seguint el graf, és molt probable que aquesta distancia no coincideixi amb un nus concret sinó que estigui en un punt intermedi d’un segment.

En aquest article es presenta una forma d’obtenir la cobertura a partir d’un punt inicial fins que s’arriba a una distancia màxima seguint l’arbre del graf de trams de carrer, la contribució principal és el càlcul del darrer segment parcial en totes les trajectòries.

Concretament, en aquest article s’explica de quina manera s’ha resolt el problema que representa obtenir els trams complerts i parcials que conformen el càlcul d’una distància recorreguda pel graf de carrers, mitjançant la funció ‘pgr_withPointsDD’ del pgrouting des de punts exteriors al graf, es a dir, que no formen part dels nodes de la xarxa.

Per poder utilitzar el codi d’aquest article s’ha de tenir instal·lat en el PostgresSQL l’extensió ‘pgrouting’ que ens permet fer anàlisi de xarxes, per mes informació visiteu la pagina web (http://docs.pgrouting.org) i (http://pgrouting.org).

ATENCIO: Els següents passos modificaran la base de dades PostgresSQL, cal anar amb molt de compte ja que podeu inutilitzar bases de dades ja existents.

  • Descarregar la base de dades PostgresSQL, feu clic aquí.
  • Crear base de dades nova amb nom ‘db_temp’.
  • Restaurar la base de dades descarregada.

Un cop restaurada la base de dades PostgresSQL, s’ha de tenir 3 entitats:

  • “orig_network” (xarxa de carrers)
  • “origin” (punt d’inici)
  • “orig_network_vertices_pgr” (nodes de la xarxa de carrers)

Per entendre millor el procediment s’ha plantejat un exemple concret basat en un graf de trams de carrer totalment simètric i ortogonal, però seria aplicable a qualsevol graf.

Es parteix d’una xarxa ortogonal de carrers (“orig_network”) de 2.000 x 2.000 metres, amb trams de carrers de 100m de node a node i el punt inicial (“origin”) representat en vermell, tal i com es pot veure en la figura 1.

fig1

Fig 1. Xarxa ortogonal de carrers de 100m.

Procediment pel càlcul de cobertura mitjançant pgrouting.

Per calcular una cobertura de 500m des del punt vermell seguirem les següents passes:

  • Fer un duplicat de la xarxa al qual anomenarem ‘network’.
  • Crear una taula anomenada ‘poi_tmp’ on tindrà totes les geometries dels punts inicials, en el nostre cas només tindrà un valor.
  • Modificar la taula ‘poi_tmp’ afegint els camps (x,y,edge_id,side,fraction, newPoint);
DO $$
#variable_conflict use_variable
DECLARE dist_var INT;
BEGIN
dist_var:=500;DROP TABLE IF EXISTS "network";
CREATE TABLE IF NOT EXISTS "network" as (SELECT * FROM "orig_network");
drop table if exists poi_tmp;
CREATE TABLE if not exists poi_tmp as (SELECT ST_Centroid(tmp."geom") the_geom,tmp."id" as pid from (SELECT * FROM "origin") tmp);
ALTER TABLE poi_tmp ADD COLUMN     x FLOAT;
ALTER TABLE poi_tmp ADD COLUMN     y FLOAT;
ALTER TABLE poi_tmp ADD COLUMN     edge_id BIGINT;
ALTER TABLE poi_tmp ADD COLUMN     side CHAR;
ALTER TABLE poi_tmp ADD COLUMN     fraction FLOAT;
ALTER TABLE poi_tmp ADD COLUMN     newPoint geometry;
  • Actualitzar el camp ‘edge_id’ amb l’identificador del tram més proper.
  • Actualitzar el camp ‘fraction’ amb la fracció corresponent del tram abans trobat.
UPDATE "poi_tmp" set "edge_id"=nearest_section."tram_id" from (SELECT distinct on(Poi.pid) Poi.pid As Punt_id,Sg.id as Tram_id, ST_Distance(Sg.the_geom,Poi.the_geom) as dist FROM "network" as Sg,"poi_tmp" AS Poi ORDER BY Poi.pid, ST_Distance(Sg.the_geom,Poi.the_geom), Sg.id) nearest_section where "poi_tmp"."pid"=nearest_section."punt_id";
UPDATE "poi_tmp" SET fraction = ST_LineLocatePoint(e.the_geom, "poi_tmp".the_geom),newPoint = ST_LineInterpolatePoint(e.the_geom, ST_LineLocatePoint(e.the_geom, "poi_tmp".the_geom)) FROM "network" AS e WHERE "poi_tmp"."edge_id" = e.id;
  • Crear la taula ‘tbl_final_nodes_tmp’ que contindrà les ‘id’, els costos agregats i el node de partida de tots els nodes pels quals passa la funció ‘pgr_withPointsDD’.
  • Crear la taula ‘geo_final_nodes_tmp’ que contindrà els nodes anteriors amb la geometria corresponent.
DROP FUNCTION IF EXISTS coverage();
DROP TABLE IF EXISTS tbl_final_nodes_tmp;
CREATE TABLE IF NOT EXISTS tbl_final_nodes_tmp AS(SELECT node,agg_cost,start_vid FROM pgr_withPointsDD('SELECT id, source, target, cost, reverse_cost FROM "network" ORDER BY "network".id','SELECT pid, edge_id, fraction, side from "poi_tmp"',array(select "pid"*(-1) from "poi_tmp"),dist_var,driving_side := 'b',details := false));
DROP table if exists geo_final_nodes_tmp;
CREATE TABLE IF NOT EXISTS geo_final_nodes_tmp as (select "orig_network_vertices_pgr".*,"tbl_final_nodes_tmp"."agg_cost", "tbl_final_nodes_tmp"."start_vid", dist_var from "orig_network_vertices_pgr","tbl_final_nodes_tmp" where "orig_network_vertices_pgr"."id" ="tbl_final_nodes_tmp"."node" order by "tbl_final_nodes_tmp"."start_vid" desc,"tbl_final_nodes_tmp"."agg_cost");

Després d’executar el codi anterior obtenim la imatge mostrada a la figura 2. El punt blau indica la projecció del punt de partida sobre el tram més proper, que serà d’on començaran tots els camins.

fig2

Fig 2. Nodes que queden dins de la cobertura.

El que ens retorna la funció ‘pgr_withPointsDD’ son els nodes que queden dins de la cobertura, però si volem saber els trams que composen la cobertura de 500 metres, veurem que no sabem quins son els trams finals de la cobertura que quedarien incomplerts.

Per tal de resoldre aquest problema, s’ha de fer el següent:

  • Crear la taula ‘final_sections_tmp’ on tindrem tots els trams que formen part de la cobertura , inclosos els trams finals dels quals només és vàlida una fracció del mateix.
DROP table IF EXISTS final_sections_tmp;
CREATE TABLE IF NOT EXISTS final_sections_tmp as (select "network"."id","network"."the_geom","geo_final_nodes_tmp"."id" as node,"geo_final_nodes_tmp"."agg_cost" as coste,(dist_var  "geo_final_nodes_tmp"."agg_cost") as falta,"geo_final_nodes_tmp"."start_vid" as id_punt,  (select case when (dist_var-"geo_final_nodes_tmp"."agg_cost") / ST_Length("network"."the_geom")<=1 then (dist_var-"geo_final_nodes_tmp"."agg_cost") / ST_Length("network"."the_geom") when (dist_var-      "geo_final_nodes_tmp"."agg_cost") / ST_Length("network"."the_geom")>1 then (1) end) as      fraccio from "network","geo_final_nodes_tmp" where ST_DWithin("geo_final_nodes_tmp"."the_geom", "network"."the_geom",1)=TRUE);

En la figura 3 es mostra el resultat d’executar el codi anterior.

fig3

Fig 3. Trams que formen part de la cobertura de 500 metres.

Per tal d’obtenir les fraccions del trams finals que completen la cobertura de 500 metres, s’ha creat una funció en ‘PL/pgSQL’, la qual realitza les modificacions necessàries.

  • Crear la funció ‘Coverage’ que realitzarà el procés.
  • Crear la taula ‘fraction_sections_raw’ que contindrà el trams (complerts i fraccions) que composen la cobertura de 500 metres.
CREATE OR REPLACE FUNCTION coverage() RETURNS SETOF final_sections_tmp AS
$BODY$
DECLARE
r final_sections_tmp%rowtype;
m final_sections_tmp%rowtype;
BEGIN
DROP TABLE IF EXISTS fraction_sections_raw;
CREATE TABLE fraction_sections_raw (the_geom geometry, punt_id bigint,id_tram bigint,fraccio FLOAT,node bigint,fraccio_inicial FLOAT,cost_invers FLOAT,cost_directe FLOAT,target bigint,radi_inic FLOAT);
FOR r IN SELECT "final_sections_tmp".* FROM "final_sections_tmp" WHERE "final_sections_tmp"."id" not in (select "edge_id" from "poi_tmp")
LOOP
insert into fraction_sections_raw VALUES(ST_Line_Substring((r."the_geom"),case when (select ST_Line_Locate_Point((r."the_geom"),(select "geo_final_nodes_tmp"."the_geom" from "geo_final_nodes_tmp" where "geo_final_nodes_tmp"."id"=r."node" and "geo_final_nodes_tmp"."start_vid"=r."id_punt")))<0.001 then 0 else 1-r."fraccio"
END,
case when (select ST_Line_Locate_Point((r."the_geom"),(select "geo_final_nodes_tmp"."the_geom" from "geo_final_nodes_tmp" where "geo_final_nodes_tmp"."id"=r."node" and "geo_final_nodes_tmp"."start_vid"=r."id_punt")))<0.001 then r."fraccio" else 1
END),r."id_punt"*(-1),r."id",0,r."node",0,0,0,0);
RETURN NEXT r;
END LOOP;
FOR m IN SELECT "final_sections_tmp".* FROM "final_sections_tmp" WHERE "final_sections_tmp"."id" in (select "edge_id" from "poi_tmp")
LOOP
insert into fraction_sections_raw VALUES(m."the_geom",m."id_punt"*(-1),m."id",0,m."node",0,0,0);
RETURN NEXT m;
END LOOP;
RETURN;
END
$BODY$
LANGUAGE 'plpgsql' ;
PERFORM "the_geom" FROM coverage();

Tot seguit es modifica la taula ‘fraction_sections_raw’ per tal d’obtenir els trams finals que corresponen a la cobertura de 500 metres.

  • Actualitzar ‘fraccio_inicial’ amb el valor que li pertoca.
  • Actualizar ‘’cost_directe’, ‘cost_invers’ amb els valors corresponents.
  • Actualitzar ‘fraccio’ amb el valors calculats dels trams finals.
  • Modificar la geometria segons el camp ‘fraccio’ calculat.
update "fraction_sections_raw" set "fraccio_inicial"="poi_tmp"."fraction" from "poi_tmp" where "id_tram"="edge_id";
update "fraction_sections_raw" set "cost_directe"="network"."cost", "target"="network"."target", "cost_invers"="network"."reverse_cost" from "network" where "id_tram"="id";
UPDATE "fraction_sections_raw" SET "fraccio"=((case when ("fraction_sections_raw"."fraccio_inicial" * ST_Length("fraction_sections_raw"."the_geom"))>dist_var then (dist_var/ST_Length("fraction_sections_raw"."the_geom")) else "fraction_sections_raw"."fraccio_inicial" end)+(case when ((1-"fraction_sections_raw"."fraccio_inicial") * ST_Length("fraction_sections_raw"."the_geom"))>dist_var then (dist_var/ST_Length("fraction_sections_raw"."the_geom")) else (1-"fraction_sections_raw"."fraccio_inicial") end));
update "fraction_sections_raw" set "the_geom"=final."the_geom"from(select distinct(ST_Line_Substring((m."the_geom"),(case when (select ST_Line_Locate_Point((m."the_geom"), (select "the_geom" from "geo_final_nodes_tmp" where "geo_final_nodes_tmp"."id"=m."node" and "geo_final_nodes_tmp"."start_vid" = m."punt_id"*-1)))<0.01 then 0 else 1-m."fraccio" END),(case when (select ST_Line_Locate_Point((m."the_geom") , (select "the_geom" from "geo_final_nodes_tmp" where "geo_final_nodes_tmp"."id"=m."node" and "geo_final_nodes_tmp"."start_vid" = m."punt_id"*-1)))<0.01 then m."fraccio" else 1 END)))  the_geom,m."id_tram"from "fraction_sections_raw" m where m."id_tram" in (select "edge_id" from "poi_tmp")) final where final."id_tram" ="fraction_sections_raw"."id_tram";
insert into "fraction_sections_raw" (select SX."the_geom",PI."pid" as punt_id,SX."id"as id_tram,999 as fraccio,SX."source" as node,PI."fraction" as fraccio_inicial , SX."cost",SX."reverse_cost" from "network" SX inner join (Select "edge_id","pid","fraction" from "poi_tmp") PI on SX."id"=PI."edge_id");
UPDATE "fraction_sections_raw" set "the_geom"=final."the_geom" from (select ST_Line_Substring((SXI."the_geom"),(case when (FT."fraccio_inicial" - (dist_var/ST_Length(SXI."the_geom")))>0 then (FT."fraccio_inicial"-(dist_var/ST_Length(SXI."the_geom"))) else 0 end),(case when (FT."fraccio_inicial" + (dist_var/ST_Length(SXI."the_geom")))<1 then (FT."fraccio_inicial"+(dist_var/ST_Length(SXI."the_geom"))) else 1 end)) as the_geom, FT."punt_id", FT."id_tram", FT."fraccio" from "fraction_sections_raw"FT inner join (select SX."the_geom" as the_geom, SX."id" as tram_xarxa from "orig_network" SX, "poi_tmp" PI where SX."id"=PI."edge_id") SXI on FT."id_tram"=SXI.tram_xarxa where FT."fraccio"=999) final where "fraction_sections_raw"."punt_id"=final."punt_id" and "fraction_sections_raw"."fraccio"=999;
  • Crear la taula ‘fractions_sections_tmp’ que contindrà els trams sense duplicats de la cobertura de 500m.
  • Crear la taula ‘driving_distance’ que contindrà la unió de tots els trams.
DROP TABLE IF EXISTS fraction_sections_tmp;
CREATE TABLE fraction_sections_tmp AS (select distinct(the_geom),punt_id,radi_inic from fraction_sections_raw);
DROP TABLE IF EXISTS driving_distance;
CREATE TABLE IF NOT EXISTS driving_distance AS (Select ST_Union(TOT.the_geom) the_geom, TOT."punt_id" from (select the_geom,punt_id,radi_inic from fraction_sections_tmp) TOT group by TOT."punt_id");
END $$;

Un cop executat tot el codi el resultat és el que es mostra en la figura 4.

fig4

Fig 4. Cobertura final de 500 metres.

En aquesta figura es poden veure els segments finals dels trajectes a partir del punt projectat amb la seva autèntica dimensió, implicant per tant només un fragment del tram sencer correspondent, es pot comparar amb la figura 3 per veure la diferència de resultats.

Conclusions

Com a conclusió finals del article, podem dir que s’ha creat una funció per obtenir la cobertura a partir d’un punt amb distància o funció  de cost constant a partir d’un punt d’inici projectat sobre del graf, donant un resultat exacte.

Millorant, així, el resultat que es podria obtenir només amb les funcions pròpies de la llibreria del ‘pgrouting’.

La funció dissenyada es aplicable a qualsevol funció de rutatge en la que es parteixi d’uns punts inicials, que formin, o no, part del graf, i obtenir la cobertura desitjada.

El codi sencer es pot descarregar del següent enllaç.

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

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

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

2

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

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

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

 

Manual de preparació de l’entorn d’usuari QGIS

En aquesta secció s’expliquen els passos a seguir per instal·lar el programa QGIS en el nostre entorn. El primer pas a seguir és anar al lloc web de QGIS (www.qgis.org) i dirigir-se a l’apartat de descàrregues (http://qgis.org/es/site/forusers/download.html). Allà es podran trobar dues versions del programa: la versió més recent i la de llarg termini. Qualsevol de les dues és perfectament vàlida, tot i que si l’usuari del programa treballa per una empresa o institució pública, recomanem la versió de llarg termini. Un cop escollida la versió, només cal descarregar-la.27

Un cop descarregada, cal instal·lar-la en el nostre equip. Només cal que fem doble clic a l’arxiu que hem descarregat prèviament. Llavors s’executarà l’instal·lador i només cal seguir els passos que ens indica. Un cop completat aquest procés, ja podrem executar el QGIS.

Per poder instal·lar els plugins que s’utilitzen per tractar les dades cal anar a Complementos à Administrar e instalar complementos… i ens apareixerà una finestra com la següent:28 Anem a la pestanya de configuració.29

Marcarem la opció de “comprovar actualitzacions a l’inici”, que es troba a la part superior, i posteriorment escollirem la periodicitat de l’acció amb les diferents opcions del desplegable que podem trobar just a sota.
També és necessari afegir el repositori on es troben els plugins necessaris per treballar. Cal prémer el botó Añadir…, que es troba a la part inferior, i ens apareixerà la finestra que es mostra a continuació.30

En el camp de nom cal afegir un nom com per exemple “Plugins CCU Tecnocampus” i en el camp de la URL cal posar http://geoportalccu.tecnocampus.cat/plugins.xml. Un cop fet, acceptem i tornem a l’apartat de Todos. A la part superior hi podrem trobar un barra de cerca on buscarem els plugins necessaris: TaulaResum, Activitats Econòmiques i ZI-GTC.

Un cop els trobem, pitgem sobre ells i finalment només caldrà instal·lar-los en el nostre equip.31

Aleshores només cal tancar la finestra i afegir les connexions a la base de dades per a poder treballar amb el QGIS. Per últim només ens farà falta configurar la connexió amb la base de dades. Per poder-ho fer cal seguir els següents passos:

Primer cal cercar a la barra d’eines en el lateral esquerra de la nostra pantalla una icona com aquesta 32Un cop ho haguem fet, ens apareixerà una finestra com la de la figura 1. En allà cal prémer el botó “Nueva”, tal i com està senyalitzat a la mateixa figura. Posteriorment ens ha d’aparèixer una finestra com la de la figura 2. En allà cal introduir els camps necessaris per configurar la connexió: usuari, nom de la base de dades, servidor i contrasenya. Una vegada fet, només es necessari prémer el botó Acceptar de les dues finestres mencionades prèviament i ja tindríem l’entorn preparat per treballar.

33Figura 134

Figura 2

Manual d’ús del mòdul ‘ZI-GTC’

Aquest post explica el funcionament del plugin de ‘ZI-GTC’ 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üent17 o anar a Complementos -> CCU -> Càlcul de població afectada i s’obrirà una finestra com la que podem veure a continuació a la imatge.18_2

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

  1. Comencem per la part superior, on hi trobem una pestanya desplegable i un requadre. A la pestanya s’escull la connexió amb la que volem treballar, i que prèviament hem configurat en el QGIS. En el requadre indica l’estat de la connexió.19
  2. En segon lloc, trobem una pestanya desplegable on hi podem seleccionar la entitat puntual sobre la qual volem treballar.20
  3. Just a sota, podem trobar una altra pestanya desplegable. En aquesta ocasió tindrem la possibilitat d’escollir la xarxa de carrers sobre la qual volem treballar. Per poder utilitzar la capa, cal que disposem d’accés a una taula auxiliar amb els vèrtex. Cada vegada que seleccionem una capa de graf, el plugin s’encarrega de comprovar que la capa auxiliar hi sigui. En el cas que no hi sigui, un missatge apareixerà per tal d’informar de la situació a l’usuari.21
  1. En quart lloc, hi ha el menú per seleccionar el mètode de treball: primer trobem un desplegable per treballar sobre la distància o el temps. Just a dreta hi trobem dos checkBox que només s’activen quan en el desplegable hi ha escollida la opció de ‘Temps’ i que s’utilitzen per indicar si volem utilitzar el cost invers i el de nusos. Després hi ha un camp per omplir text on l’indicarem amb un número la distància o el temps amb la que volem fer el buffer, i en últim lloc hi ha una pestanya desplegable on hi podrem escollir el camp de la taula de la xarxa de carrers que s’utilitzarà com a camp de distància o temps, segons s’hagi escollit.22
  1. Just després del mètode de treball, hi trobem les opcions d’aparença del graf. Primer hi ha un checkBox que habilita el botó amb el qual s’escull el color i una pestanya on s’escull el gruix del traç. A més a més, hi ha un camp on hi podem indicar el radi en metres de la zona d’influència de l’entorn del graf.23
  1. Seguidament hi ha una pestanya on podem escriure el títol de la llegenda. En el moment en què escollim una entitat puntual, aquest camp s’actualitzarà automàticament per “<nom de la entitat>”. Tot i això, el títol pot ser el que nosaltres vulguem.24
  1. Després d’això, trobarem l’apartat on seleccionarem el mètode per treballar amb la població. Primer trobarem un checkBox on indicarem si volem treballar amb la població. En cas afirmatiu, ens apareixerà el menú amb les opcions just a sota. En aquest menú hi apareixen 3 botons on indicarem si volem treballar amb les illes, parcel·les o portals. En la part inferior hi ha una etiqueta blanca on hi apareix el percentatge d’habitants afectats per la zona d’influència del càlcul, un cop realitzat. A la dreta hi ha un checkBox on hi indicarem si volem que es mostri la població exclosa.25
  2. Finalment, a la part inferior de la finestra hi ha dos botons: el de ‘SORTIR’ i el de processar o ‘INICI’. El de SORTIR serveix per tancar la pestanya. El botó ‘INICI’ serveix per processar la consulta que li hem indicat amb els elements que acabem de veure. Segons les opcions que li haguem indicat, ens apareixerà un resultat o un altre. En el cas que alguna de les dades o la connexió no sigui correcta, el programa advertirà de la incidència a l’usuari. Un cop aquesta sigui resolta, l’usuari podrà executar el programa amb normalitat.26