Entrades classificades amb: distàncies

Primers passos en el rutatge al QGIS

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

Capes de treball

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

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

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

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

Procés de creació

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

fuc

dades

 

 

 

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#Per buscar els 3 millors de cada punt

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

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

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

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

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

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

                route_points.append(from_point)

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

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

Procés d’utilització

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

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

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

afe

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

afe2

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

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

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

afe5

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

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

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

Prova del mòdul

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

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

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

ex2

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

Sobre la Generació de Taules de Proximitat

 

 

En anteriors entrades ja hem parlat del Graf de Trams de Carrer (GTC). El GTC és un conjunt de segments connectats per nodes per on poden circular els vianants de la ciutat per fer els seus trajectes a peu dins de la vila (vegeu l’entrada: ‘Sobre el Graf de Trams de Carrer (GTC) ‘).

També es va veure com mitjançant unes característiques pròpies dels segments del graf podem saber la distància mínima entre un punt qualsevol, normalment una adreça qual­sevol, i un centre proveïdor de servei (CAP, Escola, Centre Cívic etc.), això ens va por­tar al un nou concepte de Zona d’Influència basat en la distància sobre el GTC o en el temps necessari per recórrer aquesta distància (vegeu l’entrada: ‘Nou concepte de Zo­nes d’Influència lligat als desplaçaments de la població’).

El GTC és un graf orientat i d’aquí ve que en els seus segments podem tenir informació del Cost (temps que triga una persona en recórrer el segment anant a una determinada velocitat quan va en el sentit del tram) i Cost_invers (temps que triga quan va en sentit contrari), això també es pot aplicar a una población segmentada segons l’edat, ja que presumiblement la velocitat será diferent per una persona de 25 anys que per una per­sona de 65.

Una de les possibilitats que té el GTC dins del Geomèdia (GM) és la utilització d’eines de rutatge, com el Geomèdia Transportation Mànager (GMTM) que ens permeten, a més a més de generar el propi graf, calcular els camins més curts o òptims segons una determinada funció cost entre dues o més entitats o Classes d’Entitat (taula o conjunt d’entitats del mateix tipus). Una de les característiques del GMTM que es va desenvo­lupar és la possibilitat de generar cobertures a partir d’unes classes d’entitat inicials que ens van facilitar la construcció de l’eina per generar les Zones d’Influència basades en el GTC que ja s’ha descrit.

L’explotació de totes les possibilitats de trobar camins entre entitats a través d’un graf, si no es vol efectuar el càlcul directament en el moment, o si no es disposa dels ele­ments de càlcul ‘on line’, ens porta a la generació de taules amb tots els camins entre les entitats origen i les entitats final, que anomenem ‘Taules de Proximitat’.  Després per obtenir determinats trajectes només haurem de consultar la taula corresponent, sense necessitat de disposar de les eines de rutatge i ni tan sols l’entorn del GM.

Per la creació d’aquestes taules es va construïr un mòdul del GM anomenat ‘Generació de Taules de Proximitat’ que anem a descriure tot seguit [Aquest mòdul formava part del Projecte Final de Carrera de Eric Belando que va presentar el 2011 a la EUPMt per obtenir el Títol d’Enginyer Tècnic Industrial] . El format del Generador de Taules és el d’un formulari on haurem de plasmar les entrades i les opcions d’aquest càlcul, vegeu la figura 1.

Fig 1. Interfície d’usuari per la Generació de Taules de Proximitat

Anem a repassar les tres seccions que es poden veure en aquest formulari

ENTRADES

  • Entitats  ‘origen’ ,des de les quals volem accedir a les entitats proveïdores d’un servei, aquestes poden ser entitats puntuals, com ara els números de policia o portals a peu de carrer, que podem resumir en una adreça determinada tipus Nom de Carrer i Numèro de Carrer. Un altre tipus d’entitats genèriques de la ciutat poden ser les Illes de cases, o també les Parcel·les, en aquest cas serien entitats tipus àrea. Com que per fer el rutatge necessitem una entitat puntual d’origen, en el cas de les entitats tipus àrea s’agafaria el centroide. De totes maneres l’aplicatiu pot funcionar amb qualsevol tipus d’entitat origen, parades de bus, contenidors d’escombreries etc.
  • Entitats ‘destí’, cap a on es dirigeixen els camins que surten de les entitats ori­gen, aquestes entitats serien les que proveeixen d’un servei: Centres d’Assistència Primària, Escoles etc.
  • Graf de Trams de Carrer que utilitzarem. S’han de donar dues classes d’entitat: segments i nusos. El graf ha de tenir informació dels valors de les variables Cost i Cost_invers de cada segment i si es volen calcular taules amb segmentació d’edats hem de tenir aquests mateixos valors de Cost i Cost_invers per a cada segment d’edat. Per això hi ha l’opció d’escollir el GTC que en interessi.

