IMPLEMENTACIÓN APP TAXIS

BRASIL

BRATAX
1 Alcance General Hardware
Para llevar a buen termino, la implementación de la app de georeferenciación de taxis, es
necesario segmentar la solución en diferentes capas, a saber:
• Servidores
• Aplicación
• Distribución

1.1 Servidores
La solución a implementar, con respecto a los requerimientos físicos, se va a utilizar el modelo de
load balancers (imagen 1), y cluster de servidores, ya que nos permite escalar horizontalmente
(agregando o retirando nodos al cluster - elástico), de manera simple, rápida y automatizada,
según los requerimientos del sistema.

Inicialmente, se requiere una disponibilidad para

100k usuarios, lo que necesita cumplir con algunos
aspectos básicos, para obtener un servidor con
disponibilidad de 2 o 3 nueves.

Imagen 1

Availability % Downtime in Minutes Downtime per Year Vendor Jargon

90 52,560.00 36.5 days one nine
99 5,256.00 4 days two nines
99.9 525.60 8.8 hours three nines
99.99 52.56 53 minutes four nines
99.999 5.26 5.3 minutes five nines
99.9999 0.53 32 seconds six nines
Tabla 1
La tabla 1, nos muestra el estándar de los tipos de servidores, con relación a su disponibilidad
anual.
Para que la app funcione correctamente, se requiere de servidores para: Web Server, Base de
Datos, Load Balancer, Firewall, DNS.
En la imagen 2 , podemos observar, una posible implementación de un cluster, con load balancer
varios servidores, que al usuario final, se le presentan como 1 sola aplicación, en este caso,
cuando un usuario accede al servidor validando sesión, esta se almacena en un solo origen, y no
importa cual nodo responda a dicha solicitud el usuario se mantendrá “logueado” en el sistema.
El origen de la sesión, se podría almacenar en otro cluster, inclusive.

Imagen 2

En la imagen 3, vemos los requerimientos mínimos para el funcionamiento de un cluster

elástico, que funcionaría como un servidor web a la vista del público. Internamente, estaría
compuesto por 1 load balancer, 2 servidores web, 1 servidor de base de datos, y 1 servidor para
sistema de almacenamiento de archivos. El switch, conectaría de manera eficiente todos los
servidores anteriores entre ellos, al menos 10Gbps, por último, el enrutador, para acceder a
internet. Todos estos sistemas, podría ser clusters, cada uno de ellos.

Imagen 3
La imagen 4, nos muestra una implementación óptima para iniciar un sistema de producción al
público, se le han agregado servidores de soporte para todas las aplicaciones, lo que mejoraría la
disponibilidad de manera exponencial.

Imagen 4

1.2 Requerimientos de hardware

Un cálculo aproximado de los requerimientos mínimos para cada tipo de servidor en este
sistema.
1.2.1 Load Balancers
• Intel Dual Core Processor con la mayor velocidad posible
• Red 8 X GbE Auto-negotiating, Full Duplex ports
• 50GB HDD
• 8 GB RAM
Lo más importante para los load balancers, es la comunicación en red de alta calidad, una buena
tarjeta de red de al menos 2xGb; la RAM como mínimo deben ser 4Gb; y el espacio de disco, es
una exageración, porque lo requerido es básicamente para logs del sistema, con unas pocas gigas,
sería suficiente.

1.2.2 Servidores Web

Aunque este punto, solo se puede definir al probar la aplicación en cuestión, los requisitos para el
buen funcionamiento de una aplicación web estándar, lo que más puede variar es el uso de la cpu
en un servidor apache requieren como mínimo:
• Procesador Dual Core 2 x 1,6 GHz / QuadCore 4 x 1,6 Ghz
• 8-32 GB RAM
• Entre 15GB y 250GB preferiblemente SSD
Esta solución, es muy borrosa, porque nuestra app requiere un mapserver, y depende enteramente
del tamaño del mapa que se va a cargar, y del zoom que se pueda realizar en dicho mapa, aunque
lo mejor para esta definición es hacer las pruebas con la app funcionando completamente. Para
poder manejar usuarios por miles, creo se deberá empezar con una CPU mucho más poderosa,
8x, o 12x, pero no mucho más. Y la RAM, como mínimo 64GB

1.2.3 Base de Datos

