Zooplankton abundance and size structure in the North Atlantic from MSM26_126-10

Data on zooplankton abundance and biovolume were collected in concert with data on the biophysical environment at 9 stations in the North Atlantic, from the Iceland Basin in the East to the Labrador Sea in the West. The data were sampled along vertical profiles by a Laser Optical Plankton Counter (LOPC, Rolls Royce Canada Ltd.) that was mounted on a carousel water sampler together with a Conductivity-Temperature-Depth sensor (CTD, SBE19plusV2, Seabird Electronics, Inc., USA) and a fluorescence sensor (F, ECO Puck chlorophyll a fluorometer, WET Labs Inc., USA). Based on the LOPC data, abundance (individuals/m**3) and biovolume (mm3/m**3) were calculated as described in the LOPC Software Operation Manual [(Anonymous, 2006), http://www.brooke-ocean.com/index.html]. LOPC data were regrouped into 49 size groups of equal log10(body volume) increments, see Edvardsen et al. (2002, doi:10.3354/meps227205). LOPC data quality was checked as described in Basedow et al. (2013, doi:10.1016/j.pocean.2012.10.005). Fluorescence was roughly converted into chlorophyll based on filtered chlorophyll values obtained from station 10 in the Labrador Sea. Due to the low number of filtered samples that was used for the conversion the resulting chlorophyll values should be considered with care. CTD data were screened for erroneous (out of range) values and then averaged to the same frequency as the LOPC data (2 Hz). All data were processed using especially developed scripts in the python programming language. The LOPC is an optical instrument designed to count and measure particles (0.1 to 30 mm equivalent spherical diameter) in the water column, see Herman et al., (2004, doi:10.1093/plankt/fbh095). The size of particles as equivalent spherical diameter (ESD) was computed as described in the manual (Anonymous, 2006), and in more detail in Checkley et al. (2008, doi:10.4319/lo.2008.53.5_part_2.2123) and Gaardsted et al. (2010, doi:10.1111/j.1365-2419.2010.00558.x).

Zooplankton abundance and size structure in the North Atlantic from MSM26_133-7

Data on zooplankton abundance and biovolume were collected in concert with data on the biophysical environment at 9 stations in the North Atlantic, from the Iceland Basin in the East to the Labrador Sea in the West. The data were sampled along vertical profiles by a Laser Optical Plankton Counter (LOPC, Rolls Royce Canada Ltd.) that was mounted on a carousel water sampler together with a Conductivity-Temperature-Depth sensor (CTD, SBE19plusV2, Seabird Electronics, Inc., USA) and a fluorescence sensor (F, ECO Puck chlorophyll a fluorometer, WET Labs Inc., USA). Based on the LOPC data, abundance (individuals/m**3) and biovolume (mm3/m**3) were calculated as described in the LOPC Software Operation Manual [(Anonymous, 2006), http://www.brooke-ocean.com/index.html]. LOPC data were regrouped into 49 size groups of equal log10(body volume) increments, see Edvardsen et al. (2002, doi:10.3354/meps227205). LOPC data quality was checked as described in Basedow et al. (2013, doi:10.1016/j.pocean.2012.10.005). Fluorescence was roughly converted into chlorophyll based on filtered chlorophyll values obtained from station 10 in the Labrador Sea. Due to the low number of filtered samples that was used for the conversion the resulting chlorophyll values should be considered with care. CTD data were screened for erroneous (out of range) values and then averaged to the same frequency as the LOPC data (2 Hz). All data were processed using especially developed scripts in the python programming language. The LOPC is an optical instrument designed to count and measure particles (0.1 to 30 mm equivalent spherical diameter) in the water column, see Herman et al., (2004, doi:10.1093/plankt/fbh095). The size of particles as equivalent spherical diameter (ESD) was computed as described in the manual (Anonymous, 2006), and in more detail in Checkley et al. (2008, doi:10.4319/lo.2008.53.5_part_2.2123) and Gaardsted et al. (2010, doi:10.1111/j.1365-2419.2010.00558.x).

Zooplankton abundance and size structure in the North Atlantic from MSM26_137-17

Data on zooplankton abundance and biovolume were collected in concert with data on the biophysical environment at 9 stations in the North Atlantic, from the Iceland Basin in the East to the Labrador Sea in the West. The data were sampled along vertical profiles by a Laser Optical Plankton Counter (LOPC, Rolls Royce Canada Ltd.) that was mounted on a carousel water sampler together with a Conductivity-Temperature-Depth sensor (CTD, SBE19plusV2, Seabird Electronics, Inc., USA) and a fluorescence sensor (F, ECO Puck chlorophyll a fluorometer, WET Labs Inc., USA). Based on the LOPC data, abundance (individuals/m**3) and biovolume (mm3/m**3) were calculated as described in the LOPC Software Operation Manual [(Anonymous, 2006), http://www.brooke-ocean.com/index.html]. LOPC data were regrouped into 49 size groups of equal log10(body volume) increments, see Edvardsen et al. (2002, doi:10.3354/meps227205). LOPC data quality was checked as described in Basedow et al. (2013, doi:10.1016/j.pocean.2012.10.005). Fluorescence was roughly converted into chlorophyll based on filtered chlorophyll values obtained from station 10 in the Labrador Sea. Due to the low number of filtered samples that was used for the conversion the resulting chlorophyll values should be considered with care. CTD data were screened for erroneous (out of range) values and then averaged to the same frequency as the LOPC data (2 Hz). All data were processed using especially developed scripts in the python programming language. The LOPC is an optical instrument designed to count and measure particles (0.1 to 30 mm equivalent spherical diameter) in the water column, see Herman et al., (2004, doi:10.1093/plankt/fbh095). The size of particles as equivalent spherical diameter (ESD) was computed as described in the manual (Anonymous, 2006), and in more detail in Checkley et al. (2008, doi:10.4319/lo.2008.53.5_part_2.2123) and Gaardsted et al. (2010, doi:10.1111/j.1365-2419.2010.00558.x).

Zooplankton abundance and size structure in the North Atlantic from MSM26_131-4

Data on zooplankton abundance and biovolume were collected in concert with data on the biophysical environment at 9 stations in the North Atlantic, from the Iceland Basin in the East to the Labrador Sea in the West. The data were sampled along vertical profiles by a Laser Optical Plankton Counter (LOPC, Rolls Royce Canada Ltd.) that was mounted on a carousel water sampler together with a Conductivity-Temperature-Depth sensor (CTD, SBE19plusV2, Seabird Electronics, Inc., USA) and a fluorescence sensor (F, ECO Puck chlorophyll a fluorometer, WET Labs Inc., USA). Based on the LOPC data, abundance (individuals/m**3) and biovolume (mm3/m**3) were calculated as described in the LOPC Software Operation Manual [(Anonymous, 2006), http://www.brooke-ocean.com/index.html]. LOPC data were regrouped into 49 size groups of equal log10(body volume) increments, see Edvardsen et al. (2002, doi:10.3354/meps227205). LOPC data quality was checked as described in Basedow et al. (2013, doi:10.1016/j.pocean.2012.10.005). Fluorescence was roughly converted into chlorophyll based on filtered chlorophyll values obtained from station 10 in the Labrador Sea. Due to the low number of filtered samples that was used for the conversion the resulting chlorophyll values should be considered with care. CTD data were screened for erroneous (out of range) values and then averaged to the same frequency as the LOPC data (2 Hz). All data were processed using especially developed scripts in the python programming language. The LOPC is an optical instrument designed to count and measure particles (0.1 to 30 mm equivalent spherical diameter) in the water column, see Herman et al., (2004, doi:10.1093/plankt/fbh095). The size of particles as equivalent spherical diameter (ESD) was computed as described in the manual (Anonymous, 2006), and in more detail in Checkley et al. (2008, doi:10.4319/lo.2008.53.5_part_2.2123) and Gaardsted et al. (2010, doi:10.1111/j.1365-2419.2010.00558.x).

Zooplankton abundance and size structure in the North Atlantic from MSM26_135-10

Data on zooplankton abundance and biovolume were collected in concert with data on the biophysical environment at 9 stations in the North Atlantic, from the Iceland Basin in the East to the Labrador Sea in the West. The data were sampled along vertical profiles by a Laser Optical Plankton Counter (LOPC, Rolls Royce Canada Ltd.) that was mounted on a carousel water sampler together with a Conductivity-Temperature-Depth sensor (CTD, SBE19plusV2, Seabird Electronics, Inc., USA) and a fluorescence sensor (F, ECO Puck chlorophyll a fluorometer, WET Labs Inc., USA). Based on the LOPC data, abundance (individuals/m**3) and biovolume (mm3/m**3) were calculated as described in the LOPC Software Operation Manual [(Anonymous, 2006), http://www.brooke-ocean.com/index.html]. LOPC data were regrouped into 49 size groups of equal log10(body volume) increments, see Edvardsen et al. (2002, doi:10.3354/meps227205). LOPC data quality was checked as described in Basedow et al. (2013, doi:10.1016/j.pocean.2012.10.005). Fluorescence was roughly converted into chlorophyll based on filtered chlorophyll values obtained from station 10 in the Labrador Sea. Due to the low number of filtered samples that was used for the conversion the resulting chlorophyll values should be considered with care. CTD data were screened for erroneous (out of range) values and then averaged to the same frequency as the LOPC data (2 Hz). All data were processed using especially developed scripts in the python programming language. The LOPC is an optical instrument designed to count and measure particles (0.1 to 30 mm equivalent spherical diameter) in the water column, see Herman et al., (2004, doi:10.1093/plankt/fbh095). The size of particles as equivalent spherical diameter (ESD) was computed as described in the manual (Anonymous, 2006), and in more detail in Checkley et al. (2008, doi:10.4319/lo.2008.53.5_part_2.2123) and Gaardsted et al. (2010, doi:10.1111/j.1365-2419.2010.00558.x).

Modelación y simulación de la conexión a red de un parque eólico

Se tiene una red eléctrica compuesta por tres centrales térmicas convencionales y dos núcleos de consumo diferenciados, uno industrial y otro residencial, a la que se le va a conectar un parque eólico. El objetivo es dimensionar la línea de conexión y conocer el comportamiento de la red ante este cambio. Se han calculado las características de la línea eléctrica de conexión para satisfacer la potencia instalada del parque. También se ha estimado la demanda horaria de electricidad en las zonas residencial e industrial y se han tomado los valores horarios significativos de la potencia generada por el parque eólico, ambos, para las distintas estaciones del año. Como programa para la simulación de la red eléctrica se utilizó el PSS/E (Power System Simulator for Engineering) en el que, ayudándose del lenguaje de programación Python, se creó un código que cambiaba los datos horarios del consumo y la generación del parque, resolvía el flujo de cargas y exportaba los resultados que mostraban el comportamiento de la red para las distintas casuísticas. Finalmente, se analizaron los resultados de las potencias activa y reactiva generadas por las centrales convencionales, la tensión en los buses y las posibles sobrecargas.

Transforming meteorological data into linked data

This paper describes the process followed in order to make some of the public meterological data from the Agencia Estatal de Meteorología (AEMET, Spanish Meteorological Office) available as Linked Data. The method followed has been already used to publish geographical, statistical, and leisure data. The data selected for publication are generated every ten minutes by the 250 automatic stations that belong to AEMET and that are deployed across Spain. These data are available as spreadsheets in the AEMET data catalog, and contain more than twenty types of measurements per station. Spreadsheets are retrieved from the website, processed with Python scripts, transformed to RDF according to an ontology network about meteorology that reuses the W3C SSN Ontology, published in a triple store and visualized in maps with Map4rdf.

Implementation of wireless communication based on Software Defined Radio

In current communication systems, there are many new challenges like various competitive standards, the scarcity of frequency resource, etc., especially the development of personal wireless communication systems result the new system update faster than ever before, the conventional hardware-based wireless communication system is difficult to adapt to this situation. The emergence of SDR enabled the third revolution of wireless communication which from hardware to software and build a flexible, reliable, upgradable, reusable, reconfigurable and low cost platform. The Universal Software Radio Peripheral (USRP) products are commonly used with the GNU Radio software suite to create complex SDR systems. GNU Radio is a toolkit where digital signal processing blocks are written in C++, and connected to each other with Python. This makes it easy to develop more sophisticated signal processing systems, because many blocks already written by others and you can quickly put them together to create a complete system. Although the main function of GNU Radio is not be a simulator, but if there is no RF hardware components,it supports to researching the signal processing algorithm based on pre-stored and generated data by signal generator. This thesis introduced SDR platform from hardware (USRP) and software(GNU Radio), as well as some basic modulation techniques in wireless communication system. Based on the examples provided by GNU Radio, carried out some related experiments, for example GSM scanning and FM radio station receiving on USRP. And make a certain degree of improvement based on the experience of some investigators to observe OFDM spectrum and simulate real-time video transmission. GNU Radio combine with USRP hardware proved to be a valuable lab platform for implementing complex radio system prototypes in a short time. RESUMEN. Software Defined Radio (SDR) es una tecnología emergente que está creando un impacto revolucionario en la tecnología de radio convencional. Un buen ejemplo de radio software son los sistemas de código abierto llamados GNU Radio que emplean un kit de herramientas de desarrollo de software libre. En este trabajo se ha empleado un kit de desarrollo comercial (Ettus Research) que consiste en un módulo de procesado de señal y un hardaware sencillo. El módulo emplea un software de desarrollo basado en Linux sobre el que se pueden implementar aplicaciones de radio software muy variadas. El hardware de desarrollo consta de un microprocesador de propósito general, un dispositivo programable (FPGA) y un interfaz de radiofrecuencia que cubre de 50 a 2200MHz. Este hardware se conecta al PC por medio de un interfaz USB de 8Mb/s de velocidad. Sobre la plataforma de Ettus se pueden ejecutar aplicaciones GNU radio que utilizan principalmente lenguaje de programación Python para implementarse. Sin embargo, su módulo de procesado de señal está construido en C + + y emplea un microprocesador con aritmética de coma flotante. Por lo tanto, los desarrolladores pueden rápida y fácilmente construir aplicaciones en tiempo real sistemas de comunicación inalámbrica de alta capacidad. Aunque su función principal no es ser un simulador, si no puesto que hay componentes de hardware RF, Radio GNU sirve de apoyo a la investigación del algoritmo de procesado de señales basado en pre-almacenados y generados por los datos del generador de señal. En este trabajo fin de máster se ha evaluado la plataforma de hardware de DEG (USRP) y el software (GNU Radio). Para ello se han empleado algunas técnicas de modulación básicas en el sistema de comunicación inalámbrica. A partir de los ejemplos proporcionados por GNU Radio, hemos realizado algunos experimentos relacionados, por ejemplo, escaneado del espectro, demodulación de señales de FM empleando siempre el hardware de USRP. Una vez evaluadas aplicaciones sencillas se ha pasado a realizar un cierto grado de mejora y optimización de aplicaciones complejas descritas en la literatura. Se han empleado aplicaciones como la que consiste en la generación de un espectro de OFDM y la simulación y transmisión de señales de vídeo en tiempo real. Con estos resultados se está ahora en disposición de abordar la elaboración de aplicaciones complejas.

Interactividad programada en el Game Engine de Blender

Con este proyecto se ha desarrollado una guía introductoria a uno de los aspectos más complejos y especializados de Blender, que es el control de su motor de videojuegos mediante programas escritos en Python. Está orientado a lectores que tienen un conocimiento amplio sobre el manejo de Blender, su interfaz y el funcionamiento de sus diferentes elementos, así como una mínima experiencia en cuanto a programación. Se ha organizado en una parte descriptiva, centrada en el lenguaje Python y en las bases de su uso para programar el motor de videojuegos (Game Engine) de Blender, y otra de práctica guiada, que constituye la mayoría del proyecto, donde se estudian de manera progresiva ejemplos concretos de uso del mismo. En la parte descriptiva se ha tratado tanto el funcionamiento más básico del lenguaje Python, especialmente las características que difieren de otros lenguajes de programación tradicionales, como su relación con Blender en particular, explicando las diferentes partes de la API de Blender para Python, y las posibles estrategias de uso. La parte práctica guiada, dado que esta interacción entre Blender y Python ofrece un rango de posibilidades muy amplio, se ha centrado en tres áreas concretas que han sido investigadas en profundidad: el control del objeto protagonista, de la cámara y la implementación de un mapa de orientación. Todas ellas se han centrado en torno a un ejemplo común, que consiste en un videojuego muy básico, y que, gracias a los ficheros de Blender que acompañan a esta memoria, sirve para apoyar las explicaciones y poder probar su efecto directamente. Por una parte, estos tres aspectos prácticos se han explicado exhaustivamente, y se han llevado hasta un nivel relativamente alto. Asimismo se han intentado minimizar las dependencias, tanto entre ellos como con la escena que se ha usado como ejemplo, de manera que sea sencillo usar los programas generados en otras aplicaciones. Por otra, la mayoría de los problemas que ha sido necesario resolver durante el desarrollo no son específicos de ninguna de las tres áreas, sino que son de carácter general, por lo que sus explicaciones podrán usarse al afrontar otras situaciones. ABSTRACT. This Thesis consists of an introductory guide to one of the most complex and specific parts of Blender, which is the control of its game engine by means of programs coded in Python. The dissertation is orientated towards readers who have a good knowledge of Blender, its interface and how its different systems work, as well as basic programming skills. The document is composed of two main sections, the first one containing a description of Python’s basics and its usage within Blender, and the second consisting of three practical examples of interaction between them, guided and explained step by step. On the first section, the fundamentals of Python have been covered in the first place, focusing on the characteristics that distinguish it from other programming languages. Then, Blender’s API for Python has also been introduced, explaining its different parts and the ways it can be used in. Since the interaction between Blender and Python offers a wide range of possibilities, the practical section has been centered on three particular areas. Each one of the following sections has been deeply covered: how to control the main character object, how to control the camera, and how to implement and control a mini-map. Furthermore, a demonstrative videogame has been generated for the reader to be able to directly test the effect of what is explained in each section. On the one hand, these three practical topics have been thoroughly explained, starting from the basis and gradually taking them to a relatively advanced level. The dependences among them, or between them and the demonstrative videogame, have been minimised so that the scripts or ideas can be easily used within other applications. On the other hand, most of the problems that have been addressed are not exclusively related to these areas, but will most likely appear in different situations, thus enlarging the field in which this Thesis can be used.

Determinación de un modelo de geoide gravimétrico para Puerto Rico como sistema de referencia para las altitudes ortométricas

El geoide, definido como la superficie equipotencial que mejor se ajusta (en el sentido de los mínimos cuadrados) al nivel medio del mar en una determinada época, es la superficie que utilizamos como referencia para determinar las altitudes ortométricas. Si disponemos de una superficie equipotencial de referencia como dátum altimétrico preciso o geoide local, podemos entonces determinar las altitudes ortométricas de forma eficiente a partir de las altitudes elipsoidales proporcionadas por el Sistema Global de Navegación por Satélite (Global Navigation Satellite System, GNSS ). Como es sabido uno de los problemas no resueltos de la geodesia (quizás el más importante de los mismos en la actualidad) es la carencia de un dátum altimétrico global (Sjoberg, 2011) con las precisiones adecuadas. Al no existir un dátum altimétrico global que nos permita obtener los valores absolutos de la ondulación del geoide con la precisión requerida, es necesario emplear modelos geopotenciales como alternativa. Recientemente fue publicado el modelo EGM2008 en el que ha habido una notable mejoría de sus tres fuentes de datos, por lo que este modelo contiene coeficientes adicionales hasta el grado 2190 y orden 2159 y supone una sustancial mejora en la precisión (Pavlis et al., 2008). Cuando en una región determinada se dispone de valores de gravedad y Modelos Digitales del Terreno (MDT) de calidad, es posible obtener modelos de superficies geopotenciales más precisos y de mayor resolución que los modelos globales. Si bien es cierto que el Servicio Nacional Geodésico de los Estados Unidos de América (National Geodetic Survey, NGS) ha estado desarrollando modelos del geoide para la región de los Estados Unidos de América continentales y todos sus territorios desde la década de los noventa, también es cierto que las zonas de Puerto Rico y las Islas Vírgenes Estadounidenses han quedado un poco rezagadas al momento de poder aplicar y obtener resultados de mayor precisión con estos modelos regionales del geoide. En la actualidad, el modelo geopotencial regional vigente para la zona de Puerto Rico y las Islas Vírgenes Estadounidenses es el GEOID12A (Roman y Weston, 2012). Dada la necesidad y ante la incertidumbre de saber cuál sería el comportamiento de un modelo del geoide desarrollado única y exclusivamente con datos de gravedad locales, nos hemos dado a la tarea de desarrollar un modelo de geoide gravimétrico como sistema de referencia para las altitudes ortométricas. Para desarrollar un modelo del geoide gravimétrico en la isla de Puerto Rico, fue necesario implementar una metodología que nos permitiera analizar y validar los datos de gravedad terrestre existentes. Utilizando validación por altimetría con sistemas de información geográfica y validación matemática por colocación con el programa Gravsoft (Tscherning et al., 1994) en su modalidad en Python (Nielsen et al., 2012), fue posible validar 1673 datos de anomalías aire libre de un total de 1894 observaciones obtenidas de la base de datos del Bureau Gravimétrico Internacional (BGI). El aplicar estas metodologías nos permitió obtener una base de datos anomalías de la gravedad fiable la cual puede ser utilizada para una gran cantidad de aplicaciones en ciencia e ingeniería. Ante la poca densidad de datos de gravedad existentes, fue necesario emplear un método alternativo para densificar los valores de anomalías aire libre existentes. Empleando una metodología propuesta por Jekeli et al. (2009b) se procedió a determinar anomalías aire libre a partir de los datos de un MDT. Estas anomalías fueron ajustadas utilizando las anomalías aire libre validadas y tras aplicar un ajuste de mínimos cuadrados por zonas geográficas, fue posible obtener una malla de datos de anomalías aire libre uniforme a partir de un MDT. Tras realizar las correcciones topográficas, determinar el efecto indirecto de la topografía del terreno y la contribución del modelo geopotencial EGM2008, se obtuvo una malla de anomalías residuales. Estas anomalías residuales fueron utilizadas para determinar el geoide gravimétrico utilizando varias técnicas entre las que se encuentran la aproximación plana de la función de Stokes y las modificaciones al núcleo de Stokes, propuestas por Wong y Gore (1969), Vanicek y Kleusberg (1987) y Featherstone et al. (1998). Ya determinados los distintos modelos del geoide gravimétrico, fue necesario validar los mismos y para eso se utilizaron una serie de estaciones permanentes de la red de nivelación del Datum Vertical de Puerto Rico de 2002 (Puerto Rico Vertical Datum 2002, PRVD02 ), las cuales tenían publicados sus valores de altitud elipsoidal y elevación. Ante la ausencia de altitudes ortométricas en las estaciones permanentes de la red de nivelación, se utilizaron las elevaciones obtenidas a partir de nivelación de primer orden para determinar los valores de la ondulación del geoide geométrico (Roman et al., 2013). Tras establecer un total de 990 líneas base, se realizaron dos análisis para determinar la 'precisión' de los modelos del geoide. En el primer análisis, que consistió en analizar las diferencias entre los incrementos de la ondulación del geoide geométrico y los incrementos de la ondulación del geoide de los distintos modelos (modelos gravimétricos, EGM2008 y GEOID12A) en función de las distancias entre las estaciones de validación, se encontró que el modelo con la modificación del núcleo de Stokes propuesta por Wong y Gore presentó la mejor 'precisión' en un 91,1% de los tramos analizados. En un segundo análisis, en el que se consideraron las 990 líneas base, se determinaron las diferencias entre los incrementos de la ondulación del geoide geométrico y los incrementos de la ondulación del geoide de los distintos modelos (modelos gravimétricos, EGM2008 y GEOID12A), encontrando que el modelo que presenta la mayor 'precisión' también era el geoide con la modificación del núcleo de Stokes propuesta por Wong y Gore. En este análisis, el modelo del geoide gravimétrico de Wong y Gore presento una 'precisión' de 0,027 metros en comparación con la 'precisión' del modelo EGM2008 que fue de 0,031 metros mientras que la 'precisión' del modelo regional GEOID12A fue de 0,057 metros. Finalmente podemos decir que la metodología aquí presentada es una adecuada ya que fue posible obtener un modelo del geoide gravimétrico que presenta una mayor 'precisión' que los modelos geopotenciales disponibles, incluso superando la precisión del modelo geopotencial global EGM2008. ABSTRACT The geoid, defined as the equipotential surface that best fits (in the least squares sense) to the mean sea level at a particular time, is the surface used as a reference to determine the orthometric heights. If we have an equipotential reference surface or a precise local geoid, we can then determine the orthometric heights efficiently from the ellipsoidal heights, provided by the Global Navigation Satellite System (GNSS). One of the most common and important an unsolved problem in geodesy is the lack of a global altimetric datum (Sjoberg, 2011)) with the appropriate precision. In the absence of one which allows us to obtain the absolute values of the geoid undulation with the required precision, it is necessary to use alternative geopotential models. The EGM2008 was recently published, in which there has been a marked improvement of its three data sources, so this model contains additional coefficients of degree up to 2190 and order 2159, and there is a substantial improvement in accuracy (Pavlis et al., 2008). When a given region has gravity values and high quality digital terrain models (DTM), it is possible to obtain more accurate regional geopotential models, with a higher resolution and precision, than global geopotential models. It is true that the National Geodetic Survey of the United States of America (NGS) has been developing geoid models for the region of the continental United States of America and its territories from the nineties, but which is also true is that areas such as Puerto Rico and the U.S. Virgin Islands have lagged behind when to apply and get more accurate results with these regional geopotential models. Right now, the available geopotential model for Puerto Rico and the U.S. Virgin Islands is the GEOID12A (Roman y Weston, 2012). Given this need and given the uncertainty of knowing the behavior of a regional geoid model developed exclusively with data from local gravity, we have taken on the task of developing a gravimetric geoid model to use as a reference system for orthometric heights. To develop a gravimetric geoid model in the island of Puerto Rico, implementing a methodology that allows us to analyze and validate the existing terrestrial gravity data is a must. Using altimetry validation with GIS and mathematical validation by collocation with the Gravsoft suite programs (Tscherning et al., 1994) in its Python version (Nielsen et al., 2012), it was possible to validate 1673 observations with gravity anomalies values out of a total of 1894 observations obtained from the International Bureau Gravimetric (BGI ) database. Applying these methodologies allowed us to obtain a database of reliable gravity anomalies, which can be used for many applications in science and engineering. Given the low density of existing gravity data, it was necessary to employ an alternative method for densifying the existing gravity anomalies set. Employing the methodology proposed by Jekeli et al. (2009b) we proceeded to determine gravity anomaly data from a DTM. These anomalies were adjusted by using the validated free-air gravity anomalies and, after that, applying the best fit in the least-square sense by geographical area, it was possible to obtain a uniform grid of free-air anomalies obtained from a DTM. After applying the topographic corrections, determining the indirect effect of topography and the contribution of the global geopotential model EGM2008, a grid of residual anomalies was obtained. These residual anomalies were used to determine the gravimetric geoid by using various techniques, among which are the planar approximation of the Stokes function and the modifications of the Stokes kernel, proposed by Wong y Gore (1969), Vanicek y Kleusberg (1987) and Featherstone et al. (1998). After determining the different gravimetric geoid models, it was necessary to validate them by using a series of stations of the Puerto Rico Vertical Datum of 2002 (PRVD02) leveling network. These stations had published its values of ellipsoidal height and elevation, and in the absence of orthometric heights, we use the elevations obtained from first - order leveling to determine the geometric geoid undulation (Roman et al., 2013). After determine a total of 990 baselines, two analyzes were performed to determine the ' accuracy ' of the geoid models. The first analysis was to analyze the differences between the increments of the geometric geoid undulation with the increments of the geoid undulation of the different geoid models (gravimetric models, EGM2008 and GEOID12A) in function of the distance between the validation stations. Through this analysis, it was determined that the model with the modified Stokes kernel given by Wong and Gore had the best 'accuracy' in 91,1% for the analyzed baselines. In the second analysis, in which we considered the 990 baselines, we analyze the differences between the increments of the geometric geoid undulation with the increments of the geoid undulation of the different geoid models (gravimetric models, EGM2008 and GEOID12A) finding that the model with the highest 'accuracy' was also the model with modifying Stokes kernel given by Wong and Gore. In this analysis, the Wong and Gore gravimetric geoid model presented an 'accuracy' of 0,027 meters in comparison with the 'accuracy' of global geopotential model EGM2008, which gave us an 'accuracy' of 0,031 meters, while the 'accuracy ' of the GEOID12A regional model was 0,057 meters. Finally we can say that the methodology presented here is adequate as it was possible to obtain a gravimetric geoid model that has a greater 'accuracy' than the geopotential models available, even surpassing the accuracy of global geopotential model EGM2008.

Ampliación y mejora de aplicativo de análisis forense de imágenes

Ampliación de software dedicado al análisis de imágenes mediante la introducción de nuevas opciones en el procesamiento de video digital, mejoras en la interacción con el usuario. Para ello se ha estudiado el funcionamiento de la aplicación, integrando el lenguaje Python como herramienta de gestión y ejecución de la aplicación. En esta parte de la aplicación se ha integrado: - Traducción de la UI a una versión castellana. - Modificación y eliminación de cualquier filtro añadido para el procesamiento de video, no únicamente el último. - Descripciones de puntero y en la barra de estado de elementos de la aplicación. - Iconos en la barra de herramientas de los filtros añadidos más importantes. Por la otra parte, la del tratamiento digital de video, Avisynth se dispone como el eje de estudio, el cuál ejecuta sobre lenguaje de bajo nivel (C++) las operaciones pertinentes a través de librerías de enlace dinámico o *.dll. Las nuevas funcionalidades son: Convolución matricial, filtro de media adaptativa, DCT, ajustes de video generales, en formato RGB o YUV, rotaciones, cambios de perspectiva y filtrado en frecuencia. ABSTRACT. Improvement about a digital image processing software, creating new options in digital video processing or the user interaction. For this porpuse, we have integrated the application language,Python, as the tool to the application management and execution. In this part of the application has been integrated: - Translation of the UI: Spanish version. - Modifying and removing any added filter for video processing, not just the last. - Descriptions for the pointer and the status bar of the application. - New icons on the toolbar of the most important filters added. On the other hand, Avisynth was used tool for the digital video processing, which runs on low-level language (C ++) for a quickly and to improve the video operations. The new introduced filters are: Matrix Convolution, adaptive median filter, DCT, general video settings on RGB or YUV format, rotations, changes in perspective and frequency filtering.

Análisis de imágenes del rostro humano

El objetivo general de este trabajo es el correcto funcionamiento de un sistema de reconocimiento facial compuesto de varios módulos, implementados en distintos lenguajes. Uno de dichos módulos está escrito en Python y se encargarí de determinar el género del rostro o rostros que aparecen en una imagen o en un fotograma de una secuencia de vídeo. El otro módulo, escrito en C++, llevará a cabo el reconocimiento de cada una de las partes de la cara (ojos, nariz, boca) y la orientación hacia la que está posicionada (derecha, izquierda). La primera parte de esta memoria corresponde a la reimplementación de todas las partes de un analizador facial, que constituyen el primer módulo antes mencionado. Estas partes son un analizador, compuesto a su vez por un reconocedor (Tracker) y un procesador (Processor), y una clase visor para poder visualizar los resultados. Por un lado, el reconocedor o "Tracker.es el encargado de encontrar la cara y sus partes, que serán pasadas al procesador o Processor, que analizará la cara obtenida por el reconocedor y determinará su género. Este módulo estaba dise~nado completamente en C y OpenCV 1.0, y ha sido reescrito en Python y OpenCV 2.4. Y en la segunda parte, se explica cómo realizar la comunicación entre el primer módulo escrito en Python y el segundo escrito en C++. Además, se analizarán diferentes herramientas para poder ejecutar código C++ desde programas Python. Dichas herramientas son PyBindGen, Cython y Boost. Dependiendo de las necesidades del programador se contará cuál de ellas es más conveniente utilizar en cada caso. Por último, en el apartado de resultados se puede observar el funcionamiento del sistema con la integración de los dos módulos, y cómo se muestran por pantalla los puntos de interés, el género y la orientación del rostro utilizando imágenes tomadas con una cámara web.---ABSTRACT---The main objective of this document is the proper functioning of a facial recognition system composed of two modules, implemented in diferent languages. One of these modules is written in Python, and his purpose is determining the gender of the face or faces in an image or a frame of a video sequence. The other module is written in C ++ and it will perform the recognition of each of the parts of the face (eyes, nose , mouth), and the head pose (right, left).The first part of this document corresponds to the reimplementacion of all components of a facial analyzer , which constitute the first module that I mentioned before. These parts are an analyzer , composed by a tracke) and a processor, and a viewer to display the results. The tracker function is to find and its parts, which will be passed to the processor, which will analyze the face obtained by the tracker. The processor will determine the face's gender. This module was completely written in C and OpenCV 1.0, and it has been rewritten in Python and OpenCV 2.4. And in the second part, it explains how to comunicate two modules, one of them written in Python and the other one written in C++. Furthermore, it talks about some tools to execute C++ code from Python scripts. The tools are PyBindGen, Cython and Boost. It will tell which one of those tools is better to use depend on the situation. Finally, in the results section it is possible to see how the system works with the integration of the two modules, and how the points of interest, the gender an the head pose are displayed on the screen using images taken from a webcam.

Sistema de gestión de rankings deportivos V6: funcionalidades avanzadas

El trabajo realizado en este Trabajo de Fin de Grado (en adelante, TFG) consiste en la inclusión de nuevas funcionalidades avanzadas a la última versión del Sistema de Gestión de Rankings de carreras de orientación. El proyecto, actualmente en fase de explotación, es un sistema de clasificación y manejo de diferentes tipos de rankings para las carreas de orientación a pie de la FEDO1. Por medio de este ranking, se determina la clasificación global de los distintos corredores federados dentro de cada categoría, a través de diferentes parámetros de entrada que establecen la funcionalidad del ranking. En cuanto al trabajo realizado en este TFG, se trata de la implementación de la siguiente versión del sistema (versión 6). En esta nueva versión se ha querido incluir nuevas funcionalidades requeridas por los miembros de la federación, así como mejora de otras que no funcionan correctamente. El primer punto del trabajo fue el de comprender y familiarizarme con la herramienta ya implementada hasta el momento, así como aprender un nuevo lenguaje de programación desconocido hasta la fecha para mí; Python. Una de las primeras modificaciones realizadas, sobre las versiones anteriores, es la modificación del Sistema de Gestión de Rankings para los organizadores de carreras. Los organizadores de las carreras obtienen una recompensa de puntos por la organización de carreras, lo que significa un punto de gran importancia para el sistema. Esta funcionalidad no funcionaba correctamente en las versiones anteriores, de manera se tuvo que rehacer desde cero con las especificaciones necesarias. Otro requisito necesario fue modificar los requisitos para el cálculo de las nuevas medias de corredores, permitiendo el cálculo de la misma de forma continua o solo cuando se cumplan todos los requisitos. Respecto a la versión anterior, existía un problema con los accesos a los directorios de cada ranking. En caso de introducir los valores iniciales del ranking desde una carpeta diferente al directorio raíz de la aplicación, el sistema no realizaba correctamente la búsqueda de archivos en el directorio de ranking. De esta manera, había que modificar todo el código implementado para que todas las búsquedas se realizaran sobre el directorio de cada ranking. A continuación, se incluyó una nueva funcionalidad para el ranking individual de los corredores. Esta nueva funcionalidad permite la inclusión de una nueva opción de cálculo de puntuaciones para el ranking individual, a través de un fichero de entrada de puntuaciones que determinase las puntuaciones de los corredores exactas. Durante toda la fase del proyecto se ha tenido que añadir otra serie de especificaciones en la aplicación, las cuales serán explicadas en esta memoria. En definitiva, el trabajo realizado se ha basado en la mejora de una aplicación que gestiona rankings deportivos, de manera que esta versión se acercase lo máximo posible a la versión final de la aplicación.---ABSTRACT---The work done during these months is based on the addition of new advanced functionalities to the last version of the "Sistema de Gestión de Rankings" of orientation races. The project, now in phase of operation, is based on a classification system and management of different types of rankings for walk orienteering of the FEDO. Through this ranking, the global classification of the federal runners in each category is determinated, through various input parameters which establish the functionality of the ranking. Talking about the work done, it consist in the implementation of a new system version (version 6). This new version include new required functionalities by the members of the federation, as well as improving others that were working wrong. The first point of the project was to understand and become familiar with the tool already implemented in that moment, as well as learn a new programming language unknown to date for me; Python. One of the first changes made on previous versions, was the modification of the system for races organizers. The races organizers obtained a reward of points for the organized race, which means a point of great important for the system. This functionality didn't work correctly in previous versions, so was essential to redo it from zero with the required specifications. Another requirement was the addition of a new option for calculating the average of organizers, allowing calculation of it at all times. In the previous version, there was a problem with the access to directories of each ranking. In case of introduce the initial values of the ranking from a different folder to the root directory of the application, the system didn't perform correctly the finding of files in the directory of the ranking. So check all the implemented code for all searches were carried out on each ranking directory.Then a new functionality was included for the individual ranking of runners. This new feature is the inclusion of a new option to calculate scores for the individual ranking, through an input file that determinates exact scores for the runners. Throughout the project phase the addition of another set of specifications in the application was important, which will be explained in this memory. In short, the work done has been based on improving of an application that manage sport rankings, so this version could approach as much as possible to the final version of the application.

Dashboard configurable para la gestión y administración de una instancia de OpenStack

En este documento está descrito detalladamente el trabajo realizado para completar todos objetivos marcados para este Trabajo de Fin de Grado, que tiene como meta final el desarrollo de un dashboard configurable de gestión y administración para instancias de OpenStack. OpenStack es una plataforma libre y de código abierto utilizada como solución de Infraestructura como Servicio (Infrastructure as a Service, IaaS) en clouds tanto públicos, que ofrecen sus servicios cobrando el tiempo de uso o los recursos utilizados, como privados para su utilización exclusiva en el entorno de una empresa. El proyecto OpenStack se inició como una colaboración entre la NASA y RackSpace, y a día de hoy es mantenido por las empresas más potentes del sector tecnológico a través de la Fundación OpenStack. La plataforma OpenStack permite el acceso a sus servicios a través de una Interfaz de Linea de Comandos (Command Line Interface, CLI), una API RESTful y una interfaz web en forma de dashboard. Esta última es ofrecida a través del servicio Horizon. Este servicio provee de una interfaz gráfica para acceder, gestionar y automatizar servicios basados en cloud. El dashboard de Horizon presente algunos problemas como que: solo admite opciones de configuración mediante código Python, lo que hace que el usuario no tenga ninguna capacidad de configuración y que el administrador esté obligado a interactuar directamente con el código. no tiene soporte para múltiples regiones que permitan que un usuario pueda distribuir sus recursos por distintos centros de datos en diversas localizaciones como más le convenga. El presente Trabajo de Fin de Grado, que es la fase inicial del proyecto FI-Dash, pretende solucionar estos problemas mediante el desarrollo de un catálogo de widget de la plataformaWireCloud que permitirán al usuario tener todas las funcionalidades ofrecidas por Horizon a la vez que le ofrecen capacidades de configuración y añaden funcionalidades no presentes en Horizon como el soporte de múltiples regiones. Como paso previo al desarrollo del catálogo de widgets se ha llevado a cabo un estudio de las tecnologías y servicios ofrecidos por OpenStack, así como de las herramientas que pudieran ser necesarias para la realización del trabajo. El proceso de desarrollo ha sido dividido en distintas fases de acuerdo con los distintos componentes que forman parte del dashboard cada uno con una funcion de gestion sobre un tipo de recurso distinto. Las otras fases del desarrollo han sido la integración completa del dashboard en la plataforma WireCloud y el diseño de una interfaz gráfica usable y atractiva.---ABSTRACT---Throughout this document it is described the work performed in order to achieve all of the objectives set for this Final Project, which has as its main goal the development of a configurable dashboard for managing and administrating OpenStack instances. OpenStack is a free and open source platform used as Infrastructure as a Service (IaaS) for both public clouds, which offer their services through payments on time or resources used, and private clouds for use only in the company’s environment. The OpenStack project started as a collaboration between NASA and Rackspace, and nowadays is maintained by the most powerful companies in the technology sector through the OpenStack Foundation. The OpenStack project provides access to its services through a Command Line Interface (CLI), a RESTful API and a web interface as dashboard. The latter is offered through a service called Horizon. This service provides a graphical interface to access, manage and automate cloud-based services. Horizon’s dashboard presents some problems such as: Only supports configuration options using Python code, which grants the user no configuration capabilities and forces the administrator to interact directly. No support for multiple regions that allow a user to allocate his resources by different data centers in different locations at his convenience. This Final Project, which is the initial stage of the FI-Dash project, aims to solve these problems by developing a catalog of widgets for the WireCloud platform that will allow the user to have all the features offered by Horizon while offering configuration capabilities and additional features not present in Horizon such as support for multiple regions. As a prelude to the development of the widget catalog, a study of technologies and services offered by OpenStack as well as tools that may be necessary to carry out the work has been conducted. The development process has been split in phases matching the different components that are part of the dashboard, having each one of them a function of management of one kind of resource. The other development phases have been the achieving of full integration with WireCloud and the design of a graphical interface that is both usable and atractive.

Utilización de métodos de visión artificial para PC como apoyo en la automoción

La detección de los bordes de líneas en la carretera es una parte muy importante en los sistemas inteligentes de transportación, así como la detección de objetos tal como vehículos, con la finalidad de informar o prevenir a través de una alerta al conductor o al sistema informático. De aquí nace el interés de analizar algunos métodos de visión artificial (VA) que es un subcampo de la inteligencia artificial, cuyo propósito es programar un computador y que este “entienda” una escena o imagen, algunos de los métodos más comunes en la detección de líneas y vehículos (considerados objetos en nuestra investigación) son la transformada de Hough, el método de Canny, clasificador Haar Cascade, filtros de Fourier, etc. Se desarrollará una aplicación de escritorio o PC (Personal Computer) para el reconocimiento de vehículos y las líneas de bordes, el lenguaje de programación utilizado será Python y la biblioteca OpenCV que contiene más de 500 funciones en el campo de visión por computador. La validación del reconocimiento de objetos se la realizará con una prueba de campo. Este resultado apoyará a la automoción (máquina que se desplaza por acción de un motor como el vehículo) con datos que luego pueden ser procesados.