PARÀMETRES

  • S’ha d’indicar si volem generar la taula agafant com a criteri de proximitat la dis­tància (camins de les entitats ‘origen’ fins a les entitats ‘final’ que siguin més curts en distància) o bé el temps  (camins de les entitats ‘origen’ fins a les enti­tats ‘final’ que siguin més curts en temps).

Si hem agafat com a criteri el temps haurem d’escollir si volem segmen­tació per edats o no (si és així el GTC l’ha d’incloure).

  • Nombre d’entitats a les que volem generar camins per ordre de proximitat. Ca­mins a 4 les Escoles Bressol (EB), per exemple, més properes. En aquest cas de cada entitat ‘origen’ hi haurà 4 camins a les 4 EB més properes.
  • Paràmetres interns de la generació de taules. Com ara quina ha la distància mà­xima de les entitats ‘origen’ al GTC per possibilitar el rutatge. O els les agrupa­cions d’entitats que podem fer com a bloc de càlcul.

SORTIDES

  • A quina connexió del GM volem posar les taules que generem com a sortida.
  • Els noms que tenen cada una de les dues taules que generem. Una taula de trajec­tes, o camins, per tant amb geometria de línia. I una taula sense geometria on només posem les dades de la proximitat les entitats ‘final’ per a cada entitat ‘origen’, aquesta proximitat pot ser expressada en metres (distància) o en minuts (temps) segons el mètode que hàgim utilitzat

Aquesta  interfície de la figura 1 correspon a la generació de taules de trajectes i proxi­mitat des de les Illes de Cases de la ciutat de Mataró fins a totes les Llars d’Infants (es­coles bressol privades) de la ciutat. Considerant la unitat de mesura el temps empleat en fer el recorregut , per les les persones de menys de 25 anys. Es considera també que cerquem els trajectes i la proximitat a les dues Llars d’Infants més properes a cada Illa de Cases.

A la part esquerra del formulari tenim les ENTRADES on s’ha d’escollir la classe d’entitat de les entitats ‘origen’ i la classe d’entitat de les entitats ‘destí’ i on també s’ha d’escollir l’atribut identificador de cada entitat. Igualment s’ha de seleccionar les dues classes d’entitat del GTC, els segments i els nodes.

A la part central hi ha els PARÀMETRES de les taules que ja hem comentat.

A la dreta hi ha la configuració de les SORTIDES, connexió escollida d’entre les con­nexions actives del GM, i els noms de les dues taules de sortida que estem generant. També hi ha una retroacció del procés que s’està desenvolupant, una barra de progrés abaix de tot i un ‘log’ de quan s’ha acabat de processar cada una dels blocs d’entitats en que s’ha dividit del procés. En el cas de la figura 1, s’ha escollit blocs de 100 entitats i com que hi ha unes 800 i escaig Illes tindrem unes nou línies en la finestra, indicant per a cada bloc en quin moment s’ha completat. Aquest informació ens pot permetre decidir quin format de bloc és més eficient per a cada procés i cada màquina.

 

Fig 2. Generació de la Taula des de cada portal

A la figura 2 veiem el cas de la generació de les taules de trajectes i proximitat des de cada portal, n’hi ha uns 20000, si s’agafen blocs de 100 es necessiten 200 blocs tal com mostra la finestra de seguiment del procés.

També a la figura 3 es mostra la taula generada,  amb el primer camp D_S_I (districte_secció_illa) que correspon de cada Illa de Cases, el segon camp que es veu correspon a l’entitat d’arribada, que està definida pel nom de la Llar d’Infants corresponent, el camp número 4 correspon al temps definit en minuts que es trigaria en anar des de l’Illa del primer camp a la Llar d’Infants del segon camp, la resta de camps indiquen la geometria o sigui el dibuix del trajecte i només els pot interpretar el GM. Com es pot veure per a cada Illa hi ha dos trajectes, són els dos més ‘curts’ a les Llars d’Infants més ‘properes’.

