Yearly Archives: 2018

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í