Este punto es vital para nuestra app, porque además de las consultas clásicas de texto y/o
numéricas, se van a realizar consultas de tipo geográfico, y este aplicativo, recae principalmente
en este tipo de consultas, así que la inversión grande en servidores, debe ser en esta área, aunque
ocurre igual que los sevidores web, en las pruebas es donde podemos dimensionar mucho mejor
los requerimientos, pero como mínimo se necesita:
• 32 GB RAM
• 700 GB HDD – recomendado SSD
 • 8-12 core CPU

1.2.4 Sistema de archivos

Los requerimientos para el sistema de almacenamiento están, obviamente enfocados en el espacio
de disco, esta app, no va a necesitar mucho almacenamiento, más allá del uso que genere el
sistema operativo, sobre todo las bases de datos, pero no existen usuarios almacenando
contenidos en el servidor; como mínimo se recomienda:
• DualCore 2 x 1,6 Ghz 64
• Aprox 1GB de RAM, por TeraByte de almacenamiento de disco.
• Varios HDD, Varios SSD
• 2x 1GB Ethernet NICs

imagen 5
2 Alcance Aplicación
El desarrollo de la app, será realizado en el lenguaje Node JS, cumpliendo los estándares
modernos de la industria, como son: REST API, y PWA.

2.1 REST API

Se implementará la API, sobre el framework Express, de Node JS.

2.2 PWA
Progressive Web Application, es un conjunto de técnicas, para desarrollar la interfaz gráfica de las
apps, y que estas se instalen fácilmente, sobre cualquier plataforma (PC, android, Mac), sin
necesidad de sistemas de distribución de contenido, como el appstore.

2.3 Procedimiento
Para llevar este proyecto a buen termino, se deben seguir los siguientes pasos para el desarrollo de
la app en cuestión:
• Levantamiento de información
• Desarrollo de Aplicativo
• Puesta en producción

2.3.1 Levantamiento de Información

Etapa en la que desarrolladores y solicitantes, se ponen de acuerdo en las prestaciones y funciones
que debe cumplir exactamente la aplicación, se recopilan datos y documentación requeridos para
el desarrollo. Tiene una duración aproximada de 1 a 2 semanas, en donde también se escogen las
tecnologías que se utilizaran en el desarrollo final.

2.3.2 Desarrollo Aplicativo

En esta fase del proyecto, los desarrolladores ponen en marcha la solución planteada en el paso 1,
se instalan servidores de prueba, para monitorear el avance del aplicativo cuando ya esté en un
punto de revisión. Esta etapa, tiene una duración de 4 a 5 semanas, donde la última de estas, se
dedica a pruebas y correcciones de las funciones.
2.3.3 Puesta en Producción
Luego de superada la etapa de pruebas, se implementan los servidores definitivos, se instalan los
requerimientos de software para un correcto funcionamiento de la plataforma, incluye, servidores
de correo, seguridad, configuración de red, etc. La duración de esta etapa es de 1 a 2 semanas.

2.3.4 Cronograma
3 Estructura General de la Aplicación

Imagen 6
Para el correcto funcionamiento de la aplicación BRATAX, se requiere de los siguientes
componentes, y las librerías necesarias para que cada uno de ellos funcione de manera adecuada.

3.1 BRATAX API Server V1

3.1.1 Lenguaje de programación
Se utilizará el lenguaje Javascript, Node JS version LTS (10.15.2).
Consultas de la base de datos se utilizará SQL. No ORM.

3.1.2 Base de datos

Postgresql con extensión Postgis.
Redis in memory database, para caches, jobs, y queues.

3.1.3 Microservicios
El servidor API de BRATAX, requiere varios servicios adicionales para cumplir con funciones
específicas, estas deben ejecutar de manera sincronizada, para así garantizar una experiencia
fluida del cliente web. Estos servicios incluyen: servidor de mapas local, servicios de enrutado,
para decidir que camino tomar dentro del mapa, y geo-codificador, para convertir puntos
geográficos en direcciones legibles por humanos, y viceversa.

3.1.3.1 Servidor de mapas