Fig. 3. Taula de les sortides dels trajectes: TrajectesILLES_LI_25a_2

Aquesta  mateixa informació està indicada en un sol registre, en comptes de dos, en la taula de proximitat, on no hi ha cap ‘geometria’. Vegeu la figura 4 on la primera entitat de destí que es troba és la més propera (en temps)

Fig 4. Taula de les sortides de la proximitat: ProximitatILLES_LI_25a_2

En resum aquest mòdul és molt interessant per tenir una base de dades de trajectes o de proximitat en temps o distància, que es poden utilitzar en la publicació ràpida d’informacions que es puguin cercar a partir de ubicacions sobre el mapa de la ciutat o de llistats de domicilis, o d’adreces amb georeferenciació.   Pot ser molt útil per un recurs web, com ara el el servei WFS, del que es pugui obtenir un o varis camins a partir d’una petició d’una pàgina web on hi hagi una ubicació sobre el mapa de mataró. Només cal que, per que la informació sigui actual, les taules es va­gin generant periòdicament, cosa que s’aconsegueix de forma senzilla utilitzant aquest aplicatiu mostrat.

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

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

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

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

Fig. 1. Exemple de diagrama de Voronoi

Algoritme utilitzat

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

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

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

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

 

Formulari

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

Fig. 3. Formulari de la aplicació creada.

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

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

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

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

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

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

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

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

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

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

  • Botó “calcular Voronoi”.

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

Fig. 10. Botó calcular Voronoi.

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

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

  • Botó Sortir

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

Fig. 12. Botó sortir.

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

Mòduls

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

Mòdul Obtenció de coordenades

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

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

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

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

 

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

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

Modul Voronoi_code

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

Fig. 14. Generar.dll.

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


 


 

 

 

 

 


 

 

Aplicatiu per mostrar trajectes a entitats per ordre de proximitat

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

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

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

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

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

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

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

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

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

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

Figura 3: Selecció de la BBDD de trajectes

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

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

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

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

Figura 5: Resultats obtinguts en l’execució.

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

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

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

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

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

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

Estudi de l’Activitat Econòmica

 

Unes de les aplicacions més sol·licitades dels Sistemes d’Informació Geogràfica (SIG) són les que tenen a veure amb l’anàlisi de l’activitat econòmica (AE), sigui aquesta la corresponent d’una ciutat, d’un territori o d’un país.

De fet la col·locació sobre el terreny de les diferents activitats econòmiques és una informació estratègica de primer ordre, ja que d’una mirada es pot intuir  si d’una determinada activitat, diguem-ne per exemple: restaurants, farmàcies o perruqueries, n’hi ha una concentració exagerada, equilibrada o deficient. Una anàlisi més rigorosa ens permetria saber si d’acord amb la població ‘target’ que hi ha en la seva proximitat i amb els hàbits de mobilitat de la població està justificada o no una determinada oferta en un lloc concret en relació amb la demanda possible. En aquest sentit s’hauria d’anar a esbrinar motivacions sociològiques, moltes vegades difícilment  racionalitzables, per explicar el per què de la presència o no  d’una activitat en una àrea determinada.

De tota manera, una de les motivacions més senzilles de la geolocalització d’activitats econòmiques en un territori, serien les aplicacions anomenades de ‘geo-marketing’, consistents en veure on hi ha ‘buits’ o mancances d’una determinada activitat per impulsar la creació de negocis precisament en aquells indrets.

Un primer punt d’un aplicatiu que respongués a tals característiques seria la ubicació de les activitats econòmiques sobre el mapa de la ciutat, en aquest cas, de la ciutat de Mataró. Aquesta eina per ser útil caldria que oferís la possibilitat de diferents mètodes de cerca de les activitats, sigui pel nom o descripció, sigui pel codi corresponent segons una determinada classificació. També caldria tenir una font de les activitats i un manteniment que permetés afegir amb agilitat les altes i les baixes que es van produint.

Arribats a aquest punt cal dir que el CCU ha treballat i està treballant en la generació d’eines que permetin ubicar les AE sobre el mapa de la ciutat de Mataró, tant pel que fa a parcel·la com a portal.

La font  de la informació de l’AE de Mataró que ha escollit el CCU és la Brossa Comercial (BC). Cada activitat genera un tipus de deixalles específic i això influeix en la tarifa que ha de pagar, i quan es deixi de fer l’activitat el seu titular serà el primer interessat en notificar-ho als responsables de recaptació per deixar de pagar per aquell concepte, per tant la Base de Dades de la Brossa Comercial és una font actualitzada de l’AE a la ciutat. Com a part negativa d’escollir aquesta font hi ha el fet  que l’activitat real que es faci no s’ajusti exactament a la declarada en concepte de deixalles generades.

Respecte al tema de la classificació, en aquest moment s’ha escollit la forma de classificació que la BC utilitza, que és la dels epígrafs de l’antic IAE (Impost sobre l’Activitat Econòmica), amb tendència a anar-ho canviant progressivament cap a la classificació CCAE (Classificació Catalana d’Activitats Econòmiques).

A l’aplicatiu del CCU també es poden visualitzar algunes característiques concretes com ara la superfície de l’activitat i consultar igualment algunes informacions proveïdes per la Base de Dades de la BC. A més a més també es poden consultar d’altres informacions relacionades amb la població que s’aniran explicant tot seguit i que el refermen com a eina analítica a més a més d’informativa.

Anem a concretar una mica tot això. A la figura 1 es pot veure la interfície on hi el cercador on a partir d’un paraula o conjunt de paraules o d’un codi podem anar seleccionant les activitats que es volen mostrar.

Fig 1. Llista d’activitats que podem cercar i seleccionar

Un cop escollida l’activitat, si es tracta de situar els portals on es desenvolupa l’activitat, es pot anar a una altra pestanya per incidir en el tamany del ‘topo’ on es mostra (proporcional a la superfície del local), i fer d’altres mesures relacionades amb la població, com ara definir una zona d’influència(ZI) a l’entorn de la ubicació de cada activitat i mostrar un mapa temàtic de la població que queda fora de aquestes zones d’influència.

Si mirem per exemple les ferreteries, la segona pestanya seria la que mostra la figura 2

Fig 2. Pestanya pes escollir tamany dels ‘topos’ i de la Zona d’Influència i tipus de Z.I

En aquest cas s’ha escollit un factor de forma dels ‘topos’ de 2, àrees d’influència circulars de 150 m de radi i veure el mapa temàtic de la població exclosa. La sortida es mostra a la figura 3 on s’ha fet un zoom sobre el centre urbà de la ciutat i es poden apreciar els indrets de l’activitat, les  ZI circulars i el mapa temàtic de les illes externes a les ZI.

Fig 3. Ferreteries amb ZI de 150 m i temàtic de població exterior

La llegenda corresponent a aquest mapa es mostra a la figura 4:

Fig 4. Llegenda del mapa de ferreteries

En el mapa temàtic de la població, les Illes més fosques corresponen a les de més població i per tant allà on ‘faria més falta’ la instal·lació de noves activitats.

Les ZI es poden escollir també sobre el Graf de Trams de Carrer (GTC), anem a  veure un altre exemple, les farmàcies.

En aquest cas hi ha la possibilitat d’escollir el treballar amb distància o recorregut seguint el GTC o bé amb temps de trajecte, i s’ha triat una zona d’influència de 3 minuts a l’entorn de cada centre d’activitat. La segona pantalla es mostra a la figura 5 i la sortida a la figura 6

Fig 5. Segona pantalla per a les Farmàcies amb ZI-GTC

Fig 6. Sortida de la consulta de Farmàcies amb ZI graf a 3 minuts

En resum la interacció entre la situació de les diferents activitats econòmiques amb la població, segmentada per Illes, permet veure la sobre-presència d’activitats en uns punts de la ciutat així com la no presència en d’altres on hi pot haver potencials usuaris o compradors. També la utilització del graf de trams de carrer graduat per distància o per temps ens dóna una idea molt fidel del concepte de proximitat i ens permet fer un anàlisi més acurat de les necessitats o tendències properes en la instal·lació de noves activitats.

 

 

 

 

 

 

 