Se requiere la instalación del servidor Geoserver, para administrar las imágenes para mapas, y
datos geo-espaciales requeridos por la app BRATAX, para el funcionamiento de aplicaciones de
mapas interactivos en la web. Para instalar y configurar, favor dirigirse a:
https://docs.geoserver.org/stable/en/user/installation/index.html#installation. Esta solución, requiere de
un entorno java JRE instalado, incluyendo el servidor tomcat, o Jboss. Leer apéndice B. Además,
ofrece el servicio de REST API, para que nuestros otros componentes, solo requieran de utilizar
un cliente http como axios. La implementación en general, es un proceso más complejo, pero el
funcionamiento y servicio final, nos simplifica el desarrollo de manera importante.

3.1.3.2 Routing
El servicio que nos permite trazar la ruta más corta, por las vías de una red de carreteras
permitidas de un mapa, es fundamental para el correcto funcionamiento de la app BRATAX, por
tal motivo, se necesita de un servidor que cumpla con dicha funcionalidad, en las pruebas
realizadas con varias soluciones, se ha llegado a la conclusión de utilizar el enrutador Project
OSRM, para mayor información: http://project-osrm.org. Ver apéndice C. Project OSRM, está
desarrollado en C++, y tiene soporte para NodeJS. El servidor de enrutado nos permite trazar el
camino en el mapa, por donde el taxista debe dirigirse, generando además instrucciones de
navegación al estilo GPS, que pueden ser leidas por un TTS.

3.1.3.3 Geocoder
Cuando los usuarios solicitan un servicio de taxi, lo más probable es que utilicen una o más
direcciones, estas direcciones, se deben convertir en datos geográficos, para que la API pueda
funcionar con ellas, a este procedimiento se le conoce como geocoder. Cuándo en una aplicación,
se pone un punto sobre un mapa existente, el usuario necesita saber a qué dirección física se
refiere, para tal fin, se realiza el proceso conocido como geocoder inverso, en donde el sistema
convierte ese punto geográfico [latitud, longitud], en una dirección legible, como calle 3 # 5-55,
inclusive, permite utilizar puntos de interes, en vez de direcciones, por ejemplo el usuario podría
solicitar un servicio para ir a “Areopuerto El Robado”, el geocoder, debe convertir ese lugar
reconocido, en una dirección o en un punto geográfico. La solución escogida, para que cumpla
con esta funcionalidad, es Nominatim, que es en general un motor de búsqueda de los datos de
openstreetmap, y permite realizar geocoder, y geocoder inverso. Para más información
https://nominatim.org. Para el correcto funcionamiento de este servicio, se requiere de un servidor
web, por ejemplo apache, y de la base de datos Postgresql. Ver apéndice D.

3.2 Bratax App Cliente

El cliente de la API BRATAX v1, debe tener soporte para funcionar en dispositivos móviles, con
sistema operativo androide, con dispositivos de apple, y en navegador web en general, por
ejemplo firefox, chrome y safari. Con respecto al desarrollo, como se explica en el punto 2.2, se
utilizará el concepto PWA, que solo requiere de lenguajes estándar, como: HTML, CSS,
Javascript, además evita tener que utilizar muchas librerías de los framework de apple o androide,
simplemente, generando un paquete con un webkit view, con soporte de javascript, apuntando
al servidor donde se aloja la PWA. Todas las funcionalidades, se ejecutan a través del servidor
API, apuntando a los endpoints definidos en las rutas de dicha API, Por ejemplo:
GET /login, nos muestra una vista, con el formulario de usuario y clave, o POST
/solicitaServicio, nos permitiría enviar datos al API server, para que la plataforma encuentre un
taxista disponible.

3.2.1 Requerimientos de software

Como este componente de la aplicación, es el que maneja las vistas, pantallazos, o actividades,
como se dice en androide, es necesario utilizar librerías enfocadas a este punto, que manejen
formularios, obviamente javascript, y se pueda comunicar con la API, por tal motivo,
utilizaremos un paquete de última tecnología conocido como VUE.js, con esta librería, se
pueden manejar formularios reactivos, es decir, que se puedan alimentar en tiempo real, sin
necesidad de recargar la vista, ni tampoco haciendo nuevas solicitudes al servidor web del API
server. Para mayor información https://vuejs.org/. El otro aspecto necesario para que nuestra
interfaz gráfica cumpla con las funciones requeridas, es el cliente http, en este caso, utilizaremos
axios: https://github.com/axios/axios.
La instalación de estas librerías, se explica de manera detallada en el apéndice E. Al realizar este
procedimiento, se debe configurar el vue para que actué como una PWA, esto es posible por
medio de vue cli.