Sobre el Graf de Trams de Carrer (GTC)

 

Tal com ja s’ha comentat en aquest bloc quan hem parlat del ‘Nou concepte de Zones d’Influència’, un element bàsic de la modelització dels desplaçaments a la ciutat de Mataró és el Graf de Trams de Carrer (GTC). Aquest graf està format per segments i nodes, cada segment és un tram de carrer (part del carrer entre cruïlles) i els nodes són precisament les cruïlles.

El GTC es pot obtenir de moltes maneres, però en resum hi ha dos orígens bàsics, ad­quirint-lo a una empresa especialitzada (com per exemple Navteq o  TomTom) , on s’inclouran informacions sobre els sentits de circulació en cada via i els girs prohibits i autoritzats en cada nus i moltes altres coses, o bé generant-lo nosaltres mateixos, aquí s’ha optat pel segon cas, més que res per que es vol estudiar més el desplaçament de vianants  que no pas el de vehicles i d’aquesta manera podem afegir i incloure en el GTC trams que no siguin vials de carrer, com ara camins de vianants dins de parcs o zones verdes i recorreguts específics de la gent que va a peu.

Des del punt de vista d’un SIG el GTC està format per un conjunt d’entitats, o classe d’entitat, segons la terminologia del GeoMedia, de tipus lineal, els segments del graf, i un conjunt d’entitats de tipus punt, els nodes. Aquestes entitats lineals han de ser total­ment connexes si es vol navegar al seu través, o sigui, no hi pot haver cap punt de des­connexió o discontinuïtat. També a part de les característiques geomètriques de cada classe d’entitat, línies i punts, cal que hi hagin uns atributs associats a cada element si­gui aquest segment o node.

Quins són aquests atributs?

En primer lloc hi ha d’haver un codi per a cada segment i un codi per a cada node aquests dos codis han d’estar relacionats, és a dir,  dins de cada segment hi ha d’haver informació d’entre quins dos nodes està definit aquell segment en concret, i això per a tots els segments, d’aquesta manera amb aquestes dues llistes la de segments amb els codis dels nodes dels extrems de cada segment i la dels nodes s’estableix la morfologia del graf i es podria calcular una ruta encara que no tinguéssim la imatge geomètrica precisa.

Un altre atribut que podem tenir dins de la taula de segments és sobre l’ orientació o sentit del tram, aquesta orientació és arbitrària i s’agafa en el moment de definir el graf, per tant ens cal saber quin és el node d’origen del tram i quin el node de final del tram, per tant aquests nodes extrems del tram no són qualssevol , un d’ells és des de on parteix el tram i l’altre és a on arriba.

Per la construcció del GTC utilitzem una eina del GeoMedia Transportation Manager que parteix d’una classe d’entitat lineal i ella mateixa et va guiant per acabar obtenint les dues classes d’entitat del graf, els segments i els nodes, automàticament és generen els camps: NodeId en la taula de nodes amb un codi per cada node, i els camps: EdgeId, FromNodeId, ToNodeId en la taula de segments, que ens indiquen el codi de segment, i des de quin node a quin altre node està definit el segment, respectivament. Aquests són els camps principals per la construcció del graf, després n’hi ha uns altres que anirem comentant a continuació. Vegeu a la figura 1 una part dels segments i els nodes del GTC amb els identificadors respectius.

Fig1. Segments i Nodes del GTC amb els codis de EdgeId (vermell) i NodeId (negre)

Si cliquem sobre del tram 1017 obtenim les informacions que es mostren a la figura 2, on es poden comprovar els valors dels atributs EdgeId, FromNodeId i ToNodeId i es pot veure que el tram 1017 efectivament va del node 836 fins al node 837 tal com es veu a la figura 1.

Fig2. Dades del Segment 1017

De la mateixa manera es pot comprovar que hi ha molts altres camps dins dels atributs del tram, fixem-nos de moment en els camps LENGTH i Cost i Cost_invers.

Per què volem el GTC?