3.2.2 Distribución
Se requiere empaquetado para distribuir sobre plataformas, play store de google y app store de
apple.
4 Funciones y Prestaciones BRATAX
La aplicación de taxis por geo-referencia, será implementada basados en el modelo de múltiples
roles en el sistema, siendo estos:
• Administrador
• Taxista
• Cliente
• Soporte

4.1.1 Administrador
El acceso del administrador, las funciones de este usuario están por definirse, pero lo básico es:
• Administrar usuarios del sistema
• Manejar copias de seguridad

4.1.2 Taxistas
Los usuarios taxistas, deben registrarse en la plataforma , proceso que debe ser autorizado por un
administrador. Este usuario, recibe los anuncios de solicitud de servicios desde la plataforma,
donde decide, si va o no a tomar dicha solicitud.

4.1.3 Clientes
Los usuarios clientes, se pueden registrar de manera más libre en el sistema, pero se debe buscar
algún procedimiento para verificar por asuntos de seguridad. Los clientes, generan solicitudes de
servicio en la plataforma, esta solicitud, se responderá, en lo posible, con taxis ubicados lo más
cerca posible en la zona.

4.1.4 Soporte
El usuario soporte, es un ayudante, para guiar y colaborar con asuntos de usuarios en la
plataforma, dando soporte técnico, u otro tipo de ayudas.
5 BRATAX REST API v1
Las funciones explícitas del servidor API, deben cumplir los requerimientos que el sistema
integral requiere, permitiendo que las aplicaciones clientes, alimenten de data, sus solicitudes.

5.1 Estándar
Apegándose al estándar MVC (Modelo, Vista, Controlador), para así separar el funcionamiento
de las partes primordiales de nuestra solución final, podemos obtener resultados de manera
efectiva, rápida, y escalable. Desde el punto de vista del desarrollo, y para que podamos aplicar
este estándar, requerimos de varias aplicaciones, que van a ser la estructura base del servidor API
BRATAX.

5.2 Librerías
Los requerimientos de software, para el funcionamiento de la aplicación BRATAX API v1, están
enfocados, al funcionamiento correcto, y cumplimiento del MVC, para tal fin, se requieren varias
librerías y/o aplicaciones, funcionando en el entorno de desarrollo. En el título llevará la
indicación si pertenece a modelo, vista, o controlador.

5.2.1 Migraciones (M)

Administrar la base de datos de manera programática, facilitando el proceso de desarrollo, y
mantenimiento de los orígenes de datos. https://db-migrate.readthedocs.io/en/latest/

5.2.1.1 Instalar:

npm install db-migrate

5.2.1.2 Utilizar:

npm install db-migrate

Básicamente con esta solución, podemos mantener el orden de las modificaciones a la BD, que se
realizan en el proceso de desarrollo, por ejemplo db-migrate create add-paises, crea un
documento, donde se pueden agregar campos a una tabla, llamada países, así, queda una
secuencia, en el desarrollo, nos ofrece solo ventajas:
• Almacena cambios en el tiempo.
 • Se puede modificar cualquier estructura de la base de datos, en cualquier momento del
desarrollo.
• Almacena versiones, que permite volver a un momento anterior de la base de datos.

5.2.2 Constructor de consultas y/o Relaciones (M)

Para agilizar el proceso de creación de consultas, pero sin perder la velocidad de funcionamiento
en el servidor de base de datos, se recomienda utilizar un constructor de consultas, aunque
existen varias soluciones, muy avanzadas, como el caso de KNEX, se prefiere algo más cercano a
los requerimientos de nuestro sistema en específico, a manera de pruebas, iniciaremos con el uso
de SHIP-HOLD, debido a que funciona únicamente para Postgresql, y además se pueden definir
relaciones en las tablas.

5.2.2.1 Instalar

npm install --save ship-hold

5.2.3 Templates (V)

Para agilizar el proceso de creación de vistas y formularios HTML, se recomienda el uso de
cualquier sistema de “templates”, aunque existe una variada selección, para este caso en
específico, no es algo muy importante, ya que nuestra app, no requiere demasiadas vistas, ni
formularios, así que, con el soporte para express, y las funciones básicas, se ha escogido, EJS. Un
sistema de templates, que es muy básico de aprender, y efectivo al utilizar.

5.2.3.1 Instalar

npm install ejs

En express:

app.set('view engine', 'ejs')

5.2.3.2 Ejemplo
Es posible implementar soluciones dinámicas, en los documentos HTML de respuesta:

<% if (user) { %>

<h2><%= user.name %></h2>
<% } %>
5.2.4 Autenticación (C)
Para todas las aplicaciones existentes en la actualidad, el manejo de los usuarios del sistema es un
factor muy importante para el buen funcionamiento de una plataforma, multi-usuario, para tal
fin, el manejo de este tema, es mejor ejecutarlo con alguna librería reconocida, y con soporte
extenso, por ejemplo de tokens, y validación con servidores externos como facebook, o twitter,
con esto en mente, la mejor solución puede ser: http://www.passportjs.org/.

5.2.4.1 Instalar Passport

npm install passport

5.2.5 Autorización (C)

Por medio del middleware de express, es posible realizar un sistema de verificación simple de
roles, que es lo que se necesita en la aplicación BRATAX, por el momento, los usuarios ‘Cliente’ y
‘Taxista’, son los roles básicos del sistema, además de 1 usuario administrador.

5.3 ENDPOINTS
El servidor BRATAX API v1, debe cumplir con las funciones necesarias, para alimentar con datos
a la app, por tal motivo, se requiere que existan las funciones, o endpoints, en este servidor, estas
funciones, están definidas dentro del estándar REST:
https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional
Para definir los endpoints, se debe primero completar las funcionalidades de la App, por
ejemplo:
GET /login : Muestra el formulario de acceso de usuarios.
POST /solicitudes: Un usuario cliente, envía una solicitud al server, para que sea procesada, y
encuentre un taxi disponible.
En el caso anterior, tendríamos una API, con 2 endpoints, si el servicio se encontrara alojado en
un dominio, por ejemplo, bratax.com, los endpoints quedarían así, si no se ha modificado algo en
el web server:

http://bratax.com/login
http://bratax.com/solicitudes
Página en blanco
6 Apéndice – CENTOS 7
Descargar:

wget http://isoredirect.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1810.iso

6.1 Broker MQTT

https://mosquitto.org/download/

6.1.1 Message Broker

https://www.rabbitmq.com/install-rpm.html
7 APÉNDICE A - NodeJS
7.1 Instalación Requerimientos de Librerías nodejs – BRATAX API Server v1
Utilizando el administrador de paquetes npm.

7.1.1 Express framework

npm install express --save

7.1.2 Mensajería instantanea websocket

npm install --save socket.io

7.1.3 Módulo de postgresql

npm install --save pg
Posiblemente es mejor utilizar pg-promise, pero verificando soporte con otras librerías del
servidor API como db-migrate. Funciona bien con express.

npm install pg-promise

7.1.4 Cliente http

npm install --save axios

7.1.5 Redis In memory DB:

npm install --save redis
8 Apéndice B – GEOserver en Centos 7
8.1 Entorno Java
De antemano, se debe tener instalado el repo EPEL:

sudo yum install -y epel-release

Luego, dirigirse a:
https://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
Y descargar rpm:

cd ~
wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F
%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie"
"http://enlace_copiado_desde_sitio"

Instalar rpm, verificando que el número de versión coincida, con la descargada en el paso
anterior:

sudo yum localinstall jre-8u161-linux-x64.rpm

Al finalizar la instalación, el ejecutable se encuentra en /usr/java/jre1.8.0_161/bin/java, y
enlazado a /usr/bin/java. Se puede borrar el archivo descargado anteriormente:

rm ~/jre-8u161-linux-x64.rpm

8.1.1 COnfiguraCIÓN
Es posible, que el sistema tenga varios entorneo de ejecución de java, para verificar cuál versión
se encuentra funcionando, ejecutar:

java -version

8.1.2 UTILIZANDO Alternatives

El comando alternatives, nos permite seleccionar que versión queremos que sea la
predeterminada en el sistema:

sudo alternatives --config java

8.2 Instalar TOMCAT
8.2.1 Crear un usuario dedicado para Tomcat
sudo groupadd tomcat
sudo mkdir /opt/tomcat
sudo useradd -s /bin/nologin -g tomcat -d /opt/tomcat tomcat