Per a dues coses, en primer lloc per a navegar des d’un punt de la ciutat fins a un altre, aquesta navegació ens ha de portar al conjunt de segments concatenats que uneixin el punt inicial amb el punt final segons un determinat criteri d’optimització que podria ser minimitzant la distància o minimitzant alguna altra variable (a la figura 3 es mostren els trajectes a les 3 Escoles Bressol més properes des d’una adreça concreta de la ciutat)  i en segon lloc per desplegar a partir d’un punt el conjunt, ramificat en arbre, de trajectes fins a assolir una determinada distància màxima o un valor màxim d’un altre indicador (vegeu la figura 4)

Fig 3. Trajectes a les 3 Escoles Bressol més properes des d’un punt de la ciutat seguint el GTC. La variable a optimitzar és la distància.

A la figura 4 es pot veure aquesta construcció en arbre, seguin el GTC, a partir de l’entitat: Escola Bressol ‘Les Figueretes’ fins a una distància màxima de 250 m. Com es veu a la figura la progressió fins a assolir els 250 metres pot acabar en un punt entremig del tram.

Fig 4. Arbre corresponent a l’Escola Bressol ‘Les Figueretes’ sobre el GTC (segments i nodes) fins a una distància de 250 m.

Tant en el cas 1, camí o trajecte entre dos punts de la ciutat, com en el cas 2, arbre des­plegat sobre el GTC a partir d’un punt, s’ha utilitzat la distància, el camp LENGTH, de cada segment com a base dels càlculs, això vol dir el camí òptim de distància mínima entre dos punts o el desplegament per la xarxa de trams de carrer fins arribar a fer la distància fixada de 250 m.

Una altra possibilitat seria fer servir una altra variable a minimitzar quan volem definir un camí o a utilitzar quan volem definir un desplegament en arbre, aquesta variable se­ria la que tenim quantificada en els camps Cost i Cost_invers de cada tram. Així com la longitud del tram no depèn de si es recorre en un sentit  o en un altre, en canvi si es tre­balla amb una altra variable, com ara el temps de recorregut del tram, sí que depèn de les característiques específiques de cada tram, com ara el pendent, els obstacles i la ti­pologia (plataforma única, escales, etc.) i en aquest cas té sentit de tenir dos paràmetres per tram, per si es circula en el sentit definit del tram Cost o si es va en sentit contrari Cost_invers. Això pot donar lloc a diferències importants de recorregut o de conjunt de carrers a l’abast si es va de casa a l’Ambulatori o es torna de l’ambulatori, sobretot quan el terreny és accidentat, amb moltes pujades i baixades.

En resum, quan més acurada sigui la informació del GTC, i en concret de cada tram, més es podrà afinar en la cerca de recorreguts òptims i en la definició de les Zones d’Influència a través del graf. De la mateixa manera, la utilització de la variable temps com a funció de cost, ens dona una mesura molt més real de la proximitat o llunyania dels centres proveïdors de serveis al ciutadà però requereix de tenir un bon model de la velocitat en els desplaçaments.

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Segmentació de la Població

 

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

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

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

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

 

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

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

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

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

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

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

 

WFS: Interactuació amb mapes.

Descripció.

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

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

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

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

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

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

Com fer la publicació?

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

Creació del servei.

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

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

Nom del servei.

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

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

Configurant el Geomedia.

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

Botó “settings”.

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

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

Servei inicialitzat.

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

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

Codi GML creat.

Interpretació gràfica del codi GML.

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

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

Nova connexió.

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

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

Ventana de mapa del Geomedia amb les dades.

Entitats agregades de Població

 

Hem vist en anteriors entrades que al final de qualsevol càlcul de proximitat en un sentit o en altre (comptar entitats), arribàvem a veure la població afectada agrupada per illes de cases, cosa que permetia, mitjançant un mapa temàtic, veure les illes on hi havia més o menys gent, que en el cas dels càlculs de proximitat ens  portava a estudiar  les illes que es trobaven a més distància d’un determinat centre o que no en tenien cap a una distància determinada.

Es pot dir que aquesta relació amb la població és el motiu final de molts càlculs i simulacions, ja que la població, en darrera instància és el subjecte principal de l’activitat de la gestió municipal.