8.2.2 Descargar
cd ~
wget https://www-eu.apache.org/dist/tomcat/tomcat-8/v8.5.38/bin/apache-tomcat-
8.5.38.tar.gz
sudo tar -zxvf apache-tomcat-8.5.38.tar.gz -C /opt/tomcat --strip-components=1

8.2.3 Configurar permisos:

cd /opt/tomcat
sudo chgrp -R tomcat conf
sudo chmod g+rwx conf
sudo chmod g+r conf/*
sudo chown -R tomcat logs/ temp/ webapps/ work/

sudo chgrp -R tomcat bin

sudo chgrp -R tomcat lib
sudo chmod g+rwx bin
sudo chmod g+r bin/*

8.2.4 Systemd
sudo nano /etc/systemd/system/tomcat.service

8.2.4.1 tomcat.service

[Unit]
Description=Apache Tomcat Web Application Container
After=syslog.target network.target

[Service]
Type=forking

Environment=JAVA_HOME=/usr/lib/jvm/jre
Environment=CATALINA_PID=/opt/tomcat/temp/tomcat.pid
Environment=CATALINA_HOME=/opt/tomcat
Environment=CATALINA_BASE=/opt/tomcat
Environment='CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC'
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom'

ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/bin/kill -15 $MAINPID
 User=tomcat
Group=tomcat

[Install]
WantedBy=multi-user.target

8.2.5 Verificar entropía

cat /proc/sys/kernel/random/entropy_avail
Si el resultado es menor que 1000:

sudo yum install haveged

sudo systemctl start haveged.service
sudo systemctl enable haveged.service

8.2.6 Configurar firewall

sudo firewall-cmd --zone=public --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

8.2.7 Iniciar servicio

sudo systemctl start tomcat.service
sudo systemctl enable tomcat.service
Acceder y verificar funcionamiento:

http://[IP-DEL-SERVIDOR]:8080

8.2.8 Crear administrador

sudo nano /opt/tomcat/conf/tomcat-users.xml
En el segmento </tomcat-users ...>...</tomcat-users>, se debe insertar una línea definiendo al
usuario necesario para esta implementación1, báscamente solo requerimos del usuario admin:

8.2.8.1 /opt/tomcat/conf/tomcat-users.xml

<role rolename="tomcat"/>
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<role rolename="admin-gui"/>

1 https://blog.techstacks.com/2010/07/new-manager-roles-in-tomcat-7-are-wonderful.html
 <role rolename="admin-script"/>
<user username="tomcat" password="[CHANGE_ME]" roles="tomcat"/>
<user username="manager" password="[CHANGE_ME]" roles="manager-gui,manager-
script,manager-jmx,manager-status"/>
<user username="admin" password="[CHANGE_ME]" roles="manager-gui,admin-gui"/>
Reiniciar:

sudo systemctl restart tomcat.service

Si todo funciona bien, debe aparecer en la interface web unos enlaces para la administración del
servidor, y contenedores (Server Status, Manager App, Host Manager).

8.3 Instalar Geoserver

Descargar:

wget https://superb-dca2.dl.sourceforge.net/project/geoserver/GeoServer/2.15.0/
geoserver-2.15.0-war.zip
Descomprimir:

sudo unzip -d /opt/apache-tomcat-8.5.13/webapps geoserver-2.15.0-war.zip geoserver.war

9 Apéndice C – Project OSRM
9.1 Compilar en centos 7
Se requiere tener las herramientas básicas de programación instaladas en un server, la versión del
compilador gcc que viene predeterminada en Centos 7 es muy antigua, y se requiere por lo tanto:

yum install yum-utils centos-release-scl

yum-config-manager --enable rhel-server-rhscl-7-rpms
yum install devtoolset-6
Iniciar una nueva shell:

scl enable devtoolset-6 bash

Instalamos las siguientes aplicaciones y librerías:
yum install git cmake3 zlib-devel
Luego, descargamos y compilamos, para las otras dependencis, utilizaremos MASON, con eso no
necesitamos recompilar boost:

git clone https://github.com/Project-OSRM/osrm-backend.git

cd osrm-backend
mkdir build
cd build
cmake3 .. -DENABLE_MASON=ON -DCMAKE_CXX_COMPILER=/opt/rh/devtoolset-6/root/usr/bin/g++
make
make install
10 Apéndice D – Nominatim en centos 7
10.1 Requerimientos de Nominatim
Se necesita: Base de datos Postgresql con extension PostGIS, servidor web, php.

10.1.1 Instalar repo

sudo yum install -y epel-release

10.1.2 Instalar dependencias

sudo yum install -y postgresql-server postgresql-contrib postgresql-devel \
postgis postgis-utils \
wget git cmake make gcc gcc-c++ libtool policycoreutils-python \
php-pgsql php php-pear php-pear-DB php-intl libpqxx-devel \
proj-epsg bzip2-devel proj-devel libxml2-devel boost-devel \
expat-devel zlib-devel

10.1.3 Configurar siStema

sudo useradd -d /srv/nominatim -s /bin/bash -m nominatim
export USERNAME=nominatim
export USERHOME=/srv/nominatim
chmod a+x $USERHOME

10.1.4 Configurar postgresql

sudo postgresql-setup initdb
sudo systemctl enable postgresql

10.1.4.1 postgresql.conf

shared_buffers (2GB)
maintenance_work_mem (10GB)
work_mem (50MB)
effective_cache_size (24GB)
synchronous_commit = off
checkpoint_segments = 100 # only for postgresql <= 9.4
checkpoint_timeout = 10min
checkpoint_completion_target = 0.9

sudo systemctl restart postgresql

For the initial import, you should also set:

 fsync = off
full_page_writes = off
Finally, we need to add two postgres users: one for the user that does the import and another for
the webserver which should access the database only for reading:

sudo -u postgres createuser -s $USERNAME

sudo -u postgres createuser apache

10.1.5 Configurar Apache

Add a separate nominatim configuration to your webserver:

sudo tee /etc/httpd/conf.d/nominatim.conf << EOFAPACHECONF

<Directory "$USERHOME/build/website">
Options FollowSymLinks MultiViews
AddType text/html .php
DirectoryIndex search.php
Require all granted
</Directory>

Alias /nominatim $USERHOME/build/website

EOFAPACHECONF
Then reload apache

sudo systemctl enable httpd

sudo systemctl restart httpd

10.1.6 Instalar Nominatim

cd $USERHOME
wget https://nominatim.org/release/Nominatim-3.2.0.tar.bz2
tar xf Nominatim-3.2.0.tar.bz2
cd Nominatim-3.2.0

The code must be built in a separate directory. Create this directory, then configure and build
Nominatim in there:

cd $USERHOME
mkdir build
cd build
cmake $USERHOME/Nominatim-3.2.0
make
10.1.7 Configurar Selinux
It is a good idea to leave SELinux enabled and enforcing, particularly with a web server
accessible from the Internet. At a minimum the following SELinux labeling should be done for
Nominatim:

sudo semanage fcontext -a -t httpd_sys_content_t "$USERHOME/Nominatim-3.2.0/(website|

lib|settings)(/.*)?"
sudo semanage fcontext -a -t httpd_sys_content_t "$USERHOME/build/(website|lib|settings)
(/.*)?"
sudo semanage fcontext -a -t lib_t "$USERHOME/build/module/nominatim.so"
sudo restorecon -R -v $USERHOME/Nominatim-3.2.0
sudo restorecon -R -v $USERHOME/build

You need to create a minimal configuration file that tells nominatim the name of your webserver
user and the URL of the website:

tee settings/local.php << EOF

<?php
@define('CONST_Database_Web_User', 'apache');
@define('CONST_Website_BaseURL', '/nominatim/');
EOF
11 Apéndice E – Requerimientos BRATAX APP
Para el correcto funcionamiento del entorno de desarrollo de Nativescript, se requiere tener
instalado Node JS, y npm. Además se deben instalar las librerías de desarrollo para androide y/o
para IOS, para así poder utilizar las prestaciones nativas que permite este framework

npm install -g nativescript

nativescript create brataxapp
nativescript platform add android
nativescript platform add ios
Para mayor información: https://www.nativescript.org/
Android: https://developer.android.com/studio/install
IOS: https://developer.apple.com/ios/
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/
SubmittingYourApp/SubmittingYourApp.html