Anem a veure una mica en detall com fem aquestes agrupacions dels habitants. L’eina base és el Padro Municipal d’Habitants. En un primer procés s’agafen totes les dades rellevants de la base de dades del Padró, i un cop despersonalitzades, s’inclouen en una taula única, que seria una imatge de la situació del Padró Municipal en un moment determinat, en una data determinada, per tant seria una fotografia que es queda obsoleta immediatament acabada de fer ja que el Padró va canviant en el temps constantment degut a les altes i baixes que es van produint de forma contínua.

Un aspecte important és com situar els habitants en el territori. Nosaltres fem les agregacions dels habitants de tres maneres: càlcul dels habitants que viuen en una  mateixa illa, càlcul dels habitants que viuen en una mateixa parcel·la, i càlcul dels habitants que viuen en el mateix ‘portal’.

Aquesta diferent forma de comptar els habitants correspon al nivell de resolució que ens cal, segons el tipus d’estudi que volem fer. Les illes de Mataró són de l’ordre de 600, les parcel·les, estaríem en unes 12.000 i els portals  (també anomenats números de policia) de l’ordre de 20.000. Per tenir una visió general, no massa precisa, les illes són suficients. Si volem calcular els habitants d’una zona arbitrària de la ciutat  afinarem molt més amb àrees molt més petites com ara les parcel·les, i amb els portals, que per definició no són àrees sinó punts, encara més. Seria com tenir una mateixa fotografia amb uns pixels molt grans (illes) o més petits (parcel·les i portals).

Com podem associar cada habitant amb una illa, una parcel·la o un portal?  D’entrada hem dit que tenim tots els habitants en una única taula, cada fila de la taula és una persona i tant tindrem un total de tantes files com persones. Ara el que cal és un identificador de l’entitat amb la qual volem associar aquest habitant. Si parlem d’illes hi ha una forma única d’identificar cada illa amb un conjunt de tres codis INE (Instituto Nacional de Estadística) : codi de districte censal, i dins de cada districte codi de secció censal i dins de cada secció codi d’illa, tots tres són codis numèrics, i el conjunt de tots tres codis constitueix un identificador únic per una illa de la ciutat de Mataró, el format sol ser D-S-I (districte-secció-illa) per exemple: 5-2-4 que vol dir la illa 4 de la secció 2 del districte 5. Com que cada registre (fila) de la taula tindrà el seu codi D-S-I podrem sumar tots els habitants que tenen un mateix codi, per exemple pel codi 5-2-4 podríem dir que hi ha 235 habitants i així podríem fer una nova taula de dues columnes en la primera tindríem tots els codis d’illa i en la segona els habitants que podem comptar de cada codi. Aquesta seria una primera forma d’agregació dels habitants.

Codificació INE per les Illes: Districte-Secció-Illa
Taula d’agregacions d’habitants per Illa

De la mateixa manera podem tenir en cada registre de la taula general del Padró un identificador únic per la parcel·la que en aquest cas s’anomena codi UTM o Referència Cadastral [set caracters numèrics], aquest codi no existeix per les parcel·les dins de les zones rurals i en aquest cas és substituït per un altre codi que s’anomena CODI_GIS[ nou caracters numèrics]

Codificació per les parcel·les urbanes codi UTM

De la mateixa manera que hem fet la taula d’agregacions per les illes ho faríem per les parcel·les

Agregacions dels habitants per parcel·la

Tal com es pot veure el nombre d’habitants per parcel·la és molt menor que en el cas de les illes, però clar depèn de l’edificació en vertical que hi hagi.

L’agregació per portals o números de policia la faríem en base a un codi que es genera directament de l’adreça postal. El codi NP estaria format per codiCarrer+NumCasa+Lletra, corresponent a cinc caracters numèrics pel codi de carrer, tres pel número de casa, i un per la lletra que si no n’hi ha, que és el normal, es posa una x.

Numeros de Carrer. Codificació CodiCarrer.NumCarrer.Lletra

Com podem veure són els números de carrer que es correspondran amb els portals de les cases i/o les escales. Podem fer l’agregació igual que s’ha fet per les Illes i les parcel·les.

Agregació d’habitants per portal

En resum, d’aquesta manera podem construir les agregacions d’habitants segons la unitat de referència geogràfica que agafem.

Aquesta georeferenciació agregada dels habitants de la ciutat ens pot permetre fer estudis de densitat de població per barris o per àrees concretes de la ciutat, també per carrers, vies i eixos i preveure necessitats de serveis a la població.